Kubernetes Rolling Update Availability

A rolling update overlaps old and new Pods, replacing old ones gradually as new Pods become ready.

The Client sends requests through the Service to three ready v1 Pods: v1 A, v1 B, and v1 C. In this rollout, one extra Pod is allowed, and none of these three ready replicas can be lost.

The Deployment can start v2 D alongside v1 A, v1 B, and v1 C because maxSurge allows one extra Pod. Until v2 D passes its readiness probe, the Service keeps routing requests to the three ready v1 Pods; the new Pod gets no traffic.

Readiness is the handoff point: once v2 D passes its probe, the Service can route requests to it alongside v1 A, v1 B, and v1 C, letting Kubernetes remove an old Pod while keeping three ready replicas.

Let's think this through. The new Pod is running but has not passed readiness. Which Pods should receive Service traffic? A: Only the three ready old Pods. B: All four Pods immediately. C: Only the new Pod. Choose an answer, or just think it through. I'll explain in a moment.

The answer is A: Only the three ready old Pods. Running does not necessarily mean ready to serve. The Service continues routing to the three ready old Pods; the new Pod joins its eligible endpoints after it passes readiness.

Each time a replacement passes readiness, Kubernetes can remove one old Pod and create the next v2 Pod. When the cycle finishes, the Service routes Client requests to three ready v2 Pods: v2 D, v2 E, and v2 F.

The overlap needs capacity for an extra Pod, accurate readiness, and settings that preserve enough ready replicas. That maintains replica availability, not uninterrupted individual requests.

A rolling update overlaps old and new replicas; readiness determines when new Pods can receive Service traffic. Gradual replacement leaves three ready v2 Pods.