Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Three checks, three responses
A failed probe doesn’t always mean a restart. Readiness makes the API Pod ineligible for Service traffic while its container keeps running; liveness can restart it. During slow startup, the startup probe holds both checks back.
Ready: traffic can reach the API Pod
The Client sends a request to the Service, which can route it to the API Pod when the Kubelet’s readiness check passes. That makes the Pod eligible for traffic, not guaranteed to receive every request.
Unready: removed from Service traffic
When the Kubelet’s readiness check fails, the Service stops treating the API Pod as an eligible endpoint, so requests aren’t sent there. The container keeps running, and it can rejoin traffic once readiness succeeds.
Liveness: restart an unhealthy container
The kubelet checks whether the API Pod’s container is alive. After repeated failures reach the configured failure threshold, it restarts the container. That’s different from readiness: liveness doesn’t just remove this Pod from Service traffic, and it doesn’t replace the whole Pod.
The API Pod fails readiness but passes liveness. What happens to its container and Service traffic?
Let's think this through. The API Pod fails readiness but passes liveness. What happens to its container and Service traffic? A: It restarts and continues receiving traffic. B: It keeps running but stops receiving Service traffic. C: It stops running until readiness passes. Choose an answer, or just think it through. I'll explain in a moment.
- It restarts and continues receiving traffic
- It keeps running but stops receiving Service traffic
- It stops running until readiness passes
The API Pod fails readiness but passes liveness. What happens to its container and Service traffic?
The answer is B: It keeps running but stops receiving Service traffic. Readiness controls whether the Service considers the Pod eligible for traffic. It does not restart the container; liveness is the check that can trigger a restart.
- It restarts and continues receiving traffic
- It keeps running but stops receiving Service traffic
- It stops running until readiness passes
Startup checks come first
As the API starts, the startup check runs first. Until it succeeds, readiness and liveness checks are held back. If failures reach the configured threshold, Kubernetes restarts the container; success lets the other checks begin.
Choose the question each probe answers
Readiness asks whether the API Pod can receive traffic, liveness whether it should keep running, and startup whether initialization is complete. Thresholds require repeated failures before a response.
- Ready to receive traffic?
- Still healthy enough to keep running?
- Finished starting up?
Traffic eligibility is not container health
Readiness determines traffic eligibility; liveness determines whether a container restarts; startup protects slow initialization by gating the other checks until it succeeds or triggers a restart.