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]>
44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
# 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
|
|
|
|
1. "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?
|
|
2. If you were on-call and a rollout you just ran seemed to be causing problems, would you reach
|
|
for `kubectl rollout undo` immediately or try to hot-fix the new version first? What would
|
|
change your answer?
|
|
3. 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.
|