Kubernetes Networking Explained Simply: Pods, Services, and CNI

When you hear "Kubernetes networking," you might picture a tangled mess of YAML files and invisible wires. I did too, until I realized that beneath the hood, it's actually a beautifully simple set of principles—with just enough complexity to keep your brain from getting bored.

Let's walk through it without the corporate jargon, and with a healthy dose of "wait, that's it?"

The One Rule to Rule Them All

Here’s the dirty secret: Kubernetes networking doesn't care about Docker, containers, or even your pod names. It cares about one thing: every pod gets its own IP address, and every pod can talk to every other pod without any NAT (Network Address Translation).

Think of it like a neighborhood where every house has a unique address, and the mailman can walk directly from door to door. No forwarding, no hiding behind someone else's mailbox. This is the "flat network" model, and it's the foundation of everything else.

The Three Conversations Your Pod Is Having

Right now, inside your cluster, there are three kinds of conversations happening:

1. Container-to-container (boring, but important) – Within a single pod, containers share the same network namespace. They talk via localhost. This is like roommates sharing a phone line. If you have an app container and a sidecar container, they can just curl localhost:8080. Easy.

2. Pod-to-pod (the real work) – This is where it gets interesting. Pods live on different nodes (think: different computers in a data center). They need to talk across physical machines. The magic here is the Container Network Interface (CNI) – a plugin like Calico, Flannel, or Cilium that creates a virtual network overlay. Your pod sends a packet, the CNI routes it to the right node, and the other pod receives it as if they were on the same switch.

3. Pod-to-service (the everyday hero) – Pods die. That's their job. But you can't have your frontend hardcoding IP addresses of backend pods that might vanish. Enter the Service – a stable endpoint that load-balances traffic to a set of pods. When you create a Service, Kubernetes gives it a virtual IP (the ClusterIP) that never changes. Your app talks to the Service, the Service forwards to a healthy pod.

Fun fact: A Service is just a fancy DNS entry + some iptables rules. It's not a real load balancer. It's a hyperactive bouncer at a club who memorizes where everyone sits.

The CNI: Your Network's Actual Brain

If Kubernetes networking had a secret sauce, it's the CNI. Without it, your pods would be isolated digital islands. The CNI does three things:

• Assigns IPs – When a pod spawns, the CNI grabs an IP from a pool and sticks it on the virtual ethernet interface inside the pod.
• Routes packets – It knows which node a pod lives on, and can forward traffic across hosts.
• Enforces policies (optional) – If you use NetworkPolicies, the CNI is the one that blocks or allows traffic. Calico and Cilium are the heavy hitters here.

The beautiful part? You don't configure the CNI in your pod manifests. You install it once on the cluster, and it just works. It's like hiring a really competent network admin who never asks for a raise.

Services: The Illusion of Permanence

Remember how pods come and go? That's a problem for any real application. A Service is a stable nickname for a set of pods. It has:

• A ClusterIP (virtual IP, only reachable inside the cluster)
• A DNS name (like my-service.default.svc.cluster.local – yes, it's that long, but you rarely type it)
• A selector (labels that match pods)

When a pod dies and a new one spins up, the Service automatically updates its list of endpoints. Your app never notices.

Pro tip: Use kubectl get endpoints to see which pods a Service is currently pointing to. It's the closest thing to X-ray vision for your cluster.

The Tricky Part: The Outside World

Pods and Services live in a private network. But your users are out there, on the internet. How do they get in?

• NodePort – Opens a port on every node (say, 30080). Traffic hits any node, gets forwarded to the Service. Simple, but not production-friendly (ports clash, nodes change).
• LoadBalancer – The cloud provider (AWS, GCP, Azure) creates a real load balancer with a public IP. Traffic goes: Internet → Load Balancer → Node → Service → Pod.
• Ingress – The modern way. Ingress isn't a Service; it's a smart routing layer (like Nginx or Traefik) that sits in front of your Services. It can handle TLS, path-based routing, and virtual hosts. One Ingress can route api.example.com to one Service and web.example.com to another.

Think of Ingress as a concierge who knows exactly which door to send each guest to, while a LoadBalancer is just a big revolving door.

What Actually Goes Wrong (And Why You'll Laugh Later)

Beginners often hit these invisible walls:

• Pod can't reach Service? Check if the Service's selector matches the pod's labels. Kubernetes is picky – one typo in app: my-backend vs app: my-backend-old and the Service sees zero endpoints.
• Cross-node traffic fails? Your CNI might not be configured to allow it. Some cloud providers block inter-node traffic by default. Check firewall rules.
• DNS doesn't resolve? CoreDNS (the cluster DNS) is probably crashing. kubectl -n kube-system get pods -l k8s-app=kube-dns will tell you.
• NetworkPolicy blocking everything? By default, all pods can talk. The moment you apply a NetworkPolicy, it turns into a whitelist. If you forget to allow traffic to your own pods, they become digital hermits.

The One-Liner That Sums It All Up

Kubernetes networking is about giving every pod a permanent ID (the IP), making those IDs reachable across the cluster, and wrapping them with stable names (Services) so your application doesn't break when pods take a coffee break.

The rest is just plumbing. But hey, good plumbing saves a marriage.

Next time someone asks you what a CNI does, just say: "It's the thing that makes pods not lonely." You'll be technically correct, and that's the best kind of correct.