Kubernetes comparison
Liveness vs Readiness Probe: What Each Does in Kubernetes
A liveness probe decides whether Kubernetes restarts a container. A readiness probe decides whether the pod receives traffic from its Services. A failed readiness probe never restarts the container, and a failed liveness probe never removes the pod from a Service on its own. A startup probe holds both back until the app has started.
By Muhammad Soliman, Founder at SeaGit
·
Key takeaways
- Liveness failure restarts the container. Readiness failure removes the pod IP from matching Service endpoints and leaves the container running.
- If you configure a startup probe, Kubernetes runs neither liveness nor readiness until the startup probe succeeds.
- Do not point liveness at a dependency such as a database. A slow database then restarts every healthy app pod.
- Set liveness conservatively and readiness more aggressively. Liveness is the last resort, readiness is the everyday control.
The three probes at a glance
The official concept page defines three probes. The table shows the question each one answers and what the kubelet does when it fails.
| Probe | Question it answers | On failure |
|---|---|---|
| Liveness | Is the container stuck, such as in a deadlock? | The kubelet restarts the container after the failure threshold |
| Readiness | Can the container take traffic right now? | The pod IP is removed from matching EndpointSlices; no restart |
| Startup | Has the application finished starting? | The kubelet kills the container and applies the restart policy |
Readiness runs for the whole life of the container. Liveness runs periodically too. The startup probe runs only at start-up, which is why it is the right tool for a slow application.
A config that uses all three correctly
The example gives a slow Java service up to five minutes to start. Liveness and readiness are not evaluated until the startup probe passes, so their short periods do not kill the container during boot.
containers:
- name: my-api
image: registry.example.com/my-api:1.4.2
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
failureThreshold: 30 # up to 300 seconds to start
readinessProbe:
httpGet:
path: /ready # local state only, no database call
port: 8080
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
livenessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 15
timeoutSeconds: 2
failureThreshold: 6 # restart only after about 90 seconds of failureThe startup budget is failureThreshold times periodSeconds. Here that is 30 times 10, or 300 seconds. If the application needs longer, raise the threshold rather than the readiness delay.
The restart storm: why liveness must not check dependencies
A liveness probe that calls the database fails for every pod when the database is slow. Each failure restarts the container, so the app loses its warm caches and its connections at the moment it is needed most. The official page defines the restart action. The advice to keep dependency checks out of liveness is widely used practice rather than a quoted rule, and it follows from that action.
- Liveness: the process can still run its loop. A local check of the HTTP server or an internal heartbeat is enough.
- Readiness: the process can serve requests now. A dependency check belongs here only when the app cannot answer anything without that dependency.
- Startup: the app has finished its initial work, such as loading a model or running migrations.
Decision rules for real services
Stateless web API
Readiness checks that the app has loaded its config and can accept a request. Liveness checks only that the HTTP server still answers. Add a startup probe only if boot takes longer than the liveness window.
Worker that consumes a queue
A worker has no Service, so readiness adds little. Use liveness to catch a stuck consumer loop, with a heartbeat the worker writes on each iteration.
When a probe is the wrong tool
If you find yourself restarting pods to fix a traffic problem, the probe is not the bug. Look at the Service selector, the endpoints and the app capacity. The readiness-failed guide covers the endpoint side.