Demystifying Kubernetes Networking: From Pods to Services and Beyond

Kubernetes is built for running distributed clusters, making networking a core component; understanding its network model helps you run, monitor, and troubleshoot applications correctly.

The guide first defines basic Kubernetes terminology, then explores the Kubernetes network model and its design decisions, followed by detailed sections on container networking, pod‑to‑pod communication, pod‑to‑service routing, and internet access.

Kubernetes Basics

Kubernetes API Server

The API server (kube‑apiserver) is the gateway to the etcd data store, exposing the desired state of the cluster via API calls.

Controllers

Controllers continuously observe the API server and reconcile the actual cluster state with the desired state. In pseudocode:

while true:
    X = currentState()
    Y = desiredState()
    if X == Y:
        return  # Do nothing
    else:
        do(tasks to get to Y)

Pods

A Pod is the smallest deployable unit in Kubernetes, encapsulating one or more containers, shared storage, and a unique IP address.

Nodes

Nodes are the machines (bare metal, VM, etc.) that run the cluster.

Kubernetes Network Model

Kubernetes imposes the following requirements on any network implementation:

All Pods must communicate with each other without NAT.

All Nodes must communicate with all Pods without NAT.

Pods must see their own IP address exactly as other Pods see it.

Four networking problems arise from these constraints:

Container‑to‑container networking

Pod‑to‑Pod networking

Pod‑to‑Service networking

Internet‑to‑Service networking

Container and Container Networking

Linux provides network namespaces, each with its own routing table, firewall rules, and devices. Create a namespace with: $ ip netns add ns1 The namespace appears under /var/run/netns and can be inspected with ls /var/run/netns and ip netns.

By default, all processes run in the root network namespace, which provides external connectivity.

Pods share a network namespace, giving containers the same IP and port space. The diagram below shows a Pod composed of multiple Docker containers sharing a namespace.

Pod‑to‑Pod Communication

Each Pod has a real IP address. Within the same node, communication uses a virtual Ethernet (veth) pair that connects the Pod's namespace to the root namespace, and a Linux bridge (cbr0) forwards packets based on ARP.

Cross‑node communication relies on each node receiving a CIDR block. Traffic is routed to the correct node, then to the target Pod via its veth pair and bridge.

AWS uses the Amazon VPC CNI plugin, which creates an Elastic Network Interface (ENI) for each Pod, allowing Pods to have routable IPs within the VPC.

Pod‑to‑Service Communication

Kubernetes Services provide a stable virtual IP (VIP) that abstracts a set of Pods. kube‑proxy installs iptables (or IPVS) rules that rewrite Service IPs to the selected Pod IPs.

netfilter and iptables

netfilter is the Linux packet‑filtering framework. iptables configures chains and rules to perform NAT, filtering, and load‑balancing.

IPVS

IPVS implements transport‑layer load balancing inside the kernel, offering higher performance than iptables.

Internet ↔ Service Communication

Egress (Pod → Internet)

In AWS, a VPC Internet Gateway performs NAT for VM IPs, but not for Pod IPs. iptables performs source NAT (SNAT) so that traffic appears to originate from the node's IP before reaching the gateway.

Ingress (Internet → Service)

Ingress can be implemented via a cloud LoadBalancer (L4) or an Ingress Controller (L7). A LoadBalancer distributes traffic to nodes, where iptables routes it to the correct Pod.

Ingress Controllers (e.g., AWS ALB Ingress) create an Application Load Balancer that routes HTTP/HTTPS traffic to Services based on URL paths.

Conclusion

This guide provides a foundation for understanding the Kubernetes networking model and its support for common networking tasks. For deeper issues, consult the official Kubernetes documentation and community resources.