Liveness and readiness tell Kubernetes how the Pod feels

Wed, 14 Jul 2027 00:00:00 +0000

A slow start is not a dead process. Readiness and liveness make independent decisions: whether ordinary Service traffic should reach this Pod, and whether terminating this container can help it recover. Readiness failure does not suspend liveness. A startup probe provides that startup protection when configured.

This article focuses on choosing useful health signals and diagnosing bad wiring. Endpoint names are less important than what each check measures. Sharing a URL can work; a shared dependency check that triggers unnecessary restarts can make an outage worse. Test the failure mode and intended recovery, rather than assuming two endpoints automatically make the configuration safe.

Ordinary Service routing converges asynchronously; existing connections and direct Pod access need separate consideration.

Readiness gates traffic

Repeated readiness failures make a Pod ineligible for ordinary Service routing but leave it running, so the process can warm up or recover. Endpoint conditions and the datapath converge asynchronously in both directions; existing connections and direct Pod access need separate consideration. Readiness failure avoids a probe-triggered restart, but can remove all serving capacity: caches can warm, migrations can finish, downstream dependencies can come back, all without losing the Pod’s in-memory state or paying a restart penalty.

Design the readiness endpoint around genuine servability. Check what makes this Pod able to answer correctly right now: migrations applied, required caches populated, critical downstream reachable. A probe that only checks “the HTTP server responds” admits traffic to Pods that will fail every request. But resist stuffing every dependency into it: if a non-critical recommendation service is down, failing readiness sheds real traffic over a decoration.

Liveness guards the process

Repeated liveness failures reach a threshold and terminate the container; restart follows policy. This is a last resort for a hopeless wedge. Use it for what it is a liveness issue—not for containers that are merely slow to become ready. The legitimate targets are narrow: deadlocks where no request will ever succeed again, runaway goroutine or thread leaks that only a fresh process clears, corrupted in-memory state that no retry can heal. In each case the defining property is irreversibility — without a restart, recovery is impossible, not merely slow.

That bar means many services should ship a minimal liveness probe or none at all. A liveness check against an external database turns every database blip into a fleet-wide restart storm. Prefer a cheap local check — a watchdog timestamp refreshed by the main loop — that detects “this process is wedged” without consulting anything outside the process. Container restart policy determines recovery after crashes. Liveness can detect selected unrecoverable local failures before ordinary exit occurs.

Give the probes grace

Set the initialDelaySeconds high enough that a cold start is not counted as a crash, and keep timeoutSeconds consistent with real work. Configure startup protection independently: readiness alone cannot prevent liveness-driven termination. Better still, add a startup probe for slow-booting containers: until it succeeds, both liveness and readiness stay disabled, so version upgrades that warm large caches get minutes instead of seconds without weakening steady-state liveness at all.

Tune thresholds from observed behavior, not round numbers copied between services. periodSeconds times failureThreshold is a planning estimate, not an exact reaction time. Probe phase, timeout, scheduling, termination grace and restart backoff alter the observed timeline. Measure cold-start p99, dependency recovery time, and worst-case pauses, then set each number to react faster than the alert but slower than the noise.

When it breaks

The signature failure is the restart loop during dependency outages: the database slows, readiness would have sufficed, but liveness probes share the same failing endpoint and the whole fleet restarts in waves. Each restart wipes warm caches, making the next wave slower to recover, until the system oscillates indefinitely. Diagnose by correlating restart timestamps with the dependency incident; repair the decision semantics. Keep restart signals local and recovery-relevant. Dependency-aware readiness may help, but withdrawing every replica can be worse than serving degraded responses during a shared outage.

The mirror failure is the zombie Pod: liveness passes because the HTTP server responds, but every request hangs behind a deadlocked worker pool. Traffic keeps flowing to a Pod that answers nothing. A short worker-slot timeout cannot distinguish deadlock from healthy saturation and can trigger overload-driven restarts. Prefer evidence of stalled critical worker progress that accounts for expected pauses and idle periods; validate that restarting improves this specific failure. Handle temporary overload separately.

Check it quickly

Inspect probe wiring and recent kills:

kubectl get pod web-0 -o jsonpath='{.spec.containers[*].livenessProbe}{"\n"}{.spec.containers[*].readinessProbe}{"\n"}'
kubectl get events --field-selector reason=Unhealthy --sort-by=.lastTimestamp | tail -n 10
kubectl describe pod web-0 | grep -A3 -i 'liveness\|readiness'

These unchanged diagnostics were not rerun here. Shared URLs are not inherently wrong if their semantics fit both decisions. Unhealthy events include probe failures, not proof of a kill. Correlate the named Pod, container restart count and termination reason; bounded checks must distinguish deadlock from temporary load and harmless idleness.

Sources

Kubernetes probes, Official docs on liveness and readiness, checked 2026-10-15.
Configure liveness and readiness probes, task guide for probe configuration, checked 2026-10-15.