ced4568andClaude Sonnet 5
28c925069b
content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/: lesson (probe concepts) -> demonstration (reading kubectl describe pod Events for a probe failure) -> knowledge check -> guided exercise (write a readiness probe on paper) -> Launch Lab intro (rootnode-probe-port-mismatch) -> reflection (root cause + Real Ops prevention takeaway). 5 of 6 activities carry instructor notes (demo plan, misconceptions, timing, discussion questions, extensions). This is the reference implementation docs/COURSE_AUTHORING_STANDARD.md documents for all future RootNode lesson authoring. Co-Authored-By: Claude Sonnet 5 <[email protected]>
48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
# Launch Lab: Stuck Not-Ready: The Probe Port Mismatch
|
|
|
|
Time to apply everything from this module against a real, running incident — not a diagram, an
|
|
actual Deployment in your own disposable Lab environment.
|
|
|
|
## What you're walking into
|
|
|
|
A deployment called `api-gateway` has been rolled out. The pods start, the container runs — but
|
|
the deployment never reaches Ready, and traffic isn't being routed to it. Somewhere on-call, an
|
|
alert is firing.
|
|
|
|
You now have everything you learned in this module to work with:
|
|
|
|
- **The lesson** told you what "stuck at 0/2 Ready with 0 restarts" actually means (a readiness
|
|
problem, not a crash).
|
|
- **The demonstration** showed you exactly where to look for the explanation — `kubectl get
|
|
pods`, then `kubectl describe pod` and its Events section — and what a port-mismatch failure
|
|
looks like in that output.
|
|
- **The guided exercise** had you reason through what a correct probe definition looks like,
|
|
which is exactly what you'll need to compare the broken one against.
|
|
|
|
## Your task in this Lab
|
|
|
|
Diagnose why the pods are failing their readiness check, correct the probe configuration, and
|
|
restore the deployment to fully Ready. Start with pod status and events, the same way you just
|
|
practiced — read before you patch.
|
|
|
|
This Lab has its own in-context hints if you get stuck, revealed one at a time — use the
|
|
concepts from this module first; reach for a hint only if you're genuinely stuck, not as the
|
|
first move.
|
|
|
|
When the Lab confirms your fix, come back to this module to close it out with a short
|
|
reflection on what actually caused this.
|
|
|
|
## Instructor Notes
|
|
|
|
**Classroom flow:** if teaching this live, this is the natural point to have students launch
|
|
their own Lab environment and work independently or in pairs, while you circulate. The
|
|
Real-Time Classroom dashboard's help-request and progress views (see the instructor Curriculum
|
|
view) show who's stuck without needing to walk around asking.
|
|
|
|
**Approximate timing:** 15-20 minutes for most students; some will resolve it in under 5 once
|
|
the module's concepts have landed.
|
|
|
|
**Common mistake to watch for:** students jumping straight to `kubectl logs` here, which will
|
|
be unhelpful (nginx has nothing to say about a probe pointed at the wrong port) — this is a good
|
|
moment to reinforce the demonstration's point about reading Events first for this failure class.
|