8.18 Kubernetes Pod Network Configuration

Kubernetes Pod Network Configuration is the collection of settings, abstractions, and underlying mechanisms that determine how a Pod communicates over the network, both with other Pods in the cluster and with resources outside it. Every Pod is assigned its own network namespace, its own IP address, and shares that network stack among all containers running within it, allowing containers in the same Pod to communicate with one another over localhost while remaining addressable as a single network entity from the rest of the cluster.

The Pod Network Model

Flat Address Space

Kubernetes networking is built on the principle that every Pod receives a unique IP address that is routable within the cluster without requiring Network Address Translation between Pods. This flat address space means that any Pod can reach any other Pod's IP address directly, regardless of which node they are scheduled on, simplifying application design since containers do not need to be aware of the underlying host topology.

Shared Network Namespace Within a Pod

All containers within a single Pod share the same network namespace, meaning they share the same IP address and port space. This is achieved through a special infrastructure container, often called the pause container, which holds the network namespace open for the lifetime of the Pod while application containers attach to it. Containers within the Pod communicate with each other using localhost and must coordinate to avoid binding to the same port.

Container Network Interface

CNI Plugins

The Container Network Interface, commonly abbreviated CNI, is the specification that Kubernetes relies on to configure networking for Pods. When a Pod is scheduled onto a node, the kubelet invokes a CNI plugin to allocate an IP address and set up the necessary network interfaces, routes, and rules. Popular CNI implementations include Calico, Cilium, Flannel, and Weave Net, each offering different tradeoffs in terms of performance, encryption, and policy enforcement capabilities.

IP Address Management

CNI plugins typically include an IP Address Management component responsible for allocating IP addresses to Pods from a configured address range, often divided into per-node subnets. This ensures that each node is assigned a distinct block of addresses, avoiding conflicts as Pods are created and destroyed across the cluster.

Pod-Level Networking Fields

hostNetwork

Setting hostNetwork: true in the Pod specification causes the Pod to share the network namespace of the host node directly rather than receiving its own isolated network namespace. This means the Pod's processes bind directly to the host's network interfaces and ports, which is occasionally required for workloads that need to observe or manipulate host-level network traffic, though it removes the network isolation otherwise provided between the Pod and the node.

hostPort

The hostPort field, specified within a container's port definition, binds a container port directly to a port on the host node, making the Pod reachable via the node's IP address on that specific port. Because only one Pod on a given node can bind to a particular host port at a time, this approach is generally reserved for specific use cases such as DaemonSets that require a fixed, predictable port on every node.

DNS Policy and DNS Config

The dnsPolicy field controls how a Pod resolves DNS names, with common values including ClusterFirst, which routes queries for cluster-internal names through the cluster's DNS service while forwarding other queries upstream, and Default, which inherits the DNS configuration of the node itself. The dnsConfig field allows further customization, including specifying custom nameservers, search domains, and resolver options for Pods with specialized resolution requirements.

Service Discovery and Pod Connectivity

Services as Stable Network Endpoints

Because Pod IP addresses are ephemeral and change whenever a Pod is recreated, Kubernetes Services provide a stable virtual IP address and DNS name that load balances traffic across a dynamic set of matching Pods. Pod network configuration works in conjunction with Services, since the Pod's labels determine which Service selectors match it and therefore which traffic it receives.

Readiness and Endpoint Inclusion

A Pod's network reachability through a Service is also governed by its readiness state. Only Pods that report as ready through their configured readiness probes are included in a Service's endpoint list, ensuring that traffic is not routed to Pods that are still initializing or are otherwise unable to serve requests.

Network Policies

Restricting Pod-to-Pod Traffic

NetworkPolicy resources allow administrators to define rules that restrict which Pods can communicate with one another, based on label selectors, namespaces, and IP block ranges. By default, Pods accept traffic from any source, and applying a NetworkPolicy that selects a Pod switches that Pod into a mode where only explicitly allowed traffic is permitted, whether that be ingress traffic arriving at the Pod or egress traffic leaving it.

Enforcement Dependency on CNI

Network policies are only enforced if the underlying CNI plugin supports policy enforcement. Some simpler CNI implementations handle only basic connectivity and ignore NetworkPolicy resources entirely, which means the choice of network plugin has a direct impact on whether network-level segmentation between Pods can be enforced at all.

Multi-Container Networking Patterns

Sidecar Containers Sharing the Pod Network

Sidecar containers, such as service mesh proxies, take advantage of the shared Pod network namespace to intercept and manage traffic entering or leaving the Pod without requiring changes to the application container itself. This pattern is central to service mesh architectures, where a proxy sidecar transparently handles encryption, retries, and traffic routing on behalf of the application.

Init Containers and Network Readiness

Init containers, which run to completion before application containers start, can be used to perform network-related setup tasks such as waiting for a dependent service to become reachable or configuring routing rules within the shared Pod network namespace before the main application begins execution.