What are liveness and readiness probes, and what happens when each fails?

What's really being asked

Whether you understand that liveness and readiness are separate signals consumed by different Kubernetes controllers. The kubelet consumes liveness results to decide container-level lifecycle actions, while the endpoint controller consumes readiness results to decide routing-level inclusion. Senior candidates should articulate the exact failure consequences for the container process, the Pod object, and network traffic.

The full answer

Four things in order. First, purpose: liveness asks is the container alive or stuck in a deadlock; readiness asks is the application ready to accept traffic. Second, liveness failure: the kubelet kills the container and creates a new one according to the Pod restartPolicy; existing connections may drop depending on grace periods, but the Pod IP generally remains until the container exits. Third, readiness failure: the Pod is not restarted; instead the endpoint controller removes its IP from all matching Service endpoints, so new traffic stops immediately while the container keeps running. Fourth, traffic nuance: readiness failure is a traffic cut, liveness failure is a process recycle, and during a liveness restart the Pod may still receive traffic briefly until the container actually terminates.

The mistakes people make

Three red flags. First, saying liveness failure removes the Pod from Service endpoints; that confuses it with readiness. Second, saying readiness failure restarts the container; that confuses it with liveness. Third, claiming that startup probes are just another readiness probe; in reality startup probes disable liveness and readiness checks until the container has started, which is a distinct third state.

What usually comes next

Interviewers often ask how startup probes interact with the other two, how to choose probe types like HTTP versus TCP versus exec, what happens under a Pod restartPolicy of Never, or how graceful shutdown ties into the preStop hook and readiness. They may also ask for real-world debugging: if a Pod is restarting every thirty seconds, is it a liveness threshold that is too aggressive or a readiness probe that is missing entirely.

A concrete example

Imagine a Java application with a forty-second JVM warm-up. If you set a liveness probe with an initialDelaySeconds of ten and periodSeconds of five, the kubelet will restart the container before it finishes starting, creating a crash loop. The correct fix is adding a startup probe with a high failureThreshold or long initialDelay, then using readiness to gate traffic until the health endpoint returns two hundred, and liveness only to catch deadlocks after startup is complete. If readiness fails during a database outage, the Pod stays alive but receives zero traffic; if liveness fails because of a deadlock, the container is recreated and traffic resumes only after the new process passes readiness again.