ced4568andClaude Sonnet 5
86ea035e9b
root-06-m02-deployments-scaling-updates — a new, full gold-standard- pattern module: why Deployments/ReplicaSets exist, how a rolling update actually progresses, and what rollback restores. Lesson, demonstration (a healthy rollout vs. one stalled on ImagePullBackOff), knowledge check, guided exercise (planning a safe rollout strategy), real Labs (rolling-update-task, deployment-rollback), and a reflection. root-06-m03-jobs-cronjobs-daemonsets — a new PARTIAL module: Jobs, CronJobs, and DaemonSets as distinct workload shapes from a Deployment's always-on model. Lesson + knowledge check + real Labs (job-task, cronjob-task). Co-Authored-By: Claude Sonnet 5 <[email protected]>
78 lines
3.2 KiB
Markdown
78 lines
3.2 KiB
Markdown
# Demonstration: Watching a Rollout, Good and Bad
|
|
|
|
## A healthy rollout
|
|
|
|
A Deployment `app-v1` running `nginx:1.24` at 3 replicas gets updated to `nginx:1.25`:
|
|
|
|
```
|
|
$ kubectl set image deployment/app-v1 nginx=nginx:1.25
|
|
deployment.apps/app-v1 image updated
|
|
|
|
$ kubectl rollout status deployment/app-v1
|
|
Waiting for deployment "app-v1" rollout to finish: 1 out of 3 new replicas have been updated...
|
|
Waiting for deployment "app-v1" rollout to finish: 2 out of 3 new replicas have been updated...
|
|
Waiting for deployment "app-v1" rollout to finish: 1 old replicas are pending termination...
|
|
deployment "app-v1" successfully rolled out
|
|
```
|
|
|
|
`kubectl rollout status` blocks and reports exactly the incremental progress described in the
|
|
lesson — this is your primary tool for watching (or scripting a wait on) a rollout, rather than
|
|
repeatedly polling `kubectl get pods` yourself.
|
|
|
|
## Checking revision history
|
|
|
|
```
|
|
$ kubectl rollout history deployment/app-v1
|
|
REVISION CHANGE-CAUSE
|
|
1 <none>
|
|
2 <none>
|
|
```
|
|
|
|
Revision 1 is the original ReplicaSet (now scaled to zero, still present); revision 2 is the
|
|
current one. This history is exactly what `kubectl rollout undo` uses.
|
|
|
|
## A stalled rollout
|
|
|
|
Now imagine the same update, but to a typo'd tag, `nginx:1.25-typo`, which doesn't exist:
|
|
|
|
```
|
|
$ kubectl rollout status deployment/app-v1
|
|
Waiting for deployment "app-v1" rollout to finish: 1 out of 3 new replicas have been updated...
|
|
```
|
|
|
|
...and it just sits there. `kubectl get pods` shows why:
|
|
|
|
```
|
|
$ kubectl get pods
|
|
NAME READY STATUS RESTARTS AGE
|
|
app-v1-7d8f9c6b5d-abcde 1/1 Running 0 5m
|
|
app-v1-7d8f9c6b5d-fghij 1/1 Running 0 5m
|
|
app-v1-9c5b7d8f6b-klmno 0/1 ImagePullBackOff 0 30s
|
|
```
|
|
|
|
The new Pod can never become Ready because its image can't even be pulled — so the rollout
|
|
correctly refuses to proceed further (removing more old Pods would reduce capacity for no
|
|
benefit, since the replacement will never come up). Nothing is "broken" in the platform; the
|
|
platform is behaving exactly correctly given bad input.
|
|
|
|
**The fix here is `kubectl rollout undo`, not waiting longer** — this exact scenario is what
|
|
`deployment-rollback`'s Lab, later in ROOT_, gives you real hands-on practice with.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo script:** If time allows, run the healthy rollout live against a throwaway Deployment,
|
|
then intentionally break the second one with a bad tag so students see `ImagePullBackOff` occur
|
|
in real time rather than only in static text.
|
|
|
|
**Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced.
|
|
|
|
**Common misconception to preempt:** students sometimes assume a stalled rollout will
|
|
eventually time out and auto-rollback on its own. By default it will not — a Deployment has no
|
|
automatic rollback trigger; a human (or automation) has to run `kubectl rollout undo` (or fix
|
|
the underlying issue) explicitly. This is worth stating directly since it's a genuine and
|
|
consequential production gotcha.
|
|
|
|
**Optional extension:** ask what `kubectl rollout status --timeout=2m` would change about this
|
|
scenario (answer: the command itself would exit with an error after 2 minutes instead of
|
|
blocking forever — useful in CI/CD pipelines that need to fail a deploy step rather than hang).
|