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]>
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
# 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.
|