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]>
41 lines
2.2 KiB
Markdown
41 lines
2.2 KiB
Markdown
# 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
|
|
|
|
1. 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?
|
|
2. 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?
|
|
3. Why is checking `kubectl get endpoints` before 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.
|