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]>
1.8 KiB
Launch Lab: Perform a Rolling Update
Time to run a real rolling update against a real Deployment in your disposable Lab.
What you're doing
A Deployment app-v1 is running an older image version. Your task is to update it to a newer
version and confirm every replica ends up running the new image — exactly the mechanism from
the lesson and demonstration, on a real cluster this time.
Before you start
Recall the demonstration: kubectl rollout status is your tool for watching progress rather
than repeatedly polling kubectl get pods yourself, and a stalled rollout with no obvious error
usually means a new Pod can't become Ready. If your update seems to hang, that's exactly the
diagnostic instinct from the knowledge check to apply.
Your task in this Lab
Update the Deployment's image and verify all replicas are running the new version. Use
kubectl rollout status to confirm completion, not just a single kubectl get pods snapshot.
This Lab has its own in-context hints if you get stuck.
When you're done, return to this module for a short reflection on what "successfully rolled out" actually guarantees — and doesn't.
Instructor Notes
Classroom flow: A good moment to have students keep kubectl get pods --watch open in a
second terminal (if their Lab environment supports multiple panes) so they see the incremental
old-Pod/new-Pod transition happen live, reinforcing the demonstration.
Approximate timing: 10-15 minutes.
Common mistake to watch for: running kubectl edit deployment and forgetting to save/apply
correctly, or editing the wrong field (e.g. replicas instead of the container image) — a good
moment to reinforce reading the task description precisely rather than pattern-matching to a
similar-looking previous Lab.