Files

T

ced4568andClaude Sonnet 5 28c925069b feat(root): author the health-probes gold-standard module

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]>

2026-08-25 23:29:32 -05:00

2.8 KiB

Raw Blame History

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:

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.)
What port and path should the probe target?
Roughly what initialDelaySeconds makes sense, given the database connection takes a couple of seconds?
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):

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).

2.8 KiB Raw Blame History Unescape Escape