Startup, Liveness and Readiness Probes
How does the Kubelet tell a slow boot from a hung container? Three probes answer that on their own periodSeconds: startupProbe gates the other two until the app is up, livenessProbe restarts the container per restartPolicy after failureThreshold consecutive failures, and readinessProbe flips the Pod endpoint to ready=false in the EndpointSlice without removing it or restarting anything. A probe never restarts a Pod, only the container that failed it.
Play the animation 6 steps, animated, best on a wide screen
Startup, Liveness and Readiness Probes, step by step
-
Kubelet runs startupProbe against the container every periodSeconds, with an httpGet, tcpSocket, grpc or exec handler. While it runs, livenessProbe and readinessProbe are held shut and never execute, so a slow boot never reads as a liveness failure. If it exhausts failureThreshold, Kubelet kills the container and restartPolicy decides what follows.
Play from step 1 -
The startupProbe succeeds once. Kubelet retires it for the lifetime of this container instance and never runs it again, and the two probes it was holding are released. From here livenessProbe and readinessProbe run independently, each on its own periodSeconds, and neither waits for the other.
Play from step 2 -
The readinessProbe passes successThreshold consecutive times, and may run ahead of its period while not Ready. Kubelet flips the Pod Ready condition to True and the Pod endpoint in the EndpointSlice flips to ready=true, so new connections start reaching it. Every condition named in spec.readinessGates must be True first.
Play from step 3 -
The readinessProbe alone fails failureThreshold consecutive times. The Pod endpoint in the EndpointSlice is marked ready=false rather than removed, so new connections stop reaching it. Nothing is restarted and restartCount stays 0, because a readiness failure only moves traffic away.
Play from step 4 -
The livenessProbe fails failureThreshold consecutive times on its own period. Kubelet kills the container and starts a fresh instance per restartPolicy, so restartCount becomes 1 and the endpoint stays ready=false. The Pod object is not replaced and keeps its IP, because a probe restarts a container and never a Pod.
Play from step 5 -
The replacement container starts from the beginning. Kubelet runs startupProbe again and holds the other two shut until it passes, then readinessProbe succeeds and that endpoint flips back to ready=true. The restartCount carries over, so it climbs with every restart, which is how a restart loop is read off a running one.
Play from step 6