K8s — Liveness vs Readiness

InfrastructureMidkubernetes

The Question

What is the difference between liveness and readiness probes in K8s?

What a Strong Answer Covers

• liveness = restart
• "readiness = no traffic
• not restarted

Senior-Level Answer

Kubernetes uses probes to determine the health of a container, but liveness and readiness probes serve fundamentally different purposes and trigger different control-plane actions.

A **liveness probe** answers the question: "Is this container still alive?" If the probe fails, kubelet kills the container and restarts it according to the pod's `restartPolicy`. Use liveness probes to recover from deadlocks or infinite loops — states where the process is running but making no progress. A classic example is a JVM that has deadlocked: the process is up, but no requests complete. Without a liveness probe the pod would stay in a broken state forever.

A **readiness probe** answers the question: "Is this container ready to serve traffic?" If the probe fails, the pod's IP is removed from the Endpoints object of any matching Service, so the load balancer stops routing new connections to it. The container is *not* restarted. This is the right tool for a pod that is temporarily overwhelmed, waiting for a dependency (database, cache), or performing a warm-up operation like loading a large ML model into memory.

Both probes support three mechanisms: `httpGet` (checks for a 2xx/3xx HTTP response), `tcpSocket` (checks that a port accepts connections), and `exec` (runs a command inside the container and checks the exit code). Key configuration fields include `initialDelaySeconds` (grace period before the first check), `periodSeconds` (how often to check), `failureThreshold` (consecutive failures before action), and `successThreshold` (consecutive successes to recover readiness).

A common production pattern is to run both together: the readiness probe uses a lightweight `/healthz` endpoint that also validates upstream dependencies, while the liveness probe hits a simpler `/livez` endpoint that only confirms the process is responsive. This prevents a cascade where a failing dependency causes a restart loop (liveness) when the correct behavior is to shed traffic (readiness).

Missing a readiness probe is one of the most frequent causes of failed rolling deployments — new pods receive traffic before they are ready, spiking error rates.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying both probes restart the container — only liveness does.
• Using liveness instead of readiness for dependency health checks, causing unnecessary restart loops.
• Forgetting initialDelaySeconds, causing probes to fire before the app starts and immediately cycling the pod.
• Pointing both probes at the same heavy endpoint, adding latency overhead and defeating the separation of concerns.

Follow-Up Questions

• What is a startup probe and when would you use it instead of initialDelaySeconds? — Startup probes block liveness/readiness checks until the container passes once — ideal for slow-starting legacy apps where initialDelaySeconds would be a static worst-case guess.
• How would you design the /livez and /healthz endpoints differently? — livez should only check internal process health (no external calls); healthz can check upstream dependencies but must return fast to avoid probe timeouts.
• What happens to in-flight requests when a readiness probe fails? — Existing connections are not dropped; the pod is removed from Endpoints so no *new* connections are routed to it. Graceful termination handles in-flight requests.
• How do liveness probe failures interact with a CrashLoopBackOff? — Repeated liveness failures → restarts → exponential back-off delay applied by kubelet, resulting in CrashLoopBackOff state.

Related Questions

• K8s — Pod vs Deployment
• K8s — ConfigMap vs Secret
• Helm Chart
• Docker — Container vs VM
• CI/CD Pipeline