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]>
40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
# 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.
|