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]>
1.9 KiB
Knowledge Check: Choosing the Right Workload Primitive
1. You need to run a database migration script exactly once when a new version deploys. Which primitive fits, and why not a Deployment?
Answer: A Job. A Deployment expects its Pods to run forever and replaces any that exit; a migration script is supposed to exit successfully when done, which a Deployment would treat as a failure to "fix" by restarting it — the wrong behavior for a task that's supposed to finish.
2. A CronJob scheduled for "every 5 minutes" keeps creating Jobs that fail immediately due to a bad image tag. What actually happens over the next hour if nobody notices?
Answer: A new failing Job (and its Pod) gets created roughly every 5 minutes, accumulating failed Job/Pod objects and consuming cluster resources — nothing stops this automatically. This is exactly the kind of slow, easy-to-miss resource exhaustion a real on-call engineer should watch for.
3. True or false: a DaemonSet's Pod count scales with a replicas field, the same as a
Deployment.
Answer: False. A DaemonSet has no replicas field — its Pod count is implicitly "one per
matching node," and it grows or shrinks automatically as nodes join or leave the cluster.
4. You need a log-shipping agent that must run on every node, including any new node added later. Which primitive, and what would go wrong if you used a Deployment with a high replica count instead?
Answer: A DaemonSet. A Deployment's replicas are placed by the scheduler wherever it decides is best — nothing guarantees one per node, and a newly-added node wouldn't automatically get a copy the way a DaemonSet guarantees.
Instructor Notes
Facilitation: Question 2 is worth emphasizing — it's a genuinely realistic "how does a cluster quietly get into trouble" scenario, not just trivia.
Approximate timing: 5 minutes.