Probes (Liveness & Readiness)
A container being up and a container being able to take requests are two different things. The kubelet asks each container on a schedule, and it answers the same silence in two ways: a failed readiness probe only removes the Pod from the Service endpoints, while a failed liveness probe kills the container and starts it again. Which one you attach decides whether an incident merely cuts traffic or restarts the process.
01Probes (Liveness & Readiness)
Concept at a Glancereadiness fails · it only cuts the traffic
Three Pods sit behind the Service. The kubelet asks each of them every ten seconds, and only the ones that answer well are listed as endpoints.
The second Pod has taken on heavy work and is slow to answer. One missed check is not enough to pull it out.
After three failures in a row, Ready goes down. The container has not died — it is still running.
New requests now go only to the other two. The Pod that dropped out was never killed, so it gets time to finish what it was doing.
The work ends and the checks pass again. Coming back takes a single success.
There is a cost. Tune the check too tightly and a load spike pulls healthy Pods out one after another, until the ones left take that share too and follow them out.
liveness fails · it ends the container
The same Pod can carry a liveness probe as well. This one does not ask whether it can take requests, but whether it is alive at all.
The app in the second Pod has deadlocked. The process is still up, so nothing restarts on its own — from outside, only the answers are missing.
After three failures in a row the kubelet kills the container. This is where the two part ways: readiness pulled it out, liveness ends it.
The container starts again inside the same Pod. Name and IP are unchanged; only the restart count goes up.
For a slow-starting app this becomes a trap. The check fails before startup finishes, so it dies again — and never manages to come up.
A startupProbe holds the other checks off until startup is done. Telling a slow start apart from a real hang is exactly what this probe is for.
If the cause stays, the restarts repeat. The gap between them doubles, up to five minutes, and it settles into CrashLoopBackOff.
Try it yourself
Break web-2, then repeat the same failure while switching which probe is attached. Whether it is merely pulled out or restarted is what changes.
probe attached readiness · All three are answering · try breaking web-2
02 Understand It Simply
For Everyonereadiness only removes a pod from traffic, while liveness kills the container and restarts it. The same missing response gets a different verdict, so choosing the wrong one either blocks recovery or restarts healthy pods.
When readiness fails, the endpoints controller takes that Pod's address out of the Service endpoints.
The container keeps running, so work in flight survives, and the address comes back once the Pod recovers.
When liveness fails, the kubelet kills the container and starts it again according to restartPolicy — it is the outside lever for a process that is up but stuck, as in a deadlock.
No verdict comes from a single check: probes run every periodSeconds (10 by default) and the state flips only after failureThreshold (3 by default) consecutive failures, while a single success brings it back.
Probes can be httpGet, tcpSocket, exec, or grpc.
Attaching liveness straight to a slow-starting app is a trap — it dies mid-startup, over and over — so a startupProbe holds the other checks off until it succeeds.
Repeated restarts back off exponentially (capped at five minutes) and surface as CrashLoopBackOff.
The cost is just as concrete: a probe tuned too tightly pulls healthy Pods out under load, piling that load onto the ones still in, and a liveness probe that also checks a dependency restarts your container over someone else's outage.
- –Choosing between readiness and liveness
- –adding a startupProbe to a slow-starting app
- –narrowing down a CrashLoopBackOff
- –and understanding what a rolling update means by ready
03 Frequently Asked Questions
FAQWhat is Probes (Liveness & Readiness)?+
A container being up and a container being able to take requests are two different things. The kubelet asks each container on a schedule, and it answers the same silence in two ways: a failed readiness probe only removes the Pod from the Service endpoints, while a failed liveness probe kills the container and starts it again. Which one you attach decides whether an incident merely cuts traffic or restarts the process.
Where is Probes (Liveness & Readiness) used?+
Choosing between readiness and liveness, adding a startupProbe to a slow-starting app, narrowing down a CrashLoopBackOff, and understanding what a rolling update means by ready.
What's a simple analogy for Probes (Liveness & Readiness)?+
readiness only removes a pod from traffic, while liveness kills the container and restarts it. The same missing response gets a different verdict, so choosing the wrong one either blocks recovery or restarts healthy pods.