In brief
Readiness controls whether a pod receives service traffic, liveness decides whether a container should restart, and startup protects slow-starting applications before liveness takes over.
Key takeaways
- Use readiness to remove an unavailable pod from service traffic.
- Use liveness only when restarting can recover the failed condition.
- Use startup probes for applications with long or variable initialization.
- Keep probe endpoints cheap, bounded, observable, and intentional about dependencies.
What each probe controls
A readiness probe answers whether the container should receive traffic through Kubernetes Services. When readiness fails, the pod can remain running while endpoints stop directing normal service traffic to it. This is appropriate for temporary overload, dependency initialization, cache warming, or conditions where the process is alive but cannot serve requests safely.
A liveness probe answers whether Kubernetes should restart the container. It is appropriate for unrecoverable states such as a deadlock when a restart is expected to restore progress. A startup probe delays liveness and readiness evaluation until a slow-starting application has completed initialization according to the configured threshold.
Design probe endpoints deliberately
A probe endpoint should complete quickly, consume little capacity, and describe the intended state. Readiness may check dependencies required to serve traffic, but liveness should usually avoid failing because a remote dependency is briefly unavailable. Otherwise a downstream outage can trigger mass restarts and make recovery harder.
Choose HTTP, TCP, gRPC, or command probes based on the actual service contract. Ensure the probe uses the correct port, path, scheme, headers, and timeout. Protect it from expensive database queries and uncontrolled fan-out, but include enough application logic to distinguish a functioning process from an unresponsive shell.
Tune thresholds from observed startup and failure behavior
Set initial delays, periods, timeouts, success thresholds, and failure thresholds from real measurements. Values that are too strict create false failures during CPU pressure, deployment, or dependency latency. Values that are too relaxed delay traffic removal or recovery from a genuine failure.
For slow startup, prefer a startup probe over an extremely long liveness delay because it separates initialization from steady-state behavior. During rolling deployments, align readiness with termination behavior, graceful shutdown, disruption budgets, and rollout settings so traffic does not reach a pod before it is ready or continue after shutdown begins.
- Measure cold-start and warm-up duration at realistic resource limits.
- Log probe failure reasons without flooding application logs.
- Alert on repeated probe failures and restart loops, not isolated failures alone.
- Test dependency outages to confirm probes fail in the intended way.
Troubleshoot probe-driven incidents
When pods restart or disappear from endpoints, review events, pod status, restart count, previous container logs, probe response, node pressure, CPU throttling, memory limits, and rollout history. Reproduce the probe from inside the pod when appropriate and compare it with the application path used by real clients.
Do not disable probes permanently to hide an incident. Adjust a probe only when evidence shows that its contract or thresholds are wrong, and verify the change during startup, steady traffic, overload, dependency failure, and graceful termination.