Rolling back a bad Deployment

WHAT THIS TESTS Incident response under pressure: can you revert a release quickly and explain why it works without magic.

A GOOD ANSWER COVERS The command is kubectl rollout undo deployment/NAME. To target a specific revision, add --to-revision=N, where revision numbers come from kubectl rollout history deployment/NAME. The mechanism reuses the retained ReplicaSets: when the new release was rolled out, the previous ReplicaSet was scaled to zero but not deleted. Undo triggers a fresh rolling update that scales that old ReplicaSet back up and the faulty one down, respecting the same maxSurge and maxUnavailable settings.

COMMON WRONG ANSWERS Thinking rollback rebuilds or re-pulls images from scratch; it reuses the already-recorded pod template. Believing it restores database state or persistent volumes; rollback only affects the workload spec, not data. Forgetting that you can only revert as far back as revisionHistoryLimit retains.

LIKELY FOLLOW-UPS How do you list past revisions? kubectl rollout history. What if the prior revision is also broken? Target an even earlier one with --to-revision. How do you prevent bad rollouts? Readiness probes plus progressDeadlineSeconds to fail and pause automatically.

ONE CONCRETE EXAMPLE Version 2 ships and error rates spike. You run kubectl rollout undo deployment/webapp. Kubernetes scales the version-1 ReplicaSet from zero back to three and the version-2 ReplicaSet down to zero, Pod by Pod. Within seconds traffic returns to the healthy version, and kubectl rollout history records the undo as a new revision.