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]>
2.2 KiB
Knowledge Check: Deployments & Rollouts
1. A rolling update to a new image version has been "in progress" for 20 minutes with no
error message, and kubectl rollout status never returns. What's the first thing you should
check, and why?
Answer: kubectl get pods to see the new Pod's status, then kubectl describe pod on it if
it isn't Running. A stalled rollout with no explicit error almost always means a new Pod can't
become Ready — commonly ImagePullBackOff (bad image/tag) or a failing readiness probe. The
rollout isn't broken; it's correctly refusing to proceed until the new Pod proves healthy.
2. True or false: kubectl rollout undo restores your application from a backup of its
previous state.
Answer: False. It scales the previous (still-present, just scaled-to-zero) ReplicaSet back up and the current one back down — the same rolling mechanism as a forward update, just pointed at an older, already-proven-working Pod template. Nothing is being restored from storage.
3. A Deployment has replicas: 3. You need it to handle more traffic. Which is the correct
action: edit the Pod template's resource limits, or change the replica count? Justify your
answer for a stateless web application.
Answer: Change the replica count (scale out) for a stateless application handling more concurrent traffic — more identical copies sharing the load. Changing resource limits affects how much each individual Pod can use, not how many Pods exist; it doesn't add capacity for more concurrent requests the way scaling does.
4. Why does a Deployment keep an old, scaled-to-zero ReplicaSet around instead of deleting it immediately after a successful rollout?
Answer: That scaled-down ReplicaSet is exactly what makes fast, safe rollback possible later — deleting it immediately would mean a "rollback" would have to rebuild the old Pod template from scratch (or fail entirely) instead of simply scaling existing, already-defined Pods back up.
Instructor Notes
Facilitation: Question 1 is the most important one to discuss out loud — it's the exact diagnostic instinct students will need repeatedly in ROOT 10.
Approximate timing: 5 minutes.