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]>
48 lines
2.1 KiB
Markdown
48 lines
2.1 KiB
Markdown
# Knowledge Check: Services & Service Discovery
|
|
|
|
---
|
|
|
|
**1. A Deployment has three replicas but `kubectl get endpoints` shows `<none>` for its Service.
|
|
Which part of the system should you inspect first, and why?**
|
|
|
|
*Answer:* Compare the Service's selector (`kubectl describe service`) against the actual Pods'
|
|
labels (`kubectl get pods --show-labels`) — a Service with a healthy backend Deployment but zero
|
|
Endpoints almost always means the selector doesn't match the Pods' current labels, not that the
|
|
Pods themselves are unhealthy.
|
|
|
|
---
|
|
|
|
**2. You need a microservice reachable ONLY from other services inside the same cluster, never
|
|
from the public internet. Which Service type, and why not LoadBalancer?**
|
|
|
|
*Answer:* ClusterIP — it's reachable only from inside the cluster by design, which is exactly
|
|
the requirement. A LoadBalancer would provision a real external endpoint reachable from the
|
|
public internet, which is more exposure than the requirement calls for, and depends on cloud
|
|
provider support this scenario doesn't need.
|
|
|
|
---
|
|
|
|
**3. True or false: application code that connects to `redis-svc` by that plain hostname is
|
|
relying on Kubernetes' internal DNS to resolve it.**
|
|
|
|
*Answer:* True. Every Service automatically gets a DNS name; that's specifically what lets code
|
|
use a stable hostname instead of hardcoding a Pod IP that could change at any time.
|
|
|
|
---
|
|
|
|
**4. A Service's Endpoints list is non-empty, but the application still can't connect. Does
|
|
this rule out a Service-level problem entirely?**
|
|
|
|
*Answer:* Not entirely — a non-empty Endpoints list means at least one Pod currently matches the
|
|
selector, but the connection could still fail for other reasons (wrong port number on the
|
|
Service, a NetworkPolicy blocking the traffic, the application inside the Pod not actually
|
|
listening). A populated Endpoints list narrows the problem, it doesn't prove the whole path
|
|
works.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 1 is the single most transferable diagnostic habit from this module —
|
|
worth explicitly calling out as "the first thing to check" for this entire class of problem.
|
|
|
|
**Approximate timing:** 5 minutes.
|