Kubernetes Networking Explained: Pods, Services, DNS

— ny_wk

Kubernetes networking trips up almost everyone at first, because it quietly breaks the rules you expect from plain Docker. The good news: once you grasp four kinds of communication, the whole model clicks. Let's walk through them.

1. Containers in the same pod

Containers inside one pod share a single network namespace — same IP, same port space. They talk to each other over localhost. That's why a sidecar (say, a logging agent) can reach the main app at 127.0.0.1:8080. They can also share files through a common volume mounted into both containers.

2. Pods on the same node

Every pod gets its own IP address. Pods on the same node reach each other directly by that IP — no port mapping, no NAT. This is the first surprise for Docker users: in Kubernetes, pods are first-class network citizens.

3. Pods on different nodes

Here's the core promise of the Kubernetes network model: every pod can reach every other pod by IP, across all nodes, without NAT. Kubernetes itself doesn't implement this — a CNI plugin (Calico, Flannel, Cilium, and others) wires up the flat overlay or routed network that makes it true. Pick one at cluster setup; it handles the cross-node plumbing.

4. Pods and Services

Pods are disposable — they die, restart, and get new IPs constantly. You can't hardcode a pod IP. A Service solves this by giving a stable virtual IP and name in front of a set of pods (chosen by label selector). Traffic to the Service is load-balanced across the healthy pods behind it, with kube-proxy programming the routing on each node.

How DNS and discovery work

Service discovery runs on DNS, handled by CoreDNS inside the cluster. Create a Service named payments in namespace shop, and any pod can reach it at payments.shop.svc.cluster.local (or just payments from within the same namespace). So you connect to names, not IPs — and the names stay stable even as pods churn.

Key takeaways

• Same pod → talk over localhost; share data via a shared volume.
• Every pod has its own IP; pods reach each other directly, no NAT — a CNI plugin makes that work across nodes.
• Services give a stable IP + name and load-balance across pods.
• CoreDNS resolves Service names like name.namespace.svc.cluster.local.

Frequently asked questions

Why can't I just use pod IPs?

Pods are ephemeral — their IPs change on every restart. Use a Service's stable IP/name instead.

What does a CNI plugin do?

It implements pod-to-pod networking across nodes (the flat, NAT-free network Kubernetes assumes). Examples: Calico, Flannel, Cilium.

How do containers in one pod communicate?

They share a network namespace, so they reach each other on localhost and can share files through a common volume.

What resolves Service names?

CoreDNS, the in-cluster DNS server, maps Service names to their virtual IPs.

Four flows, one flat network, names instead of IPs — that's Kubernetes networking in a nutshell.