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]>
46 lines
1.9 KiB
Markdown
46 lines
1.9 KiB
Markdown
# 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.
|