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]>
57 lines
2.6 KiB
Markdown
57 lines
2.6 KiB
Markdown
# Knowledge Check: Health Probes
|
|
|
|
Answer each question yourself before reading the answer that follows it. This isn't graded —
|
|
it's a checkpoint to catch a misunderstanding before you're troubleshooting a live Pod in the
|
|
next activity.
|
|
|
|
---
|
|
|
|
**1. A Pod shows `RESTARTS: 12` and `READY: 1/1`. What kind of probe failure, if any, is most
|
|
consistent with this?**
|
|
|
|
*Answer:* A liveness probe that was failing and has now recovered (or is intermittently
|
|
failing) — the climbing restart count is the signature of liveness failures, since a failed
|
|
liveness check causes the kubelet to kill and restart the container. `READY: 1/1` means it's
|
|
currently passing its readiness check right now.
|
|
|
|
---
|
|
|
|
**2. A Pod shows `RESTARTS: 0` and `READY: 0/1`, and has looked this way for several minutes.
|
|
What kind of probe failure is most consistent with this?**
|
|
|
|
*Answer:* A readiness probe that is failing. The container is running fine (no restarts), but
|
|
Kubernetes has decided it isn't ready to receive traffic and has excluded it from the Service's
|
|
endpoints. This is exactly the symptom you'll investigate in this module's lab.
|
|
|
|
---
|
|
|
|
**3. Why does Kubernetes offer a separate startup probe instead of just making
|
|
`initialDelaySeconds` on the liveness probe longer?**
|
|
|
|
*Answer:* `initialDelaySeconds` is a fixed, one-size-fits-all wait before checks even begin —
|
|
set it too short and a normally-slow startup gets killed; set it too long and every fast
|
|
startup pays that same delay before liveness/readiness protection is even active. A startup
|
|
probe instead keeps checking until the application actually reports ready (bounded by its own
|
|
failure threshold), so liveness/readiness only take over once startup is confirmed done —
|
|
correct for both a consistently slow app and one whose startup time varies.
|
|
|
|
---
|
|
|
|
**4. True or false: a readiness probe failure will cause Kubernetes to restart the container.**
|
|
|
|
*Answer:* False. A readiness probe failure only removes the Pod from Service endpoints — it
|
|
does not restart anything. Only a liveness (or startup, before it succeeds once) probe failure
|
|
causes a restart.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** In a live classroom, ask these out loud and take verbal answers before
|
|
revealing each one, rather than having students read this silently — the goal is to surface a
|
|
wrong mental model while it's still cheap to correct.
|
|
|
|
**Approximate timing:** 5 minutes.
|
|
|
|
**Likely misconception this catches:** question 2 specifically catches students who default to
|
|
"something is broken, kubectl logs will show an error" — for a pure readiness-probe
|
|
misconfiguration, logs are usually clean, which is disorienting the first time you hit it.
|