Updating without downtime
Ship a new version, and undo it.
In plain terms
A rolling update is repainting a fence one plank at a time while people lean on it — never a gap — and the old paint is right there if you need to undo the colour.
live traffic → Ready pods only
scaling up (new pods starting)
draining (old pods terminating)
New pods must pass readiness before old ones are removed, so a broken version stalls instead of dropping traffic.
Shipping a new version should not mean taking the app down. A Deployment rolls out changes gradually — it starts new-version pods, waits for them to be healthy, and only then removes the old ones — so users never hit a gap.
terminal
$ kubectl set image deployment/web app=nginx:1.26 # ship a new version$ kubectl rollout status deployment/webWaiting for rollout to finish... 3 of 3 updateddeployment "web" successfully rolled out
Undo is one command
If the new version misbehaves, you do not scramble — the old version is kept, ready to restore. rollout undo puts everyone back on the previous version in seconds. Knowing rollback is this easy is what makes shipping feel safe.
terminal
$ kubectl rollout undo deployment/web # back to the previous version$ kubectl rollout history deployment/web # see the versions you can return to
Health checks make rollouts safe
A rollout waits for each new pod to report healthy before continuing — so a broken version stalls the rollout instead of replacing your good pods. You add those health checks in the “Health checks” topic.