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]>
47 lines
2.0 KiB
Markdown
47 lines
2.0 KiB
Markdown
# 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.
|