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]>
3.2 KiB
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).