Kubernetes imposes a flat network model with specific guarantees. Understanding these guarantees — and how they're implemented — is essential for debugging connectivity issues, designing NetworkPolicies, and choosing CNI plugins.

1. The Three Guarantees

Kubernetes requires that any networking implementation (CNI plugin) satisfies these rules:

What This Looks Like in Practice

# Pod on node-1:
kubectl exec pod-a -- ip addr
# eth0: 10.244.1.5/24   ← Pod IP (unique across cluster)

# Pod on node-2:
kubectl exec pod-b -- ip addr
# eth0: 10.244.2.8/24   ← Different subnet, same flat network

# Connectivity test (no NAT, no port mapping):
kubectl exec pod-a -- curl 10.244.2.8:8080
# Works directly — flat network

Network Planes in a Cluster

2. Pod-to-Pod Communication

Same Node

On the same node, Pods are connected via a virtual bridge (typically cbr0 or cni0). Each Pod has a veth pair — one end in the Pod's network namespace, the other plugged into the bridge.

Traffic between Pod A and Pod B stays on the bridge — no routing needed, just L2 switching.

Cross-Node

When Pod A (node-1) talks to Pod D (node-2), the packet must leave node-1 and reach node-2. CNI plugins solve this differently:

3. IP Allocation

How Pods Get IPs

1. The cluster has a Cluster CIDR (e.g., 10.244.0.0/16)
2. Each node gets a Pod CIDR subset (e.g., node-1 gets 10.244.1.0/24 = 254 Pods max)
3. When a Pod is created, the CNI plugin assigns the next available IP from the node's Pod CIDR
4. The IP is released when the Pod is deleted

# See node Pod CIDR:
kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\
POD-CIDR:.spec.podCIDR
# NAME       POD-CIDR
# worker-1   10.244.1.0/24
# worker-2   10.244.2.0/24
# worker-3   10.244.3.0/24

IP Exhaustion

If a node's Pod CIDR is /24, it can host at most 254 Pods (minus a few reserved). Larger nodes (or many short-lived Pods) can exhaust this. Solutions:

• Use a larger per-node CIDR (--node-cidr-mask-size=23 = 510 IPs)
• Use a CNI that doesn't subdivide (EKS VPC CNI allocates from the entire VPC subnet)

4. CNI — Container Network Interface

CNI is a specification for how network plugins are invoked. The kubelet calls CNI plugins at two points:

1. ADD — when a Pod sandbox is created (assign IP, set up veth, configure routes)
2. DEL — when a Pod sandbox is removed (release IP, remove interfaces)

Popular CNI Plugins

5. Communication Types

Egress: SNAT Behavior

When a Pod connects to an external service (outside the cluster), the node SNATs the Pod IP to the node's IP. The external service sees the node IP as the source, not the Pod IP.

# Pod 10.244.1.5 on node 192.168.1.10 connects to external API:
# Source: 10.244.1.5 → SNAT → 192.168.1.10
# External API sees source: 192.168.1.10

# Exception: some CNIs (Calico, Cilium) can disable SNAT
# for specific destinations or when using direct routing

6. Debugging Network Issues

# Check Pod IP:
kubectl get pod -o wide

# Test connectivity from inside a Pod:
kubectl exec debug-pod -- curl -v http://10.244.2.8:8080
kubectl exec debug-pod -- nslookup my-service.default.svc.cluster.local
kubectl exec debug-pod -- wget -qO- --timeout=2 http://my-service:80

# Deploy a network debug Pod:
kubectl run netshoot --image=nicolaka/netshoot -it --rm -- bash
# (has curl, dig, nslookup, tcpdump, iperf, ss, ip, traceroute)

# Check node routing:
kubectl debug node/worker-1 -it --image=ubuntu -- ip route

# Check CNI logs:
kubectl logs -n kube-system -l app=calico-node --tail=50

# Check kube-proxy rules (iptables mode):
kubectl debug node/worker-1 -it --image=ubuntu -- iptables-save | grep my-service

Summary