Study notes · 12% of the exam

Services, Ingress and Networking

Every Pod gets a routable IP from the CNI plugin; Services add a stable virtual IP and DNS name in front of a changing set of ready Pods, and Ingress or Gateway API route external HTTP traffic to them.

Key points

1
Service types stack: ClusterIP (default, internal) ⊂ NodePort (30000–32767 on every node) ⊂ LoadBalancer (cloud LB in front). ExternalName is only a DNS CNAME, and headless (clusterIP: None) returns Pod IPs directly.
2
Endpoints come from the selector plus readiness: Pods must match every selector label and be Ready. A named targetPort is resolved per Pod.
3
kube-proxy balances per connection (iptables or nftables; IPVS is deprecated since v1.35), so long-lived HTTP/2 or gRPC connections pin to one Pod unless you balance at L7.
4
externalTrafficPolicy: Cluster SNATs and may add a hop; Local preserves client IPs but drops traffic on nodes without local Pods and splits load per node.
5
DNS: <svc>.<ns>.svc.cluster.local; bare names resolve only in your own namespace. ndots:5 makes external names try every search domain first.
6
Ingress needs a controller and ingressClassName; pathType: Prefix matches whole path elements. Gateway API (GatewayClass, Gateway, HTTPRoute, ReferenceGrant) is the role-oriented successor, and Ingress NGINX was retired in March 2026.
7
Pods are non-isolated until a NetworkPolicy selects them; a default-deny egress policy also blocks DNS on port 53.

Common traps

ClusterIPs often don't answer ping: test with the real protocol and port.
hostNetwork Pods need dnsPolicy: ClusterFirstWithHostNet to use cluster DNS.
Endpoint removal and SIGTERM happen in parallel: add a short preStop delay or drain on SIGTERM to avoid 502s during rollouts.

Read the source

Test yourself on Services, Ingress and Networking

Ten questions, with the answer and explanation after each one.