Files
rootnode-academy/content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/04-guided-exercise-endpoint-mismatch.md
T
ced4568andClaude Sonnet 5 7f6e1857c0 feat(curriculum): Phase 6C module upgrades, security assessment bank, ROOT 11 orientation
Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/
knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab
activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04
(ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place
from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03
(network/supply-chain security), root-10-m03 (troubleshooting framework).

root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson +
reflection rather than a full redesign, since each task already carries its own
explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to
READY via documented exceptions (no new activities) where adding one would
misrepresent their intentional design.

Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled)
using the existing Phase 3B assessment engine: 3 required hands-on CORE
scenarios + 4 random-draw pools covering SecurityContext, RBAC, network
policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired
readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01,
using the existing is_required model.

Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11
orientation module naming DevOps/platform engineering practices already
exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need
lab infrastructure this platform doesn't yet provide. No fake labs.

Adds infra/scripts/validate-course-content.js: cross-checks the DB against
scenario/content files for duplicate ids, orphans, invalid references, cycles,
sequence collisions, instructor-notes leakage, and (new) self-paced content
deferring explanation to a live instructor. 0 errors against the resulting
22 courses/modules, 163 activities, 98 scenario files.

No application code changed — every gap was satisfiable with existing tables
(course_modules, module_activities, assessment_definitions) and the existing
content-delivery pipeline.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 11:20:17 -05:00

2.8 KiB

Guided Exercise: Applying the Framework to a Broken Service, on Paper First

Before the endpoint-fix-task Lab, walk through the framework yourself against a described symptom — no cluster needed yet.

The scenario

A teammate says: "my-svc isn't routing any traffic to our Pods, and I don't know why — the Pods look healthy in kubectl get pods."

Your task

Write out, step by step, what you would actually DO for each framework stage, before looking at the worked answer:

  1. Observe — what's the precise, specific symptom here (not "it's broken")?
  2. Gather Evidence — name the exact kubectl commands you'd run, in order, and what each one is checking for.
  3. Form Hypothesis — based on what ROOT 07's Services lesson taught you, what's the most likely cause of "Pods healthy, but Service routes nowhere"?
  4. Test — how would you CONFIRM that hypothesis before changing anything?
  5. Repair — what's the minimal fix, assuming your hypothesis is correct?
  6. Validate — what would you check afterward to PROVE the fix worked, not just assume it?

A worked answer to check yourself against

  1. Traffic sent to my-svc never reaches any Pod, despite the Pods themselves reporting Running/Ready — this rules out "the Pods are unhealthy" as the cause.
  2. kubectl get endpoints my-svc (does it show any Pod IPs at all?), then kubectl describe service my-svc (what selector is it actually using?), then kubectl get pods --show-labels (what labels do the real Pods actually carry?).
  3. A Service-to-Pod label selector mismatch — exactly the failure mode ROOT 07's demonstration walked through, where a Service's selector no longer matches the Pods' actual labels.
  4. Directly compare the Service's selector (from describe service) against the Pods' labels (from get pods --show-labels) side by side — confirmed if they genuinely don't match.
  5. Correct the Service's selector (or the Pods' labels, whichever is actually wrong) so they match again.
  6. kubectl get endpoints my-svc now shows the Pod IPs populated — not just "the YAML looks right now," but the actual Endpoints object reflecting real, matched Pods.

Instructor Notes

Facilitation: This exercise deliberately reuses ROOT 07's own content — a good moment to point out explicitly that the framework's value is applying PRIOR knowledge systematically, not learning something entirely new each time.

Approximate timing: 10-12 minutes live with discussion; 10 minutes self-paced.

Optional extension: ask what would change about steps 2-4 if the symptom were instead "Pods healthy, but ONE specific caller can't reach the Service while others can" — a good bridge to considering NetworkPolicy (ROOT 09) as an alternative hypothesis once the simpler selector-mismatch explanation is ruled out.