Fig 5Rolling updateRelease, break and roll back belowv1 rolled out · 6 ready · 6 pods
maxSurge 2maxUnavailable 1
Rollout complete: 6 of 6 pods run v1.
Crate lamp: blinks while starting, steady once its readiness probe passesPods, stencilled with the version of the image they runRollout gauge: pods slider stops at replicas + maxSurge, ready slider at replicas − maxUnavailableService: requests go only to ready pods, so the rollout causes no downtimeA Deployment keeps one ReplicaSet per version. On a rolling update the controller scales the new ReplicaSet up and the old one down, inside two limits shown on the gauge: total pods may rise to replicas + maxSurge, and ready pods may fall to replicas − maxUnavailable, never further. A new pod counts as available only once its readiness probe passes, so a broken image whose pods crash-loop stops the rollout at that floor: the old pods keep serving and the Deployment reports ProgressDeadlineExceeded. kubectl rollout undo switches the template back to the previous revision, and the same rules carry it back.