Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Three probes, three different decisions
The same API container can be running but not ready for traffic, or still booting. The kubelet uses three probes for separate decisions: startup asks whether boot finished, readiness whether traffic should reach it, and liveness whether it should restart.
Startup failure: wait, then restart
The API can keep booting while its startup probe fails; Kubernetes retries until the configured threshold is reached, then restarts the container. Readiness and liveness checks stay disabled until startup succeeds, so they can’t interrupt this boot phase.
Readiness failure: stop new Service routing
After startup succeeds, an API dependency outage can make readiness fail. Kubernetes marks the API Pod not ready and removes it from Service endpoints, so new requests aren’t routed there. The container keeps running.
Liveness failure: restart the container
Readiness failure removes the Pod from Service endpoints; liveness failure makes a different decision. For this API, repeated liveness failures reaching the configured retry limit cause the kubelet to restart the container. Use liveness for problems a restart could remedy.
The API is running, but its readiness check keeps failing. What does Kubernetes do?
Let's think this through. The API is running, but its readiness check keeps failing. What does Kubernetes do? A: Restart the container immediately. B: Exclude the Pod from Service endpoints. C: Disable liveness checks until readiness recovers. Choose an answer, or just think it through. I'll explain in a moment.
- Restart the container immediately
- Exclude the Pod from Service endpoints
- Disable liveness checks until readiness recovers
The API is running, but its readiness check keeps failing. What does Kubernetes do?
The answer is B: Exclude the Pod from Service endpoints. Readiness controls whether the Pod receives traffic through a Service. Its failure does not by itself restart the container; liveness handles that decision.
- Restart the container immediately
- Exclude the Pod from Service endpoints
- Disable liveness checks until readiness recovers
Illustrative Pod probe configuration
The API’s startup probe checks /startup every ten seconds, allowing thirty failures before Kubernetes restarts the container. That isn’t a guaranteed boot-time window. Readiness checks /ready for Service eligibility; liveness checks /live for restart decisions.
startupProbe:
httpGet: {path: /startup, port: 8080}
periodSeconds: 10
failureThreshold: 30
readinessProbe:
httpGet: {path: /ready, port: 8080}
livenessProbe:
httpGet: {path: /live, port: 8080}Two important boundaries
A probe failure doesn’t trigger action immediately; Kubernetes waits for the configured failure threshold. Readiness removes the Pod from Service endpoints, but existing connections may continue.
- Failure takes repeated unsuccessful checks
- Endpoint removal need not close existing connections
Boot, traffic, recovery
These are distinct decisions, not three levels of one health score. Startup failures eventually restart the container; readiness failures remove Service traffic eligibility; liveness failures restart it.