ced4568andClaude Sonnet 5
dbcc210889
root-07-m03-services-and-service-discovery — a new, full gold-standard- pattern module: the Service/Endpoints/DNS request path, choosing the right Service type. Lesson, demonstration (a Service with zero Endpoints — the single fastest diagnostic check for this failure class), knowledge check, guided exercise (ClusterIP vs. NodePort vs. LoadBalancer for three real components), a real Lab (expose-service-basics), and a reflection. root-07-m04-ingress-networkpolicy-foundations — a new PARTIAL module: Ingress and NetworkPolicy at the architectural level (the security- control framing of NetworkPolicy is deliberately deferred to ROOT 09). Lesson + knowledge check + real Labs (ingress-task, network-policy). Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.2 KiB
Reflection: Service Discovery Is Infrastructure, Not Magic
You just created a Service that gives a moving set of Pods a stable address. Take a few minutes to connect this to real operational thinking.
Reflection questions
- Before this module, "the app can just connect to redis by name" might have seemed obvious or automatic. What specific mechanism actually makes that true, and what would break it?
- If your Service's selector had been wrong (matching zero Pods), what would the SYMPTOM have looked like from the application's side, versus what the actual CAUSE would have been?
- Why is checking
kubectl get endpointsbefore assuming a networking/DNS/firewall problem a good default habit, given how common a selector mismatch actually is?
Real Ops takeaway
"It's probably a networking issue" is often wrong, and Endpoints is how you find out fast. A
huge fraction of real "service X can't reach service Y" incidents in Kubernetes are Service
selector mismatches, not actual network problems — checking kubectl get endpoints first, before
escalating to firewall rules or DNS debugging, saves real time precisely because this failure
mode produces zero errors at the layers people instinctively check first.
Stable addressing is what makes rolling updates and self-healing actually usable. Everything you learned in ROOT 06 about Pods being replaced during a rollout or after a crash only works smoothly in practice because Services give callers a stable target that survives those replacements — without this layer, every Pod replacement would require updating every caller's configuration by hand.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: use question 2 as a discussion prompt — the symptom/cause gap is exactly why this class of bug is often under-diagnosed in real teams.
Approximate timing: 8-10 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to write the one-line runbook entry they'd want a future on-call engineer to have for "Service X seems unreachable" — a good exercise in turning a lesson into something operationally reusable.