Study Hub / Certified Kubernetes Application Developer (CKAD) / Domain 5.0
Certified Kubernetes Application Developer (CKAD) Domain 5.0: Services and Networking — Explained
Domain 5.0 is how things find and reach each other in Kubernetes: services giving stable addresses to mortal pods, DNS making them memorable, ingress opening the front door, and network policies deciding who may talk to whom.
Services: stable front doors for mortal pods
- The problem — pods die and get replaced with new IPs. Nothing can hardcode a pod IP. Services fix this: a stable virtual IP (ClusterIP) + DNS name that selects pods by label and load-balances to the healthy ones.
- ClusterIP (default) — internal only. The standard "my backend talks to my database" service.
- NodePort — exposes the service on a static port of every node. Simple external access; awkward ports (30000–32767), no load-balancer integration.
- LoadBalancer — asks the cloud provider for a real load balancer pointing at the service. The production "put it on the internet" answer on cloud Kubernetes.
- Headless (ClusterIP: None) — no virtual IP; DNS returns the pod IPs directly. For StatefulSets where clients need each pod individually (databases, clustering).
- Endpoints — the actual pod IPs behind a service, updated automatically as pods come and go. If the endpoints list is empty, the selector matches nothing — the classic "service exists but nothing answers" bug.
DNS and Ingress: names and front doors
- Cluster DNS — every service gets a DNS name:
my-svc.my-namespace.svc.cluster.local. Pods resolve service names automatically — no IPs in application config. - Ingress — the HTTP front door: one entry point routing by host and path (
app.example.com/api→ api-service,/web→ web-service). Needs an ingress controller actually running to do anything — the Ingress resource alone is just config. - Ingress vs. LoadBalancer — a LoadBalancer service gives each service its own cloud LB (and its own bill); Ingress puts one LB in front and routes L7 internally. Many services → Ingress is cheaper and cleaner.
- TLS termination — Ingress commonly terminates HTTPS (certificate in a Secret), forwarding plain HTTP to backend pods.
NetworkPolicies: the firewall between pods
- Default: open — pods accept traffic from anywhere unless a NetworkPolicy selects them. (Many newcomers assume isolation that isn't there.)
- How they work — a policy selects pods by label and declares allowed ingress (who may reach them) and egress (who they may reach), by pod selector, namespace selector, or IP block, optionally with port restrictions.
- Default-deny pattern — the standard hardening: a policy selecting all pods in a namespace with no ingress rules (deny all), then specific allow-policies per workload. Deny by default, allow by exception.
- Requires a supporting CNI — the network plugin must enforce policies (Calico, Cilium do; the default kubenet doesn't). A policy no CNI enforces is documentation.
The must-memorize table: service types
Which service for which exposure.
| Type | Exposes | Use it when |
|---|---|---|
| ClusterIP | Internal virtual IP | Backend-to-backend communication |
| NodePort | A port on every node | Quick external access, demos, bare metal |
| LoadBalancer | Cloud load balancer | Production internet exposure on cloud |
| Headless (None) | Pod IPs directly via DNS | StatefulSets needing per-pod addresses |
| (Ingress) | HTTP routing by host/path | Many HTTP services behind one entry point |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. Pods behind a service keep getting replaced, but clients never change their configuration. What makes this possible?
- A. A. Pods keep their IPs forever
- B. B. The service provides a stable virtual IP + DNS name selecting pods by label
- C. C. Clients cache pod IPs indefinitely
- D. D. The scheduler never kills pods
Show answer & reasoning
B. That's the service's entire job: a stable front (ClusterIP + DNS name) over a changing set of backends, tracked via label selectors and endpoints. Clients point at the service; Kubernetes handles the churn behind it. Pod IPs (A) are explicitly ephemeral.
2. A team runs 12 HTTP microservices and wants one public entry point routing by URL path, with TLS termination. Which construct?
- A. A. 12 LoadBalancer services
- B. B. Ingress — one entry point, L7 host/path routing, TLS termination
- C. C. 12 NodePort services
- D. D. Headless services for each
Show answer & reasoning
B. Ingress is the L7 front door: one load balancer, routing by host/path to backend services, commonly terminating TLS. Twelve LoadBalancers (A) means twelve cloud bills; NodePorts (C) expose awkward high ports with no path routing; headless (D) is for direct pod access, the opposite need.
3. After applying a NetworkPolicy that selects all pods in a namespace but defines no ingress rules, what happens to pod-to-pod traffic?
- A. A. Nothing — empty policies are ignored
- B. B. All ingress to selected pods is denied (default-deny)
- C. C. All traffic is allowed as before
- D. D. Only DNS stops working
Show answer & reasoning
B. Selecting pods with a policy makes them isolated for the specified direction; with no ingress rules, nothing is allowed in — default deny. That's the intended hardening pattern: deny all, then add explicit allow-policies. (DNS commonly needs an explicit egress exception — a classic follow-up bug.)
4. A service exists but curl to its ClusterIP times out. The fastest diagnostic check is:
- A. A. Recreate the cluster
- B. B. Check the service's endpoints — empty means the selector matches no pods
- C. C. Increase the pod memory limits
- D. D. Change the service to NodePort
Show answer & reasoning
B. "Service exists, nothing answers" is almost always a selector mismatch: the service selects by labels, and if no pods carry those labels, the endpoints list is empty. Checking endpoints takes seconds and confirms it. The other options treat symptoms blindly.
This was one domain. The simulator drills all 5.
This free preview covered Services & Networking (Domain 5.0, 20%). Not covered here: Application Deployment (Domain 2.0, 20%); Application Environment, Configuration & Security (Domain 4.0, 25%). Deployment patterns and the highest-weight environment/security domain stay in the paid guide and practice bank. The ByteBar Practice Exam Simulator drills every domain with 1,000 exam-style questions — $9.99 one-time unlocks all 28 exams. Prefer to read? The full CKAD Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy