Rolling Update
A Deployment doesn't patch Pods — it replaces them. Declare a new version and it creates a new ReplicaSet, then takes an old Pod down only after a new one has finished starting. That ordering is why the available count never falls below what you declared for the whole rollout. Zero downtime isn't a special mechanism; it falls out of the order of operations.
01Rolling Update
Concept at a GlanceThree web servers are running v1. The Deployment hands that count to a ReplicaSet and watches it.
A new image is declared. Rather than patching the running Pods, the Deployment creates a second ReplicaSet for v2.
Nothing is swapped all at once. One new Pod comes up, and only once it is ready does one old Pod go down.
The new Pod finishes starting. With four alive, taking one old Pod down still leaves three.
The old Pod terminates as the next new one starts. The same handover repeats, once per Pod.
After the second handover the last Pod comes up. More than half the fleet is already on the new version.
The final old Pod goes down. All three declared Pods are now v2.
The emptied v1 ReplicaSet isn't deleted — it stays at zero, keeping a place to return to.
If the new version misbehaves, the same rule runs backwards: scale v1 up and v2 down.
Try it yourself
Declare a new version, then pause or rewind it midway. Just watch whether the bar below ever dips under the declared mark.
declared v1 · available 3 / 3 · Three v1 Pods are running · try declaring a new version
02 Understand It Simply
For EveryoneA new ReplicaSet is created and pods are swapped one at a time. A new pod becomes ready before an old one is taken down, so the available count never drops below the declaration, and the old ReplicaSet is kept at zero as a way back.
A Deployment keeps one ReplicaSet per version and only moves counts between them.
maxSurge is how far above the target it may temporarily go, maxUnavailable how far below, and together they set the pace.
Whether a new Pod counts as ready comes from its readiness probe — if that check is sloppy, traffic reaches Pods that can't serve yet.
The old ReplicaSet is kept at zero, which makes a rollback a matter of moving counts back rather than deploying afresh.
- –Choosing a deployment strategy (rolling
- –recreate
- –blue-green)
- –designing readiness probes
- –tuning maxSurge/maxUnavailable
- –and knowing the rollback path when something breaks
03 Frequently Asked Questions
FAQWhat is Rolling Update?+
A Deployment doesn't patch Pods — it replaces them. Declare a new version and it creates a new ReplicaSet, then takes an old Pod down only after a new one has finished starting. That ordering is why the available count never falls below what you declared for the whole rollout. Zero downtime isn't a special mechanism; it falls out of the order of operations.
Where is Rolling Update used?+
Choosing a deployment strategy (rolling, recreate, blue-green), designing readiness probes, tuning maxSurge/maxUnavailable, and knowing the rollback path when something breaks.
What's a simple analogy for Rolling Update?+
A new ReplicaSet is created and pods are swapped one at a time. A new pod becomes ready before an old one is taken down, so the available count never drops below the declaration, and the old ReplicaSet is kept at zero as a way back.