Kubernetes Pod Networking: How Pods Communicate Across Nodes

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Kubernetes requires every pod to have a routable IP and reach every other pod without NAT, regardless of node. CNI plugins (Flannel, Calico, Cilium) implement this via either overlay networks (VXLAN encapsulation over existing network) or underlay networks (BGP advertises pod CIDRs directly). Cilium uses eBPF for kernel-level packet processing without iptables overhead. Services + CoreDNS layer stable names and load balancing on top. NetworkPolicies enforce microsegmentation at the CNI layer.

Interview Answer3 min

Kubernetes networking is built on a flat network model: every pod gets its own IP and every pod can reach every other pod by IP across any node without NAT. The CNI plugin is the software that implements this on real hardware.

The flat network model

Every pod has a unique IP from the pod CIDR; pods on different nodes communicate directly — this simplicity is what makes DNS-based service discovery predictable and service-mesh routing reliable.
kube-proxy on each node maintains iptables or IPVS rules that translate a ClusterIP to one of the backend pod IPs — this is how payment-service.default.svc.cluster.local resolves to a stable virtual IP that load-balances to actual pod IPs.

CNI plugins — the implementation

The CNI spec defines how Kubernetes networking plugs in; Calico, Flannel, Cilium, Weave, and cloud-native CNIs (AWS VPC, Azure) are all implementations; your cluster runs one.
Calico with BGP advertises pod routes between nodes so pods route directly without encapsulation — near-native speed, requires BGP-capable network.
Cilium with eBPF runs packet routing programs in the kernel, bypassing iptables for better performance and richer policy — many new managed clusters default to or offer Cilium.
AWS VPC CNI gives pods real VPC IPs so you can use Security Groups and VPC routing directly — the trade-off is pod density limits tied to EC2 instance type.

Network Policies — access control

Without NetworkPolicies, every pod can reach every other pod on any port cluster-wide — a security risk in multi-team clusters.
NetworkPolicies are additive: a policy allowing ingress from the payments namespace is combined with any other policies on that pod; there is no default-deny until you explicitly create one.
Start with a default-deny-all ingress policy per namespace, then add explicit allow rules — the only approach that provides meaningful isolation.
Flannel alone does NOT enforce NetworkPolicy — it is silently ignored; pair with Canal (Calico + Flannel) or switch to Calico / Cilium for real policy enforcement.

Debugging the stack

Walk bottom-up: DNS resolution (CoreDNS), Service endpoints (label match), direct pod-to-pod connectivity (bypasses Service), NetworkPolicy, then CNI-layer tools (cilium monitor, calicoctl).
MTU mismatches on overlay networks cause silent hangs — set pod MTU to 1450 if using VXLAN over 1500-MTU networks.

Interview-ready guide

Interview answer

The flat network model

Every pod has a unique IP from the pod CIDR; pods on different nodes communicate directly — this simplicity is what makes DNS-based service discovery predictable and service-mesh routing reliable.
kube-proxy on each node maintains iptables or IPVS rules that translate a ClusterIP to one of the backend pod IPs — this is how payment-service.default.svc.cluster.local resolves to a stable virtual IP that load-balances to actual pod IPs.

CNI plugins — the implementation

The CNI spec defines how Kubernetes networking plugs in; Calico, Flannel, Cilium, Weave, and cloud-native CNIs (AWS VPC, Azure) are all implementations; your cluster runs one.
Calico with BGP advertises pod routes between nodes so pods route directly without encapsulation — near-native speed, requires BGP-capable network.
Cilium with eBPF runs packet routing programs in the kernel, bypassing iptables for better performance and richer policy — many new managed clusters default to or offer Cilium.
AWS VPC CNI gives pods real VPC IPs so you can use Security Groups and VPC routing directly — the trade-off is pod density limits tied to EC2 instance type.

Network Policies — access control

Without NetworkPolicies, every pod can reach every other pod on any port cluster-wide — a security risk in multi-team clusters.
NetworkPolicies are additive: a policy allowing ingress from the payments namespace is combined with any other policies on that pod; there is no default-deny until you explicitly create one.
Start with a default-deny-all ingress policy per namespace, then add explicit allow rules — the only approach that provides meaningful isolation.
Flannel alone does NOT enforce NetworkPolicy — it is silently ignored; pair with Canal (Calico + Flannel) or switch to Calico / Cilium for real policy enforcement.

Debugging the stack

Walk bottom-up: DNS resolution (CoreDNS), Service endpoints (label match), direct pod-to-pod connectivity (bypasses Service), NetworkPolicy, then CNI-layer tools (cilium monitor, calicoctl).
MTU mismatches on overlay networks cause silent hangs — set pod MTU to 1450 if using VXLAN over 1500-MTU networks.

03 · Deep dive