Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Part 1
Kubernetes holds traffic back until a new Pod reports Ready. Here, users send requests to web-svc, and web-svc routes only to Pod v1. Pod v2 already exists, but it's not connected yet. The Service waits until v2 says it can actually serve.
Pod v2 lifecycle
Follow Pod v2 left to right. It's scheduled to a node, the image is pulled, and the container starts. But the app is still warming up, loading config and connecting to the database. Only when the probe passes does the Pod become Ready.
Running means the process started. Ready means it can serve.
Running only tells you the process started. Ready means it can actually serve, and requests sent during warm-up would fail or time out.
Readiness probe on Pod v2
The kubelet on the node asks Pod v2 GET /ready, every few seconds. While the app is still loading, it answers 503, so nothing changes. The kubelet simply tries again. Once the answer is 200 OK, the kubelet reports to the API Server that Pod v2 is Ready.
Ready status updates the Service
Once the API Server records Pod v2 as Ready, the endpoints controller notices and asks the API Server to add v2's address to web-svc's endpoints. That change is announced, and kube-proxy updates its routing rules. There's a small propagation delay, and that's normal. After that, requests can reach v2.
Pod v2's container is running, but its ready endpoint still returns 503. Where do user requests to web-svc go?
Pod v2's container is running, but its ready endpoint still returns 503. Where do user requests to web-svc go?
- Only to Pod v1
- Split between Pod v1 and Pod v2
- Held in a queue until Pod v2 is ready
Pod v2's container is running, but its ready endpoint still returns 503. Where do user requests to web-svc go?
Only to Pod v1. A failing readiness check keeps Pod v2 out of the Service's endpoints list, so the Service only knows about Pod v1. Kubernetes does not queue requests for a Pod; it simply routes to whichever Pods are currently Ready.
- Only to Pod v1
- Split between Pod v1 and Pod v2
- Held in a queue until Pod v2 is ready
Pod v2 joins the Ready list
Once /ready returns 200, the kubelet marks Pod v2 Ready, and it joins web-svc's endpoints. Now requests from users reach both Pod v1 and Pod v2. A Service only routes traffic to Pods on its Ready list. That's the whole rule.
When readiness is not confirmed
When the probe fails, v2 stays off the Service list, v1 keeps serving everyone, and the rollout simply waits. With no probe, v2 counts as Ready the moment its container starts, so users can hit errors while the app is still warming up.
Ready first, traffic second
Ready first, traffic second. A started container isn't necessarily able to serve, and Services only route to Ready Pods. So give every app a readiness probe that checks it can truly serve.





