Deployments and ReplicaSets That Roll Forward

Why this matters

A team ships on Fridays by applying a manifest and watching. When the new version breaks logins, recovery means finding the old manifest, editing the tag back, reapplying, and hoping nobody changed anything else since. Twenty minutes of archaeology under incident pressure. A Deployment keeps every revision it created, so recovery is a single recorded rollback to the previous ReplicaSet, and the history shows exactly which template serves traffic at any moment. The release is boring because the machinery remembers what humans forget.

Concepts

A Deployment owns ReplicaSets; each template change spawns a new ReplicaSet while the old ones are kept according to revisionHistoryLimit. The rolling strategy bounds disruption with two numbers: maxUnavailable (how many pods may be down) and maxSurge (how many extra pods may exist). Small values mean slow and safe; the defaults suit small services, and large fleets tune them against capacity and patience. Readiness gates the rollout: a new pod that never becomes ready blocks progress instead of taking traffic, which is exactly the behavior lesson 3 designs for.

Rollout status is a first-class query, not a feeling. The rollout history lists revisions with their templates, and a rollback simply points the Deployment back at a prior revision, which itself rolls out through the same surge and availability bounds. Two failure shapes to recognize: a rollout stuck on progress (new pods never ready, often a probe or image problem) and a rollout that completed but serves errors (bad code behind ready pods, caught by metrics, fixed by rollback first and diagnosis second).

Keep the history limit deliberate. The default of ten costs little and covers most incidents; raising it without bound clutters the object store for revisions nobody will ever restore. Annotate releases with a change cause so the history reads like a log instead of a hash list.

Worked example

The demo Deployment moves from v1 to a broken v2. The learner watches the rollout stall or serve errors, runs the status and history commands, and rolls back to the recorded previous revision. Traffic recovers through the same rolling bounds. The exercise repeats with a correct v3 to show the forward path: history grows, the old broken ReplicaSet scales to zero but stays listed until the history limit retires it.

Common wrong move

Deleting and recreating the Deployment to fix a bad rollout. That drops the revision history, restarts every pod at once, and turns a bounded rollback into an unbounded outage. Roll forward or roll back through the Deployment object; never around it.