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.1 KiB
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.