Kubernetes Pod Networking and CNI

Pods must talk to each other across many machines as if all of them sat on one big network. Kubernetes defines the rules for that network and delegates the wiring to plugins. Understanding these rules explains why services, DNS, and network policies behave the way they do.

The Four Networking Rules

1. Every pod receives its own unique IP address.
2. Pods on any node reach pods on any other node without address translation.
3. Agents on a node, such as the kubelet, reach all pods on that node.
4. Containers inside one pod share a single IP and talk over localhost.

Think of a large office building. Every employee gets a personal phone extension, and anyone can dial anyone else directly. Roommates sharing one desk (containers in one pod) share a single extension and talk face to face.

Four Kinds of Traffic

Traffic	Handled by
Container to container in one pod	Shared network namespace, localhost
Pod to pod	CNI plugin
Pod to service	kube-proxy or the CNI plugin
External client to service	NodePort, LoadBalancer, Ingress, or Gateway

What Happens Inside a Node

Each pod gets a private network namespace, which is an isolated copy of the Linux network stack. A virtual cable called a veth pair links that namespace to the node. One end sits inside the pod and appears as eth0. The other end plugs into a bridge or routing table on the node.

 Node 1 (10.244.1.0/24)
 ┌───────────────────────────────────────────┐
 │  ┌─────────────┐     ┌─────────────┐      │
 │  │ Pod A       │     │ Pod B       │      │
 │  │ 10.244.1.5  │     │ 10.244.1.6  │      │
 │  │ eth0        │     │ eth0        │      │
 │  └──────┬──────┘     └──────┬──────┘      │
 │      veth pair           veth pair        │
 │         └──────────┬───────────┘          │
 │               Bridge / routes             │
 └────────────────────┬──────────────────────┘
                      │
                 Node network

Crossing Nodes

Each node owns a slice of the pod address range (the pod CIDR). Traffic for a pod on another node travels through one of two designs.

Overlay Network

The plugin wraps each packet inside another packet (VXLAN is a common format) and sends it across the existing node network. The receiving node unwraps it and delivers it to the pod. Overlays work almost anywhere and need little setup. The wrapping adds a small speed cost.

Routed Network

The plugin teaches the network about pod ranges, often with the BGP routing protocol. Packets travel unwrapped, which gives better speed and simpler troubleshooting. Routed designs need cooperation from the underlying network.

 Pod A (Node 1) ──▶ Node 1 ═══ wrapped in VXLAN ═══▶ Node 2 ──▶ Pod C (Node 2)
                    10.244.1.5                         10.244.2.8

What CNI Means

The Container Network Interface (CNI) is a standard that defines how a runtime asks a plugin to connect a container to a network. When the kubelet starts a pod, it calls the plugin to create the interface, assign an IP, and set up routes. When the pod stops, the plugin cleans up.

Kubernetes ships no network by default. A cluster needs a CNI plugin installed, and nodes show NotReady until one runs.

Popular CNI Plugins

Plugin	Strength
Flannel	Simple overlay for small clusters and learning
Calico	Routed or overlay networking with strong network policy support
Cilium	eBPF-based networking, deep visibility, and advanced policy
Cloud plugins (AWS VPC CNI, Azure CNI)	Pods receive addresses from the cloud network directly

Network policies work only when the chosen plugin supports them. Flannel alone does not enforce policies.

Where kube-proxy Fits

Services own virtual IP addresses that belong to no pod. The kube-proxy component on each node programs rules (iptables or IPVS) that rewrite a service address to one of the healthy pod addresses. Some plugins, such as Cilium, replace kube-proxy with their own eBPF programs.

Inspecting Your Cluster Network

kubectl get pods -o wide
kubectl get nodes -o custom-columns=NAME:.metadata.name,CIDR:.spec.podCIDR
kubectl get pods -n kube-system
kubectl exec -it pod-a -- ping 10.244.2.8

The -o wide output lists pod IPs and node names, which shows quickly whether two pods share a node.

Troubleshooting Checklist

• Nodes stuck in NotReady often signal a missing or crashed CNI plugin.
• Pods stuck in ContainerCreating with a network error point to IP exhaustion or a broken plugin pod.
• Pod CIDR ranges that overlap with the node network cause lost packets. Plan address ranges before cluster creation.
• Test pod to pod reachability before blaming services or DNS.

Key Points

• Every pod owns an IP, and all pods reach each other without translation.
• CNI plugins build and maintain this flat network.
• Overlays wrap packets; routed designs forward them directly.
• Plugin choice decides which features, such as network policies, a cluster can use.