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]>
2.3 KiB
Reflection: Rollback Is a Plan, Not a Panic Button
You just completed a real rolling update. Take a few minutes to connect it to how this plays out in a real production team.
Reflection questions
- "Successfully rolled out" (from
kubectl rollout status) tells you every replica is Running and Ready. What does it NOT tell you about whether the new version is actually correct? - If you were on-call and a rollout you just ran seemed to be causing problems, would you reach
for
kubectl rollout undoimmediately or try to hot-fix the new version first? What would change your answer? - Think back to the guided exercise's crash-on-startup vs. load-dependent distinction. Which one would a typical automated health check (like a readiness probe, ROOT 10) catch, and which one might slip through even with probes configured correctly?
Real Ops takeaway
A rollout completing is not the same as a deploy succeeding. "Every Pod is Running and
Ready" only proves the new code started up and passed whatever checks are configured — it says
nothing about whether the new version is functionally correct under real traffic. Real teams
pair a rollout with actual monitoring (error rates, latency) before calling a deploy genuinely
successful, not just a green kubectl rollout status.
Rollback should be a rehearsed, low-drama action, not a last resort. Teams that treat
kubectl rollout undo as a normal, expected tool — something you reach for calmly the moment
something looks wrong — recover from bad deploys in seconds. Teams that treat rollback as an
admission of failure hesitate, try to hot-fix forward under pressure, and turn a small,
recoverable mistake into a longer outage.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 2 is worth pushing on — many students' instinct is to try to fix forward, and it's worth surfacing WHY that instinct is often wrong under time pressure (unknown time-to-fix vs. known, fast rollback).
Approximate timing: 8-10 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to write the one-sentence Slack message they'd post to their team the moment they decide to roll back a bad deploy — reinforces that rollback is a normal, communicable operational action, not a private failure.