Rolling Updates & Rollbacks

Let's think about it this way for a second

If you switched every pod to a new version all at once (a recreate strategy), there could be a brief gap where nothing is around to handle traffic — that's why a Deployment's default strategy is 'RollingUpdate': it creates one new pod, waits for it to become Ready, then removes one old pod, and keeps doing that gradually until everything is switched over — users never notice a single moment of downtime. If a bug slips into the new version, `kubectl rollout undo` lets you instantly switch back to the previous version (Kubernetes keeps the last 10 revisions of deployment history by default).

Let's connect this to a real scenario

Something like `kubectl set image deployment/web-deployment web=my-app:v2` kicks off a rolling update as soon as you change the image version — you can track its progress with `kubectl rollout status`. If v2 turns out to have a bug, `kubectl rollout undo deployment/web-deployment` gets you back to v1 instantly — it's the go-to command in a production incident.

RollingUpdate = updating pods gradually, one at a time, with zero downtime
kubectl rollout status = watching the progress of an update
kubectl rollout undo = instantly switching back to a previous version

Let's look at it together

bash

# Update to a new image version (triggers rolling update)
kubectl set image deployment/web-deployment web=my-app:v2

# Watch the rollout happen
kubectl rollout status deployment/web-deployment

# See rollout history
kubectl rollout history deployment/web-deployment

# Something went wrong? Roll back instantly
kubectl rollout undo deployment/web-deployment

You should see

Waiting for deployment "web-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "web-deployment" successfully rolled out

5-Minute Try-It

Change web-deployment's image to a new version (for example, `nginx:alpine` to `nginx:latest`) and watch the rollout status — then switch it back with `rollout undo`.

A Quick Word of Caution

Be extra careful when pairing a rolling update with a breaking database schema change — during the window where old and new pods coexist, your code needs to support both schema versions at once.