Domain 3 · Services and networking
20% of the exam. How Pods reach each other, how traffic gets in through Services, Gateway API and Ingress, how NetworkPolicies fence it, and how CoreDNS turns names into IPs.
Domain 3 tasks hand you a running app and ask you to connect it: give it a stable address, publish it on a node port or hostname, route paths and weights to the right backend, lock down who may talk to it, or make a name resolve. Almost every task ends with the same check: a request from a throwaway Pod either gets through or doesn't.
| Competency | What it's really asking | Pages |
|---|---|---|
| 3.1 Connectivity between Pods | The flat Pod network, what the CNI plugin and kube-proxy each do, and how containers in one Pod share a network namespace | Pod networking |
| 3.2 Network Policies | Default deny, selecting peers by Pod and namespace labels, AND vs OR in from, and not forgetting DNS on egress | Network policies |
| 3.3 ClusterIP, NodePort, LoadBalancer and endpoints | Picking the Service type, getting port / targetPort / nodePort right, and reading EndpointSlices when nothing answers | Services |
| 3.4 Gateway API | GatewayClass, Gateway and HTTPRoute, listeners and allowedRoutes, path and header matches, weighted splits | Gateway API |
| 3.5 Ingress controllers and resources | IngressClass, host and path rules, pathType, TLS Secrets, and why nothing happens without a controller | Ingress |
| 3.6 CoreDNS | Service and Pod DNS names, the Corefile, forwarding a private zone, and debugging a lookup that fails | CoreDNS |
What connects Domain 3 to the rest of the exam:
- Troubleshooting (30%) reuses all of this: Services with no endpoints, DNS failures and policies that block too much are in Troubleshooting networking.
- The CNI plugin that builds the Pod network is installed during cluster setup, covered in kubeadm install and Extension interfaces.
- Gateway API and Ingress controllers usually arrive as Helm charts and CRDs, see Helm and Kustomize and CRDs and operators.
- Selectors and readiness decide which Pods a Service sends traffic to, so probes from Self-healing workloads matter here too.
Declaring victory after kubectl apply
A Service, Ingress, HTTPRoute or NetworkPolicy that applies cleanly can still route nothing: the selector matches no
Pods, the class names a controller that isn't installed, or the route was never accepted by its Gateway. Graders
test traffic, so you should too: kubectl run t --rm -it --image=busybox:1.36 --restart=Never -- wget -qO- -T 2 http://target
and read the status of the object you created.
Pod placement
Steering Pods with nodeSelector, node affinity and Pod anti-affinity, keeping them off nodes with taints and tolerations, spreading them with topology spread constraints, and ordering them with PriorityClass and preemption.
Pod networking
The Kubernetes networking model, how containers in a Pod share one network namespace, how the CNI plugin gives Pods routable IPs across nodes, and what kube-proxy adds on top.