Services and Networking

Service Types, Ingress, and Cluster DNS

Pods are ephemeral and get new IP addresses whenever they are recreated, so nothing in a healthy cluster should ever talk to a Pod IP directly. A Service gives a stable address in front of a changing set of Pods, and CoreDNS gives that address a name. Ingress then adds HTTP aware routing on top of Services for traffic coming from outside the cluster, and NetworkPolicy is the one mechanism that can restrict traffic that would otherwise flow freely between any two Pods.

Exam tip. If a Service has no endpoints, the fix is almost never the Service object itself. Compare the Service selector against the actual Pod labels, and confirm the target Pods are passing their readiness probe, since a Pod that is not ready is removed from the endpoint list.

From Service to Pod: What Breaks and Where

Service connectivity failures fall into a small number of shapes, and knowing the order to check them is worth more than knowing any individual fact. Endpoints first, because a Service with none is the most common cause and the quickest to confirm. DNS second. Network policy last, because it is invisible unless you look for it.

Exam tip. kubectl get endpoints is the fastest first command for any Service problem. No endpoints means stop and look at labels and readiness.

Writing a NetworkPolicy That Does What You Meant

The two errors that cost marks are forgetting that policies are additive with no implicit deny until a pod is selected, and getting the selector combination wrong. Whether namespaceSelector and podSelector sit in the same list entry or in separate ones changes the meaning from AND to OR, and the YAML difference is a single dash.

Exam tip. Write the default deny first, then add allows. Building up from deny is faster to verify than narrowing down from allow.

1. A developer wants to expose a Deployment so that it is reachable from outside the cluster by hitting any node's IP address on a specific high numbered port, without deploying a cloud load balancer or Ingress controller. Which Service type should be used?

• A. ClusterIP
• B. NodePortcorrect
• C. ExternalName
• D. Headless

A NodePort Service opens a static port, by default in the 30000 to 32767 range, on every node, forwarding traffic on that port to the Service, which makes it reachable from outside the cluster via any node's IP without extra infrastructure. ClusterIP only exposes the Service inside the cluster. ExternalName maps a Service name to an external DNS name and does not expose cluster workloads outward. A headless Service, created with clusterIP: None, returns pod IPs directly via DNS and provides no external node port access.

2. You need a NetworkPolicy that allows pods labeled app=frontend to send egress traffic only to pods in the namespace labeled team=payments, and block all other egress. Which policy structure achieves this?

• A. A policy with policyTypes: [Ingress] and an ingress rule matching namespaceSelector team=payments
• B. A policy with no podSelector, applying the rule cluster wide to all namespaces
• C. A policy with egress: [] and no policyTypes field, which implicitly allows only same namespace traffic
• D. A policy with podSelector matching app=frontend, policyTypes: [Egress], and an egress rule whose to field contains a namespaceSelector matching team=paymentscorrect

Egress restriction requires policyTypes to include Egress, a podSelector to target the source pods, and an egress.to entry using namespaceSelector to scope allowed destinations to the payments namespace. Using Ingress policyTypes controls incoming traffic not outgoing, omitting podSelector applies the policy to every pod in the namespace rather than just frontend, and an empty egress array with no policyTypes does not enforce anything specific.