Kubernetes Rolling Updates
Learn how Deployments replace old pods gradually, what maxSurge and maxUnavailable do, and how old ReplicaSets support safe transitions.
What Is a Rolling Update?
A rolling update replaces old pods with new ones gradually instead of dropping everything at once. That reduces downtime risk.
Default Strategy
Deployments use the RollingUpdate strategy by default.
Two important tuning fields are:
maxSurgemaxUnavailable
What These Fields Mean
| Field | Meaning |
|---|---|
maxSurge | How many extra pods can be created above the desired replica count during the rollout |
maxUnavailable | How many existing pods can be unavailable during the rollout |
Update the Image Imperatively
kubectl set image deployment/web nginx=nginx:1.28
kubectl rollout status deployment/web
Rolling Update Wave
Desired replicas: 4
Old RS: [A][A][A][A]
New RS: [ ][ ][ ][ ]
Wave 1: create 1 new, remove 1 old
Old RS: [A][A][A]
New RS: [B]
Wave 2:
Old RS: [A][A]
New RS: [B][B]
Wave 3:
Old RS: [A]
New RS: [B][B][B]
Wave 4:
Old RS: [ ]
New RS: [B][B][B][B]
Why the Old ReplicaSet Is Kept
Kubernetes usually keeps the old ReplicaSet, often scaled to 0, so rollback is faster and rollout history remains available.
A Safer Deployment Habit
kubectl set image deployment/web nginx=nginx:1.28
kubectl rollout status deployment/web
kubectl get rs
This lets you confirm the new rollout before moving on.
Rolling updates are like swapping airplane passengers section by section instead of pushing everyone out at once. Controlled change lowers risk.
maxSurge Purpose
What does `maxSurge` control during a rolling update?
Old ReplicaSet Reason
Why does Kubernetes usually keep the old ReplicaSet after a rollout?