A common misconception says that when a Kubernetes readiness probe fails, Kubernetes restarts the container. It does not. Readiness controls whether a Pod should receive traffic from Services; container restarts are the job of liveness probes and process supervision.
The kubelet runs a container’s readiness probe according to the probe configuration. If the probe succeeds, Kubernetes can mark the container as ready. If every required readiness condition is satisfied, the Pod’s Ready condition becomes true. When the probe begins failing, the container is marked not ready, which normally makes the Pod not ready as well.
That state change affects service discovery. Controllers update the relevant EndpointSlices so that a not-ready Pod is no longer treated as an eligible backend for ordinary Service traffic. Components such as kube-proxy, or another implementation of Service routing, then converge on the new endpoint state.
The container keeps running throughout this process. Its process is not killed, its filesystem is not reset, and its restart count does not increase merely because readiness failed. The kubelet continues executing the readiness probe. If the application recovers and the probe succeeds again, the Pod can become ready and rejoin the Service’s available backends without a restart.
This distinction makes readiness probes suitable for temporary inability to serve traffic. An application may be alive but unable to answer requests while it refreshes configuration, reconnects to a dependency, fills a cache, or drains work. A readiness failure can isolate that instance while preserving its in-memory recovery process.
Removal from Service endpoints is not an instantaneous cancellation mechanism. Endpoint updates must propagate, and existing connections may remain open. A client using a persistent TCP connection might continue sending requests to the same Pod even after that Pod becomes unready. Readiness is therefore a routing signal, not a guarantee that all traffic stops at the exact moment a probe fails.
If an unhealthy container must be terminated and started again, a liveness probe expresses that policy. A liveness failure can cause the kubelet to restart the container according to the Pod’s restart policy. Using liveness for a condition that can recover naturally may instead create restart loops and erase useful recovery progress.
The precise correction is simple: readiness failure removes a Pod from normal Service traffic; it does not restart the container.
Top comments (0)