Kubernetes Networking for the CKA: Services, DNS, and kube-proxy

Networking is the topic that quietly decides pass or fail on the Certified Kubernetes Administrator (CKA) exam. The CKA is entirely performance-based — you are dropped into a live cluster and told to make something work — and a huge share of those tasks come down to traffic reaching the right pod. Candidates who memorized manifests but never built a mental model of how a packet travels through a cluster tend to freeze when a Service returns nothing and the clock is running. This article walks the whole path, from the flat pod network up through Services, kube-proxy, and CoreDNS, so that when something breaks you know exactly which layer to inspect.

The pod network: one flat address space

Kubernetes imposes a deliberately simple networking model, and understanding it removes most of the confusion. Every pod gets its own IP address, and every pod can reach every other pod on that IP directly, across nodes, with no network address translation between them. A pod on node A talks to a pod on node B as if they were on the same LAN. This is what people mean by a "flat" network.

Kubernetes itself does not implement this; it delegates to a CNI (Container Network Interface) plugin such as Calico, Cilium, or Flannel. The plugin wires up each pod's virtual interface, assigns it an address from the pod CIDR, and programs the routes so cross-node traffic finds its way. On the CKA this is concrete: if pods are stuck in ContainerCreating or cannot reach each other, a missing or misconfigured CNI plugin is a prime suspect. The idea to hold onto is that pod IPs are real and routable, but ephemeral — a pod that restarts gets a new one. That impermanence is the entire reason Services exist.

Services: a stable front door for disposable pods

Because pod IPs churn, you never want clients pointing at them directly. A Service is a stable virtual IP (the ClusterIP) and DNS name that sits in front of a set of pods selected by labels. Traffic sent to it is load-balanced across the healthy pods behind it, and that set is kept current through Endpoints (or EndpointSlices) that Kubernetes updates as pods come and go. Think of the Service as the permanent street address of a shop that keeps swapping which room it operates from — customers use the address and never need to know the room number.

There are three Service types worth knowing cold, because the exam expects you to pick the right one:

• ClusterIP — the default. Reachable only from inside the cluster on its virtual IP. This is what you use for internal service-to-service traffic, like a web tier talking to an API tier.
• NodePort — everything a ClusterIP does, plus it opens the same port (30000–32767 by default) on every node, so external clients can hit anyNodeIP:nodePort and reach the pods. It is the simplest way to expose something without a cloud load balancer.
• LoadBalancer — builds on NodePort and asks the cloud provider to provision an external load balancer that forwards to those node ports. On a bare-metal exam cluster there is usually no provider to fulfill it, so the external IP stays pending — worth remembering so you do not chase a non-bug.

A frequent source of "the Service returns nothing" is a label selector that does not match any pod, which leaves the Endpoints list empty. When you build fluency by running through CKA practice questions that force you to create and debug Services under time pressure, checking Endpoints becomes the reflex it needs to be: no endpoints means the selector, not the network, is wrong.

kube-proxy: what actually routes the traffic

A ClusterIP is virtual — no single machine "owns" it and nothing listens on it directly. So how does traffic to that address reach a real pod? That is kube-proxy's job. It runs on every node, watches the API server for Services and Endpoints, and programs the node's kernel so packets destined for a Service IP get rewritten to the address of one of the backing pods.

In its common iptables mode, kube-proxy installs rules that intercept traffic to each ClusterIP and, using a probabilistic match, DNAT it to one of the endpoint pod IPs — that is the load balancing, happening in the Linux kernel rather than in any proxy process on the hot path. The newer IPVS mode does the same with a purpose-built kernel load balancer that scales better on large clusters. The CKA takeaway: kube-proxy translates the stable Service abstraction into real packet forwarding on each node. If a Service resolves to an IP but connections hang, a broken or crash-looping kube-proxy pod belongs on your checklist.

CoreDNS: turning names into ClusterIPs

Applications should connect to names, not IPs, and inside a cluster that resolution is handled by CoreDNS, which runs as a Deployment fronted by a ClusterIP Service (typically named kube-dns for backward compatibility). Every pod's /etc/resolv.conf is configured by the kubelet to point at that DNS Service, so a pod can look up another Service by name and get its ClusterIP back.

The naming scheme is worth committing to memory because the exam rewards it. A Service is reachable at service.namespace.svc.cluster.local. Within the same namespace the short name service resolves thanks to the search domains in resolv.conf; from another namespace you need at least service.namespace. So a pod in namespace web reaching a Service named db in namespace data uses db.data or the fully qualified db.data.svc.cluster.local. When resolution fails, the diagnostic ladder is short: confirm the CoreDNS pods are running, confirm the kube-dns Service has endpoints, and test a lookup from a temporary pod. Getting quick at that ladder is exactly the muscle memory that timed CKA exam simulations build, because they push you to diagnose under the same 120-minute constraint you will face on exam day.

NetworkPolicy: turning the flat network into a firewall

By default that flat pod network is wide open — any pod can talk to any pod. NetworkPolicy is how you lock it down. It is a namespaced object that selects pods by label and defines allowed ingress and egress. The critical mental model is the default-deny flip: the moment any policy selects a pod for a given direction, all traffic in that direction is denied except what the policy explicitly permits. A pod with no policies stays fully open; a pod selected by even one ingress policy now rejects every inbound connection that is not whitelisted.

One gotcha the exam loves: NetworkPolicy is only enforced if your CNI plugin supports it. Flannel alone does not; Calico and Cilium do. If you write a correct policy and nothing changes, the plugin, not the YAML, may be the reason. You do not need to author elaborate rulesets for the CKA, but you must be able to read a policy and predict exactly which traffic it allows.

Tying the layers together

Put the whole stack in order and troubleshooting becomes systematic instead of frantic. A client resolves a name through CoreDNS, gets a Service ClusterIP, kube-proxy's kernel rules DNAT that to a real pod IP from the Service's endpoints, and the packet travels the flat pod network to arrive — unless a NetworkPolicy blocks it. When something fails, you walk that chain one link at a time rather than guessing. The way to internalize it is repetition against a live cluster with honest feedback on where you slipped, then reviewing each missed task until the fix is obvious. Working through full, exam-format tasks and tracking your readiness across the networking domain on the Certified Kubernetes Administrator practice set is how you turn this model into the fast, calm debugging the CKA actually measures — and how you know, from evidence rather than nerves, that you are ready to book.