Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Starting state: three ready Pods
New Pods become ready before old Pods leave. The Service currently routes traffic to three ready old Pods, so the Deployment needs to replace them without dropping below three ready replicas. It does that in controlled steps.
Create first; keep all three old Pods
With maxSurge set to one, the Deployment creates one extra Pod, temporarily bringing the count to four. With maxUnavailable at zero, it keeps all three old Pods available, and the Service continues routing to them while the new Pod starts.
Created does not mean ready
A created Pod isn't ready to serve traffic. Its readiness probe must pass before it becomes eligible for the Service endpoints, so creation alone doesn't put the new version in the traffic path.
One ready replacement; one old Pod removed
Once the first version two Pod is ready, the Service can route requests to it alongside the two old Pods. Kubernetes can then remove one old Pod, leaving three ready replicas.
The first new Pod is created but fails readiness. With zero unavailable replicas allowed, what happens to the three old Pods?
Let's think this through. The first new Pod is created but fails readiness. With zero unavailable replicas allowed, what happens to the three old Pods? A: They stay available while the rollout waits. B: One is removed immediately. C: All three are replaced at once. Choose an answer, or just think it through. I'll explain in a moment.
- They stay available while the rollout waits
- One is removed immediately
- All three are replaced at once
The first new Pod is created but fails readiness. With zero unavailable replicas allowed, what happens to the three old Pods?
The answer is A: They stay available while the rollout waits. A created Pod is not necessarily ready to serve traffic. Because the new Pod has not become a ready replacement, removing an old Pod would drop below the required three available replicas.
- They stay available while the rollout waits
- One is removed immediately
- All three are replaced at once
Repeat until every Pod runs the new version
Each arrow marks one completed replacement: a ready new Pod replaces an old one. The counts shift from three old, zero new, through one and two new, to three new, with a temporary surge Pod between displayed states.
What can pause the rollout?
A new Pod that fails readiness blocks safe removal of an old ready Pod. maxSurge one needs room for a fourth Pod; readiness can’t prevent all request failures.
- New Pod fails readiness
- No room for a surge Pod
- Healthy replicas are not a universal uptime guarantee
Ready replacement, then removal
A rolling Deployment coordinates replacement using readiness and surge/unavailable limits. One new Pod becomes ready before one old Pod leaves, preserving three ready replicas with maxUnavailable at zero.