Chapter 1
Kubernetes Networking Fundamentals
Modern applications thrive on intricate, dynamic connectivity-and Kubernetes elevates this concept with a powerful, yet often misunderstood, network model. This chapter reveals the multifaceted underpinnings of Kubernetes networking, inviting you to go beyond surface abstractions. From pod-to-pod communication and container interfaces, to plugin architectures and policy enforcement, you'll unravel how Kubernetes transforms isolated workloads into cohesive, resilient distributed systems.
1.1 Pod Networking Concepts
Kubernetes pod networking constitutes the foundational layer enabling containerized workloads to communicate reliably and efficiently in a distributed environment. Central to this model is the assignment of IP addresses directly to pods, which serve as the smallest deployable units in Kubernetes. Each pod typically receives a unique, routable IP address within a flat network space, facilitating direct addressing and simplifying service discovery and load balancing.
IP Address Allocation and Flat Addressability
Kubernetes embraces a flat addressability paradigm ensuring every pod can address every other pod by its internal IP, irrespective of node location. This model contrasts with traditional NAT-based container networking where IP addresses are often ephemeral and non-routable across hosts. IP allocation to pods is typically managed by the Container Network Interface (CNI) plugins such as Calico, Flannel, or Weave. These plugins implement and enforce the cluster-level IP addressing scheme, allocating IP ranges per node and ensuring no overlap among pods.
For example, a cluster on a 10.244.0.0/16 network might allocate 10.244.1.0/24 to pods on node 1 and 10.244.2.0/24 to node 2. Within each node, the CNI plugin assigns an IP from the node-specific subnet to each pod. This structured allocation enables simplified routing and supports scalability by avoiding IP conflicts and facilitating predictable network ranges.
Linux Network Namespaces and Isolated Interfaces
Each pod operates within a distinct Linux network namespace (netns), isolating its network stack-including interfaces, routing tables, and firewall rules-from other pods and the host. This architectural choice ensures pods can maintain independent networking behavior analogous to a virtual machine, but without the associated overhead.
When a pod is instantiated, Kubernetes (via the CNI plugin) creates a new network namespace. One or more network interfaces are attached to this namespace, including a loopback device and typically a virtual ethernet (veth) pair connecting the pod namespace to the node's root network namespace. The peer veth end resides on a Linux bridge or other data-plane element managing cross-host connectivity.
The lifecycle of these network interfaces is tightly coupled to the pod's lifecycle. When the pod is terminated, its network namespace and interfaces are destroyed, releasing the allocated IP resources. This encapsulation supports security and resource isolation at the kernel level without requiring additional virtualization layers.
# Create network namespace for pod ip netns add pod-1234 # Create veth pair ip link add veth0 type veth peer name veth1 # Assign veth0 to pod namespace and bring interfaces up ip link set veth0 netns pod-1234 ip netns exec pod-1234 ip link set dev veth0 up ip link set dev veth1 up # Assign IP address to veth0 inside pod namespace ip netns exec pod-1234 ip addr add 10.244.1.10/24 dev veth0 Host Networking versus Pod Networking
Kubernetes supports two primary networking modes: host networking and pod networking. Under host networking, pods share the node's network namespace, including its IP address and interfaces. This mode grants the pod direct access to host network resources, suitable for performance-critical applications but at the cost of reduced isolation. Host-networked pods bypass the Kubernetes network model, relying on the physical host's network configuration and ports.
Pod networking, conversely, isolates the pod's network, assigning it a unique IP and interfaces within dedicated network namespaces. This isolation enforces security and consistent routing behaviors cluster-wide, independent of underlying node variations. Containerized applications within pods can bind to well-known ports without clashing across nodes due to this namespace segmentation.
Inter-Pod Communication Within and Across Nodes
Within a node, inter-pod communication leverages the Linux virtual switch mechanisms that connect the pod's veth interfaces to bridges or software-defined networking devices. These constructs efficiently forward packets using kernel routing tables and can incorporate policy enforcement.
For cross-node pod communication, Kubernetes relies on overlay or underlay networking plugins to enable seamless addressing across physical hosts. Overlay networks such as VXLAN encapsulate Layer 3 pod traffic within Layer 2 frames, making pods appear as if they reside on a flat Layer 2 domain. Underlay...
