Files

T

ced4568andClaude Sonnet 5 86ea035e9b feat(root): author workloads curriculum

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]>

2026-08-26 09:06:00 -05:00

2.9 KiB

Raw Blame History

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:

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?
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?
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"?
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

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.
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.
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.
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).

2.9 KiB Raw Blame History