Orchestration Core
Rolling updates & rollbacks
Lesson 3 of 5
What you'll learn
- Understand how a Deployment swaps ReplicaSets to ship a new version
- Read maxSurge and maxUnavailable as the two knobs governing update pace
- Know why rollback is cheap: the old ReplicaSet is still there
When you change a Deployment's Pod template — typically a new image tag — Kubernetes does not delete everything and recreate it. It performs a rolling update: a new ReplicaSet scales up while the old one scales down, a few Pods at a time, so the service stays available throughout.
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # how many extra Pods above desired during the roll
maxUnavailable: 0 # how many below desired we tolerate at any moment
The two knobs
maxSurge caps how many Pods above the desired count may exist mid-update; maxUnavailable caps how many below it. With maxUnavailable: 0 you never dip below capacity (at the cost of briefly running extra Pods). With maxSurge: 0 you replace in place but temporarily run hot below target. These two numbers fully determine the safety and speed of every roll.
kubectl set image deploy/api api=myorg/api:1.5.0
kubectl rollout status deploy/api
Rollback is just another reconcile
Because the previous ReplicaSet is retained (scaled to zero), reverting is instant — Kubernetes scales the old one back up and the new one down using the same loop.
kubectl rollout undo deploy/api
Set maxUnavailable deliberately
The default maxUnavailable: 25% can drop a quarter of your capacity mid-roll. For latency-sensitive services, pin it to 0 and pair with a sane maxSurge so you never serve below target.
Run it. Each tick adds new Pods up to the surge ceiling and removes old ones, never violating maxUnavailable.
Why is rolling back a Deployment fast and cheap?
Saved on this device. Sign in to sync your progress everywhere.