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]>
62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
# Guided Exercise: Configure a Readiness Probe
|
||
|
||
This is a paper-and-thinking exercise, not a Lab task — you won't run these commands against a
|
||
real cluster here (that comes next). The goal is to practice reading and writing a probe
|
||
definition correctly before you're diagnosing someone else's broken one.
|
||
|
||
## The scenario
|
||
|
||
You're deploying a small HTTP API that listens on port `3000` and exposes a health endpoint at
|
||
`/healthz`. It takes a couple of seconds to finish connecting to its database on startup — if a
|
||
request arrives before that finishes, it correctly returns a `503` at `/healthz` until it's
|
||
ready.
|
||
|
||
## Your task
|
||
|
||
Work out, on paper (or in a scratch file), what you'd write for this container's readiness
|
||
probe. Think through:
|
||
|
||
1. Which mechanism fits — `httpGet`, `tcpSocket`, or `exec`? (Hint: you have a real health
|
||
endpoint that returns a meaningful status code — use it rather than a shallower check.)
|
||
2. What `port` and `path` should the probe target?
|
||
3. Roughly what `initialDelaySeconds` makes sense, given the database connection takes a couple
|
||
of seconds?
|
||
4. Should this be a `readinessProbe`, a `livenessProbe`, or both? Justify your answer using the
|
||
distinction from the lesson — what actually goes wrong if you get this specific choice wrong
|
||
here?
|
||
|
||
## A worked shape to check yourself against
|
||
|
||
Your answer should end up structurally similar to this (exact field names matter more than the
|
||
precise numbers you chose):
|
||
|
||
```yaml
|
||
readinessProbe:
|
||
httpGet:
|
||
path: /healthz
|
||
port: 3000
|
||
initialDelaySeconds: 3
|
||
periodSeconds: 5
|
||
```
|
||
|
||
If you reached for `livenessProbe` instead of `readinessProbe` for this specific scenario,
|
||
re-read the lesson's distinction before continuing — "returns 503 while warming up" is
|
||
precisely the readiness case, not the liveness case. A liveness probe here would restart a
|
||
perfectly healthy, still-starting container over and over, which never lets it finish starting.
|
||
|
||
## Instructor Notes
|
||
|
||
**Facilitation:** Have students write their probe block on paper or a shared doc before showing
|
||
the worked shape — resist showing the answer early, since the value here is in students
|
||
committing to an answer and comparing, not passively reading a correct one.
|
||
|
||
**Approximate timing:** 10-15 minutes live with discussion; 10 minutes self-paced.
|
||
|
||
**Common mistake to watch for:** choosing `livenessProbe` because "the app isn't healthy yet"
|
||
— this is the single most common real-world probe mistake and exactly what question 4 is
|
||
designed to surface before the next activity's real diagnostic task.
|
||
|
||
**Optional extension:** ask what would need to change in this same YAML if the health endpoint
|
||
took up to 60 seconds to become available on cold start (answer: a `startupProbe` with a
|
||
generous `failureThreshold` × `periodSeconds`, so liveness/readiness don't engage too early).
|