Welcome to the NZRT Wiki Podcast. Today we’re looking at Networking Overview.

Kubernetes networking is the system that connects everything inside your cluster — pods talking to other pods, services providing stable endpoints, and external traffic finding its way in. If you’ve ever wondered how all those moving pieces actually reach each other, this episode walks you through it.

Let’s start with the core networking model, because Kubernetes makes some strong guarantees here that are worth understanding upfront. First, every pod gets its own unique IP address that is valid across the entire cluster. Not just within a node — across the whole cluster. Second, any pod can communicate directly with any other pod without going through network address translation, which you might know as NAT. Third, nodes can also reach any pod directly without NAT. And finally, pod IP addresses are never masqueraded — meaning what you see is what you get, no hidden remapping happening underneath. These four rules together form what’s called the Kubernetes network model, and every networking plugin you install has to honour them.

Now, let’s talk about how traffic actually flows from the outside world into your application. Picture this as a journey with a few stops. It starts with an external client — that’s someone’s browser, a mobile app, whatever is making a request from outside the cluster. That request first hits what’s called an Ingress Controller. In this setup the Ingress Controller is running nginx. The Ingress Controller is the gatekeeper — it reads your routing rules and decides where to send the traffic next. From there, the request moves to a Service. Services in Kubernetes have what’s called a ClusterIP, which is a stable internal address that doesn’t change even if the pods behind it do. Think of the Service as a reliable middleman. Finally, the request lands at the actual Pod — the container running your application. So the journey is: external client, then Ingress Controller, then Service, then Pod. Four hops, clean and predictable.

Next up is the CNI, which stands for Container Network Interface. This is the plugin layer that actually implements the network model we just described. Kubernetes doesn’t hard-code a single networking solution — instead it lets you choose a CNI plugin that suits your needs. There are four common options you’ll encounter. The first is Flannel, which is simple to set up and uses an overlay network — a good starting point if you want something that just works without a lot of configuration. The second is Calico, which gives you support for network policies and BGP routing, making it a strong choice when you need fine-grained control over which pods can talk to which. The third is Cilium, which is eBPF-based and gives you advanced observability — if you need deep visibility into your network traffic and performance, Cilium is worth a look. The fourth is Weave Net, which is known for easy setup and comes with encrypted overlay networking out of the box, so your pod-to-pod traffic is protected without extra configuration.

Choosing the right CNI depends on your priorities — simplicity, policy control, observability, or security. Most production clusters end up on Calico or Cilium, but Flannel and Weave Net are perfectly valid for smaller or simpler environments.

Now let’s cover DNS, because once pods and services exist, you need a way to find them by name rather than memorising IP addresses. Kubernetes handles this through CoreDNS, which runs inside the cluster and answers name lookups automatically. Services get a DNS name that follows a pattern: the service name, then the namespace it lives in, then the suffix svc.cluster.local. So if you have a service called api in a namespace called production, you can reach it at api.production.svc.cluster.local. Pods also get DNS names, though they’re used less often. A pod’s DNS name uses its IP address with dashes instead of dots, followed by the namespace, then pod.cluster.local. The important thing to know is that CoreDNS makes service discovery automatic — your application code can use a stable DNS name rather than hardcoding IPs that might change.

To wrap up, here’s the big picture. Every pod has its own IP, pods talk to each other freely without NAT, and the network model is enforced by whichever CNI plugin you choose. External traffic enters through an Ingress Controller, passes through a Service, and reaches your Pod. CoreDNS keeps name resolution working so everything can find everything else by name. If you want to go deeper, the related topics to explore next are Services, Ingress, and Services and DNS — each of those builds directly on what we’ve covered here.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.