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