Free lesson · CKAD Prep Program · Module 3: Application deployment

Manage Rollouts, Pauses and Rollbacks

Deployments ship new images without downtime when the strategy is set and the probes are honest. This lesson practices the full lifecycle: roll, watch, pause, and retreat with history intact.

11 min reading

Objectives

Run a rolling update that keeps serving through maxSurge plus maxUnavailable
Pause a rollout mid-flight, inspect, then resume or roll back
Read rollout history and return to any recorded revision
Say when rollback is wrong and rollout forward is right

Why this matters

Every production deploy is a rollout, and every bad deploy becomes either a pause or a rollback. The exam tests the commands, but the real skill is the sequence: change, observe the new replicas against readiness, decide with data. Rollouts fail messily exactly when steps get skipped.

Concepts

A rolling update replaces pods gradually within two bounds: maxSurge caps how many extra pods may exist above the replica count, maxUnavailable caps how many may be down. Sane defaults (25 percent each, or explicit small numbers for small fleets) keep capacity serving throughout. The strategy sits in the Deployment spec, so it is versioned with everything else.

kubectl rollout pause freezes the update with old and new replicas side by side: the moment to run smoke checks against the new pods before they take all traffic. kubectl rollout resume continues; kubectl rollout undo returns to the previous revision, and --to-revision=N picks any recorded one. kubectl rollout history lists revisions (with --revision detail), and --record era commands are gone: modern history comes from the revision annotations the controller keeps.

Rollback is not always the answer. A failed data migration does not un-run by restoring the old image; a bad config shared by both revisions rolls back into the same failure. Retreat when the new revision is the problem and the old one is known good; roll forward when the fix is small and the old state cannot return.

Worked example

Ship image 2.5 over 2.4, watch, pause, decide:

kubectl set image deployment/web web=web:2.5
kubectl rollout status deployment/web
kubectl get pods -w  # new replicas appear, old drain away
# doubt? freeze it
kubectl rollout pause deployment/web
kubectl exec deploy/web -- wget -qO- localhost:8080/healthz
kubectl rollout resume deployment/web   # healthy: continue
# or: kubectl rollout undo deployment/web  # sick: retreat
kubectl rollout history deployment/web

The pause window is where judgment lives: real traffic-shaped checks against the new pods, not staring at phases.

Exam notes

Without readiness probes the rollout declares victory while new pods crash: probes make rolling updates truthful. rollout undo without arguments returns one step; chain it deliberately rather than assuming depth. And paused rollouts block further image changes until resumed or undone, which reads as a stuck deploy if you forget the pause.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Exercise

Write the command sequence for shipping a new image with a mid-rollout health gate: set image, watch, pause, one exec check with its expected output, then both branches (resume and undo). State what the exec check proves and what flips your decision.

Pass criteria

Sequence complete with pause before the decision; exec check names a concrete endpoint plus expected output; resume and undo branches each tied to the check result.