Study Hub / Certified Kubernetes Administrator (CKA) / Domain 3.0
Certified Kubernetes Administrator (CKA) Domain 3.0: Services & Networking — Explained
Domain 3.0 is how traffic moves in a cluster: the Service abstraction that survives pod churn, the DNS every pod uses, the Ingress front door, and the NetworkPolicies that decide who may talk to whom — plus what the admin must keep healthy underneath.
Services and kube-proxy
- The Service abstraction — a stable virtual IP (ClusterIP) and DNS name selecting pods by label. Pods die and get replaced; the Service never changes. Endpoints track the current healthy pod IPs.
- kube-proxy — the per-node agent that implements Services: programs iptables/IPVS rules so the virtual IP actually routes to backends. If Services stop working cluster-wide, kube-proxy health is on the suspect list.
- Service types — ClusterIP (internal), NodePort (a port on every node), LoadBalancer (cloud LB integration), headless/None (DNS returns pod IPs directly — for StatefulSets).
- CoreDNS — cluster DNS: Services resolve as
svc.namespace.svc.cluster.local; pods get DNS automatically. DNS failures in a cluster are very often CoreDNS pods unhealthy or misconfigured — check them early.
Ingress: the HTTP front door
- What Ingress does — L7 routing: one entry point, routing by host and path to backend Services, commonly terminating TLS. Many HTTP services, one public address.
- IngressClass and controllers — the Ingress resource is just config; an ingress controller (nginx, Traefik, cloud LBs) must be running to act on it, selected via IngressClass. "I created the Ingress and nothing happens" → no controller is watching.
- TLS — certificates live in Secrets referenced by the Ingress; termination happens at the controller, backend traffic is plain HTTP (or re-encrypted).
- Admin angle — installing and keeping the controller healthy, choosing the right class per environment, and verifying backend Services actually have endpoints.
NetworkPolicies and CNI
- Default open — pods accept traffic from anywhere unless a NetworkPolicy selects them. Isolation is opt-in, not default — a common false assumption.
- How policies work — select pods by label; declare allowed ingress/egress by pod selector, namespace selector, or IP block, with optional ports. Select-with-no-rules = deny that direction (default-deny pattern).
- CNI plugins — the Container Network Interface is what implements pod networking: Calico, Cilium, Flannel, Weave. The CNI assigns pod IPs and (for policy-capable CNIs) enforces NetworkPolicies.
- Admin troubleshooting — "policy applied but traffic still flows" → is the CNI policy-capable and healthy? "Pods can't reach each other at all" → CNI misconfiguration or a default-deny with no allow rules. Always verify the enforcement layer, not just the YAML.
The must-memorize table: who implements what
The abstraction and its implementer.
| Abstraction | Implemented by | If it breaks, check |
|---|---|---|
| Service (ClusterIP) | kube-proxy (iptables/IPVS on each node) | kube-proxy pods/daemonset health |
| DNS names | CoreDNS | CoreDNS pods, service, config |
| Ingress routing | Ingress controller (via IngressClass) | Controller deployment, class match |
| NetworkPolicy | Policy-capable CNI (Calico, Cilium) | CNI pods, policy syntax, default-deny gaps |
| Pod IPs | CNI plugin | CNI config, IP pool exhaustion |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. All Services in a cluster suddenly stop routing to pods, though the pods themselves are healthy. Which component should the admin investigate first?
- A. A. etcd
- B. B. kube-proxy — it programs the per-node rules implementing Services
- C. C. The scheduler
- D. D. CoreDNS
Show answer & reasoning
B. kube-proxy is the Service implementer: it writes the iptables/IPVS rules that make virtual IPs reach backends. Healthy pods + dead Services cluster-wide points at the programming layer, not the pods. The scheduler (C) places pods (they're already placed); etcd (A) stores state (reads still work).
2. Pods can't resolve Service names, but IP connectivity between pods works. What is the most likely culprit?
- A. A. The CNI plugin
- B. B. CoreDNS — the cluster DNS provider; name resolution fails while IPs still route
- C. C. kube-proxy
- D. D. The Ingress controller
Show answer & reasoning
B. "IPs work, names don't" isolates the failure to DNS — CoreDNS pods, its Service, or its configuration. The CNI (A) provides pod IPs (those work); kube-proxy (C) implements Service VIPs (IP-level). Name resolution has exactly one provider: check it first.
3. An Ingress resource was created correctly but no traffic is routed and no controller logs mention it. What is the likely cause?
- A. A. The backend pods are unhealthy
- B. B. No ingress controller is running/watching that IngressClass — the resource is config without an implementer
- C. C. The TLS secret is missing
- D. D. DNS is broken
Show answer & reasoning
B. Ingress resources do nothing alone — a controller must watch the IngressClass and act. No controller, no routing, no logs mentioning it. Backend health (A) would produce 503s through a working controller, not silence. Always verify the implementer exists.
4. A NetworkPolicy selecting all pods in a namespace was applied, but pods still receive traffic from anywhere. The YAML is valid. What should the admin check?
- A. A. The policy's labels
- B. B. Whether the CNI plugin enforces NetworkPolicies — a non-enforcing CNI makes policies documentation only
- C. C. kube-proxy
- D. D. The pod resource limits
Show answer & reasoning
B. NetworkPolicies are declared in YAML but enforced by the CNI: Calico and Cilium enforce; Flannel and kubenet don't. Valid YAML + zero effect = the enforcement layer doesn't implement policies. The admin checks the CNI's capabilities before debugging selectors (A).
This was one domain. The simulator drills all 5.
This free preview covered Services & Networking (Domain 3.0, 20%). Not covered here: Cluster Architecture, Installation & Configuration (Domain 1.0, 25%); Troubleshooting (Domain 5.0, 30%). The two highest-weight domains — cluster builds and live troubleshooting, the most hands-on CKA material — 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 CKA Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy