# Why Deployments Exist & How a Rolling Update Progresses

## The problem a bare Pod doesn't solve

A Pod, on its own, has no self-healing and no concept of "there should be more than one of
these." If a Pod crashes, nothing recreates it. If you need 3 copies for capacity, you'd have to
create 3 separately-named Pods by hand and keep track of all of them yourself. If you need to
update the container image, you'd have to delete and recreate every one of them manually,
almost certainly causing a visible outage while you do it.

**A Deployment solves all three problems at once**: it declares how many replicas of a Pod
template should exist, keeps that count true continuously (the exact desired-state mechanism
from ROOT 05), and knows how to change the Pod template over time — a version upgrade — without
just deleting everything and starting over.

## ReplicaSets: the layer underneath, briefly

You'll rarely touch a ReplicaSet directly, but understanding it clarifies what a Deployment
actually does. A Deployment doesn't manage Pods directly — it manages a ReplicaSet, which is
what actually keeps N Pods matching a label selector running. When you update a Deployment's
Pod template (like changing the image), the Deployment creates a NEW ReplicaSet with the new
template and gradually shifts replicas from the old ReplicaSet to the new one. The old
ReplicaSet isn't deleted — it's scaled to zero and kept around, which is exactly what makes
rollback possible (more on that below).

## How a rolling update actually progresses

By default, a Deployment updates using the `RollingUpdate` strategy: it doesn't take all old
Pods down and bring all new ones up at once (that would cause an outage). Instead, it
incrementally creates new-version Pods and removes old-version ones, always keeping enough
capacity available:

```
Before:  [v1] [v1] [v1]
Step 1:  [v1] [v1] [v1] [v2]      <- one new Pod created
Step 2:  [v1] [v1] [v2]           <- one old Pod removed once new one is Ready
Step 3:  [v1] [v1] [v2] [v2]
Step 4:  [v1] [v2] [v2]
...
After:   [v2] [v2] [v2]
```

Crucially, a new Pod only counts as "up" for the purposes of proceeding once it passes its
readiness probe (see ROOT 10's gold-standard module) — this is exactly why a misconfigured
readiness probe can make a rollout hang indefinitely instead of failing fast: Kubernetes is
correctly waiting for a "ready" signal that will never come.

## Rollback: what it actually restores

`kubectl rollout undo` doesn't magically know how to "undo" arbitrary changes — it works because
of the old ReplicaSet still sitting around at zero replicas, from the mechanism described above.
Rolling back means: scale the OLD ReplicaSet back up and the current (broken) one back down,
using the exact same rolling mechanism as a forward update. This is why rollback is fast and
safe — it's not a special operation, it's the same well-tested rolling-update machinery running
in reverse, against a Pod template that's already known to have worked before.

## Instructor Notes

**Approximate timing:** 15 minutes read, 10-12 minutes live with the ReplicaSet diagram.

**Demo plan:** Draw (or show) the ReplicaSet-swap diagram above on a whiteboard before the
demonstration activity — students who see the "old ReplicaSet scaled to zero, not deleted"
detail up front connect rollback to rollout much faster.

**Likely misconceptions to watch for:**
- Students often think rollback "restores a backup" or reverts a Git-style diff. Correct this:
  it's scaling an existing (still-present) ReplicaSet back up, nothing is being restored from
  storage.
- "Rolling update" is sometimes assumed to mean "one Pod at a time, always." The actual pace is
  controlled by `maxSurge`/`maxUnavailable` (not covered in depth here, but worth naming so
  students don't over-generalize from the simplified diagram).

**Discussion question:** "Why does a rolling update need readiness probes to work correctly,
specifically?" (Answer: without a readiness signal, Kubernetes has no way to know when a new
Pod is actually safe to receive traffic before removing an old one — it would either guess via a
fixed delay, unreliable, or not wait at all, unsafe.)

**Optional extension:** ask what would happen to an in-progress rollout if the new image simply
doesn't exist (a typo in the tag) — a good bridge to real troubleshooting: the rollout stalls
indefinitely with `ImagePullBackOff` on the new Pods, never completing and never rolling back on
its own.