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]>
55 lines
2.9 KiB
Markdown
55 lines
2.9 KiB
Markdown
# Guided Exercise: Planning a Safe Rollout Strategy
|
|
|
|
Paper-and-thinking exercise — work through this before the Lab.
|
|
|
|
## The scenario
|
|
|
|
Your team runs `api-server`, a Deployment with 6 replicas serving live traffic. You need to
|
|
ship a new image version. The team lead asks: "what could go wrong, and how would we know
|
|
before it takes down the whole service?"
|
|
|
|
## Your task
|
|
|
|
Work through these questions:
|
|
|
|
1. If the new image has a bug that crashes the container immediately on startup, at what point
|
|
in the rolling update would you expect to notice — after 1 new Pod, after all 6, or somewhere
|
|
in between? Why?
|
|
2. What's the difference in blast radius between that crash-on-startup bug and a subtler bug
|
|
that only fails under load, several minutes after a Pod starts serving traffic?
|
|
3. Given your answer to question 2, what's the practical value of watching `kubectl rollout
|
|
status` and `kubectl get pods` DURING a rollout, rather than only checking after it reports
|
|
"successfully rolled out"?
|
|
4. If you noticed a problem partway through, what's the single command that gets you back to
|
|
the last known-good state fastest?
|
|
|
|
## A worked answer to check yourself against
|
|
|
|
1. After the FIRST new Pod — a crash-on-startup bug means the new Pod never becomes Ready
|
|
(`CrashLoopBackOff`), so the rollout stalls immediately, well before more old Pods are
|
|
removed. This is actually the SAFEST kind of bug, because the blast radius stays tiny.
|
|
2. A crash-on-startup bug is naturally self-limiting (the rollout stalls itself, as above). A
|
|
bug that only appears under load is NOT self-limiting the same way — by the time it's
|
|
noticeable, several old (working) replicas may already have been replaced, meaning a larger
|
|
fraction of real traffic is already hitting the broken version.
|
|
3. Watching during the rollout, not just checking the final "successfully rolled out" message,
|
|
is what lets you catch the load-dependent case in question 2 early — waiting for the final
|
|
status alone would let the rollout complete entirely (100% on the broken version) before you
|
|
noticed anything wrong.
|
|
4. `kubectl rollout undo deployment/api-server` — assuming the previous ReplicaSet is still
|
|
present (the default), this is faster than trying to hand-diagnose and hot-fix the new
|
|
version under pressure.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 2's distinction (self-limiting vs. not) is the core insight worth
|
|
making sure lands — it's why "the rollout said success" is necessary but not sufficient
|
|
evidence that a deploy actually went well.
|
|
|
|
**Approximate timing:** 10-15 minutes live with discussion; 10 minutes self-paced.
|
|
|
|
**Optional extension:** ask what monitoring/observability signal (beyond `kubectl` output) a
|
|
real team would want during a rollout to catch the load-dependent case even faster (a good
|
|
forward pointer to ROOT 10's observability themes, without needing to build any actual
|
|
monitoring infrastructure here).
|