Rolling Updates & Rollbacks

In one line

A Deployment's default rolling update replaces pods gradually to avoid downtime — and if the new version turns out to be broken, rolling back to the previous working version is a single, fast command.

0/4 · 0%

Key ideas

01
Topic 1.1 already mentioned that updating a Deployment's image triggers a rolling update automatically — this topic covers exactly HOW that works, and critically, how to reverse it fast when the new version turns out to be broken.
02
A ROLLING UPDATE works by gradually creating NEW pods (on a new ReplicaSet, Topic 1.1) while gradually terminating OLD ones, controlled by two settings: maxSurge (how many EXTRA pods beyond the desired count are allowed temporarily, to speed up the rollout) and maxUnavailable (how many pods are allowed to be unavailable at once during the transition) — the defaults (25% each) balance rollout speed against maintaining availability throughout.
03
Kubernetes keeps a REVISION HISTORY of a Deployment's past states specifically to make rollback possible — kubectl rollout history deployment/<name> shows every past revision, and kubectl rollout undo deployment/<name> reverts to the immediately previous one in a single command, itself performing a normal rolling update BACK to the old, known-working ReplicaSet.
04
A rollout only considers a new pod truly 'up' once it passes its READINESS PROBE (Phase 0.3) — this is precisely why a correctly configured readiness probe matters so much for a safe rollout: without one, Kubernetes might consider a pod 'ready' the instant its container process starts, even if the application inside is still initializing and genuinely not ready to serve real traffic yet.
05
kubectl rollout status deployment/<name> watches a rollout live and reports when it's genuinely complete (or if it's stuck) — a rollout can get stuck indefinitely if new pods keep failing their readiness probe, which Kubernetes will keep retrying rather than ever declaring the rollout complete, a genuinely useful safety property that prevents a broken new version from ever fully replacing a working old one.
06
kubectl rollout undo deployment/<name> --to-revision=<N> rolls back to a SPECIFIC past revision, not just the immediately previous one — genuinely useful if a problem wasn't actually caused by the most recent change, but by one a few revisions back that's only now surfacing under specific conditions.

Code & diagrams

RollingUpdateProgressdiagram

Old and new pods coexist briefly — traffic never has zero healthy pods to reach.

Rendering diagram…

rollouts.shmarkdown

Trigger, watch, break on purpose, and recover from a rollout.

# Trigger a rolling update by changing the image
kubectl set image deployment/my-app my-app=my-registry/my-app:1.6.0

# Watch it live — reports success, or shows it's stuck
kubectl rollout status deployment/my-app

# See every past revision
kubectl rollout history deployment/my-app

# Deliberately roll out something broken, to practice recovering
kubectl set image deployment/my-app my-app=my-registry/my-app:1.7.0-broken
kubectl rollout status deployment/my-app
# ^C after a while if it's clearly stuck — new pods failing readiness

# Roll back to the previous, known-good revision — one command
kubectl rollout undo deployment/my-app
kubectl rollout status deployment/my-app
# back to 1.6.0, healthy again

# Roll back to a SPECIFIC older revision instead of just "the previous one"
kubectl rollout undo deployment/my-app --to-revision=1

Explain it without notes

Why does a broken new version's rollout typically get stuck rather than fully replacing every old pod immediately?

What's actually happening, mechanically, when you run kubectl rollout undo — is it literally 'going back in time,' or something else?

Practice

Perform a real rolling update on a test Deployment (even with a trivial image tag change) and watch kubectl rollout status report its progress.

Deliberately roll out a broken image (one that fails its readiness probe, or crashes immediately), observe the rollout get stuck, and use kubectl rollout undo to recover.

Trade-offs

↔
The default rolling update strategy prioritizes availability (never dropping below a configured minimum of healthy pods) at the cost of BOTH versions briefly coexisting during the transition — for an application where that brief coexistence is genuinely unacceptable (an incompatible database schema change mid-rollout, for instance), a different deployment strategy entirely (blue-green, or careful migration sequencing) is needed, a topic a dedicated CI/CD or GitOps course would cover in more depth than this Kubernetes-focused course does directly.

Done when you can

I understand how maxSurge and maxUnavailable control a rolling update's behavior.
I know a rollout relies on readiness probes to determine when new pods are genuinely healthy.
I can use kubectl rollout undo to roll back to the previous or a specific past revision.