How does a Kubernetes Deployment roll out new Pods without downtime?

How can Kubernetes replace these Pods without interrupting service? The Service currently routes requests to three ready Pods: Old A, Old B, and Old C. A rolling update brings replacements into service before removing those endpoints.

The updated Deployment creates a new ReplicaSet, using its one surge slot to start New D beside the three old Pods. With maxUnavailable at zero, all three old Pods stay ready, so the Service keeps routing to them.

Once New D passes its readiness check, the Service can route traffic to it alongside Old A, Old B, and Old C. That fourth ready Pod creates room to remove one old Pod without dropping the ready count below three.

Let's think this through. New D has started but is not ready. With zero unavailable Pods allowed, what happens to the three old Pods? A: All three keep serving. B: One is removed immediately. C: All three stop receiving traffic. Choose an answer, or just think it through. I'll explain in a moment.

The answer is A: All three keep serving. Starting a Pod does not make it ready to receive Service traffic. Removing an old Pod now would leave only two ready Pods, so the Deployment keeps all three while it waits for New D.

Once New D is ready, Old A leaves the Service’s endpoints and can terminate. The Service now routes to Old B, Old C, and New D, keeping three ready Pods available and freeing the surge slot for another replacement.

The rollout repeats the same overlap: bring each new Pod online before retiring an old one. Now the Service routes to New D, New E, and New F—the three new endpoints.

Keeping three Pods ready doesn't guarantee zero failed requests. Accurate readiness checks, capacity for the surge Pod, and graceful shutdown for in-flight requests make the handoff reliable.

A rolling update overlaps old and new ReplicaSets, scaling each within surge and availability limits. Readiness before retirement leaves the Service with three new ready Pods.