Deployment Rolling Update
How do you move every Pod to a new version without taking the app offline? A Deployment rolls the change out gradually, bringing up new-version Pods within its surge budget and retiring old ones as replacements report Ready, so the Service stays backed. The maxSurge and maxUnavailable dials both default to 25%, which at 3 replicas rounds up to a surge of 1 and down to 0 unavailable, and only at maxUnavailable 0 does an old Pod stay until its replacement serves.
Play the animation 6 steps, animated, best on a wide screen
Deployment Rolling Update, step by step
-
You run kubectl set image deployment/web app=v2.0, which PATCHes .spec.template. The Deployment hashes that template into a new pod-template-hash and creates a second ReplicaSet, RS-v2, already at replicas 1, the one surge slot the 25% maxSurge allows. RS-v1 still owns all 3 live Pods.
Play from step 1 -
RS-v2 wants 1 replica and owns no Pod yet, so the ReplicaSet controller creates one through the API, in the RS-v2 column. No old Pod has to leave first, because the create already spent the surge slot: the fleet runs to 4 live Pods, one over .spec.replicas, while the new one starts.
Play from step 2 -
The new Pod passes its readinessProbe and RS-v2 reports Ready 1. At the default minReadySeconds 0 it counts as available at once. With maxUnavailable 0 the Deployment may not touch RS-v1 until a replacement is Ready, which is what keeps 3 Pods serving throughout.
Play from step 3 -
Only now does the Deployment scale RS-v1 from 3 to 2 through the API, and RS-v1 deletes one old Pod, which enters graceful termination. Terminating Pods do not count as available, so the 3 that maxUnavailable 0 requires are the 2 old Ready Pods plus the new one.
Play from step 4 -
The same trio runs again for the second replica. RS-v2 goes to 2 and the new Pod starts in the next slot, and only once it reports Ready does RS-v1 drop to 1 and let another old Pod go. The window of live Pods has slid one slot to the right and never narrowed below 3.
Play from step 5 -
The last replica crosses the same way. RS-v2 reaches 3 Ready and RS-v1 ends at replicas 0, kept up to revisionHistoryLimit so kubectl rollout undo can roll back. With no old Pod running the rollout is complete: Available=True and Progressing NewReplicaSetAvailable.
Play from step 6