Calico

Right, let’s settle this. You’ve seen --service-cidr and --pod-cidr flags thrown around, and if you’re anything like me, you initially thought, “A CIDR is a CIDR, what’s the big deal?” I’m here to tell you the distinction is one of the most fundamental, yet initially confusing, parts of Kubernetes networking. Mixing them up is like confusing the highway (Pod CIDR) with the highway’s on-ramp signage system (Service CIDR). One carries the actual traffic, the other is a brilliant abstraction to find that traffic.

Right, let’s talk about kube-proxy. You’ve probably heard it’s the thing that makes Kubernetes Services work, and that’s mostly true. But if you think it’s a traditional proxy—some daemon sitting in the middle of the data path, inspecting packets and making decisions—I’ve got news for you. That would be horrifically inefficient. Instead, kube-proxy is a gloriously clever (and sometimes gloriously convoluted) system-level programmer. Its job isn’t to proxy traffic, but to manipulate the networking rules on the host (the iptables, IPVS, or nftables we’re about to dive into) so that traffic heading for a virtual Service IP gets magically redirected to an actual healthy Pod.

Alright, let’s roll up our sleeves and talk about Cilium. If the basic CNI plugins we’ve discussed are like reliable, simple sedans, Cilium is a fully-loaded, self-driving concept car from the future. It still connects your pods to the network, which is its job as a CNI plugin, but it throws out the old, cumbersome iptables-based plumbing and replaces it with eBPF. This isn’t just an incremental upgrade; it’s a fundamental rewrite of the kernel’s networking and security logic, and it changes everything.

Alright, let’s get our hands dirty with Calico. If you’ve been around the Kubernetes block, you’ve heard the name. It’s not just another CNI plugin; it’s more like the opinionated, highly-capable network engineer of the container world. While many CNIs slap a big virtual switch (VXLAN, I’m looking at you) over everything and call it a day, Calico often takes a different, radically sensible approach: it treats your data center like what it actually is—a network—and uses the Border Gateway Protocol (BGP) to have intelligent conversations with it.

Alright, let’s talk about Flannel. If Kubernetes networking were a high school clique, Flannel would be the reliable, unassuming friend who shows up with a six-pack and knows how to get the router working. It’s not the flashiest, it won’t brag about its features, but it will get the job done with a minimum of fuss. Its entire reason for existence is to solve one problem: making sure every Pod in your cluster gets a unique IP address that every other Pod (and Node) can talk to, regardless of which physical machine it’s sitting on. It does this using one of the oldest tricks in the networking book: an overlay network.

Right, so you’ve got a Kubernetes cluster humming along. Pods are scheduled, the API server is doing its thing, and then… a new Pod lands on a node. It has an IP address, but how did it get there? The kubelet didn’t fuss with any ip commands. That’s because it outsourced the entire messy business of networking to a bunch of smaller, specialized programs through a standard contract called the Container Network Interface (CNI).

Alright, let’s get our hands dirty with the one networking concept Kubernetes absolutely nails: the Pod Network Model. Forget everything you know about Docker’s janky port-mapping circus. In Kubernetes, every pod—yes, every single pod—gets its own, bona fide IP address. This isn’t a suggestion; it’s the entire foundation of the network model, and it’s brilliant in its simplicity. Think about it. If every pod has a unique IP on a flat network, your application doesn’t need to care about where it’s running. It just needs to know the IP of the pod it wants to talk to. No more wrestling with environment variables for port numbers or some convoluted discovery service just to find a neighboring container. A frontend pod can connect to a backend pod at 10.244.1.15:8080 just as easily as you can ping 8.8.8.8. This eliminates a massive class of network address translation (NAT) headaches and makes debugging a dream. You can curl a pod’s IP directly from any node, or even from your laptop if your network is set up right. It’s the network as it was meant to be: dumb, predictable, and transparent.