Understanding Kubernetes Liveness and Readiness Probes
Liveness and readiness probes are health checks the kubelet runs against a container to decide whether it’s still working and whether it should receive traffic. They’re defined in a Pod’s container spec (spec.containers[].livenessProbe and readinessProbe) and can check an HTTP endpoint, run a TCP socket check, execute a command inside the container, or, for newer Kubernetes versions, check a gRPC health endpoint. A related third probe type, the startup probe, protects slow-starting containers from being killed prematurely by a liveness probe during initialization.
How They’re Different
A liveness probe answers the question: is this container still alive and functioning, or should it be restarted? If it fails repeatedly (past failureThreshold), the kubelet kills and restarts the container according to the Pod’s restart policy. A readiness probe answers a different question: is this container ready to receive traffic right now? If it fails, the Pod is removed from the endpoints of any Service selecting it – the container keeps running, it just stops receiving new requests until it passes again. Confusing the two is one of the most common Kubernetes misconfigurations: using a liveness probe where a readiness probe belongs can cause unnecessary restart loops during temporary slowness, like a database connection pool warming up.
Simple Example
An API server exposes a /healthz endpoint that always returns 200 as long as the process is running, and a /ready endpoint that returns 200 only once it has successfully connected to its database. The Pod spec sets livenessProbe to httpGet /healthz with periodSeconds 10 and failureThreshold 3, and readinessProbe to httpGet /ready with the same interval. During a deploy, the new Pod starts, but its readiness probe fails until the database connection succeeds – the Service doesn’t route traffic to it yet, avoiding errors, while the liveness probe passes the whole time because the process itself is healthy.
Common Use Cases
Zero-Downtime Rollouts
Readiness probes are what make rolling updates safe – a Deployment won’t consider a new Pod available and proceed with the rollout until it passes readiness.
Automatic Recovery from Deadlocks
A liveness probe catches cases where a process is running but stuck (deadlocked, out of memory, unresponsive) and forces a restart to recover automatically.
Protecting Slow-Starting Applications
A startupProbe with a generous failureThreshold and periodSeconds gives applications with long initialization (JVM warm-up, large cache loads) time to start without being killed by an impatient liveness probe.
Benefits
- Enables self-healing at the container level, beyond just Pod-level rescheduling.
- Prevents traffic from reaching Pods that aren’t actually ready, reducing user-facing errors during deploys and scaling events.
- Integrates directly with rolling update logic and Pod Disruption Budgets to make deployments and node drains safer.
Limitations and Risks
- A liveness probe that checks downstream dependencies (like a database) instead of the container’s own health can cause cascading restarts across many Pods when that dependency has an outage – a well-known anti-pattern.
- Overly aggressive probe timing (short periodSeconds, low failureThreshold) can cause flapping restarts under normal load spikes.
- Missing a startupProbe on slow-starting containers is a common cause of CrashLoopBackOff during deploys.
- Probes add load to the container being checked; very frequent probing on a resource-constrained container can itself contribute to instability.
Best Practices
- Keep liveness probes simple and scoped to the process itself – never check external dependencies in a liveness probe.
- Use readiness probes to check real dependency health (database, cache, downstream services) since failing readiness only removes the Pod from traffic, it doesn’t restart it.
- Add a startupProbe for any container with meaningful startup time, and let it own the initial grace period instead of stretching the liveness probe’s failureThreshold.
- Tune periodSeconds, timeoutSeconds, and failureThreshold based on realistic application behavior, not defaults copied from another service.
- Monitor probe failures and container restart counts (kubectl get pods, RESTARTS column) as a leading indicator of instability.
Frequently Asked Questions
What is Kubernetes Liveness and Readiness Probes?
Liveness and readiness probes are kubelet-run health checks that decide whether a container should be restarted (liveness) or removed from Service traffic without being restarted (readiness).
How does Kubernetes Liveness and Readiness Probes work?
Kubernetes Liveness and Readiness Probes works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Kubernetes Liveness and Readiness Probes matter?
Teams adopt Kubernetes Liveness and Readiness Probes to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Kubernetes Liveness and Readiness Probes?
Use Kubernetes Liveness and Readiness Probes when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
