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.0 KiB
Knowledge Check: Ingress & NetworkPolicy Foundations
1. You create an Ingress object with correct routing rules, but no traffic is ever routed according to them. What's the most likely reason?
Answer: No Ingress controller is installed/running in the cluster. Ingress objects are just routing rules; a separate controller has to actually read and act on them, or nothing happens.
2. True or false: by default, a Pod in Namespace A cannot reach a Pod in Namespace B unless a NetworkPolicy explicitly allows it.
Answer: False — the opposite is true by default. With NO NetworkPolicy in place at all, every Pod can reach every other Pod regardless of Namespace. NetworkPolicy is what RESTRICTS this default-open behavior, not what's required to enable connectivity in the first place.
3. A NetworkPolicy selects Pods labeled app: backend and declares one ingress rule allowing
traffic from Pods labeled app: frontend. What happens to traffic from a Pod labeled
app: admin-tool trying to reach backend?
Answer: It's blocked. Once a NetworkPolicy selects a Pod, only traffic matching one of its explicit rules is allowed — everything else to that Pod is denied, including traffic that would have worked fine before the policy existed.
4. Why is Ingress the right tool for exposing an HTTP application by hostname, rather than creating a separate LoadBalancer Service per hostname?
Answer: A LoadBalancer Service typically provisions its own external IP/load balancer per Service — one per hostname would mean paying for and managing N separate external endpoints. Ingress lets one entry point route to many backend Services by hostname/path, which is both cheaper and centralizes concerns like TLS termination.
Instructor Notes
Facilitation: Question 2 catches a very common and consequential misconception — worth confirming out loud that everyone actually updated their mental model, not just guessed correctly.
Approximate timing: 5 minutes.