4.11 Kubernetes Node Network Handling

Kubernetes Node Network Handling is the set of responsibilities a worker node fulfills to give pods functioning network connectivity, spanning CNI plugin invocation for pod interfaces, kube-proxy's implementation of Service routing, and the underlying host networking configuration that ties pod traffic into the broader cluster network. It operates at both the individual pod level, through per-sandbox network setup, and at the node level, through cluster-wide routing and Service abstraction.

CNI Plugin Execution on the Node

Invocation During Sandbox Creation

When the container runtime creates a pod sandbox, it invokes the CNI plugin binary configured on the node, passing the sandbox's network namespace path along with configuration read from CNI configuration files, typically located under /etc/cni/net.d.

IP Address Management

CNI plugins commonly delegate IP address allocation to an IPAM plugin, which tracks which IP addresses within the node's assigned pod CIDR block have already been allocated, ensuring each new pod sandbox receives a unique address without conflicts.

Interface and Route Creation

The CNI plugin creates a virtual network interface, often a veth pair with one end placed inside the pod's network namespace and the other attached to a bridge or directly routed on the host, then configures routes so that traffic to and from the pod's IP address flows correctly through the node's networking stack.

Pod CIDR Allocation

Per-Node CIDR Assignment

In many cluster networking models, the control plane assigns each node a distinct slice of the overall cluster pod CIDR range. This per-node CIDR is recorded in the node object and consulted by the node's CNI plugin and IPAM component when allocating addresses to new pods.

Route Propagation

For CNI implementations that rely on direct routing rather than overlay encapsulation, each node must learn routes to other nodes' pod CIDR ranges, either through a routing protocol such as BGP, run by components like Calico, or through static routes programmed into the node's routing table.

kube-proxy and Service Routing

The kube-proxy Node Agent

kube-proxy runs on every node as a component responsible for implementing the Service abstraction at the node level, translating a Service's virtual IP address into routing rules that direct traffic toward one of the Service's backing pod endpoints.

iptables Mode

In iptables mode, kube-proxy watches Services and Endpoints objects and programs iptables NAT rules on the node that intercept traffic destined for a Service's ClusterIP, performing destination address translation to redirect it to a randomly selected backend pod IP.

IPVS Mode

In IPVS mode, kube-proxy configures the Linux kernel's IP Virtual Server subsystem, which maintains an in-kernel table of virtual servers and real backend servers, offering better performance characteristics than iptables at very large numbers of Services due to its use of hash tables rather than sequential rule evaluation.

Endpoint Slice Watching

kube-proxy watches EndpointSlice objects, which track the actual pod IPs backing each Service, and updates its routing rules dynamically as pods are created, deleted, or transition between ready and not-ready states, ensuring traffic is only routed to healthy backends.

Node-Level DNS Configuration

DNS Resolver Injection

For each pod, the kubelet configures a resolv.conf inside the pod's network namespace pointing to the cluster's DNS service, typically CoreDNS, unless the pod's dnsPolicy specifies otherwise, allowing containers to resolve Service names and other cluster-internal DNS records.

dnsPolicy Variations

The kubelet respects different dnsPolicy values such as ClusterFirst, Default, and None, each producing a different resolv.conf configuration inside the pod, ranging from cluster DNS resolution to inheriting the node's own DNS configuration or using an entirely custom configuration supplied in the pod spec.

Network Policy Enforcement

Policy Plugin Integration

When NetworkPolicy resources are in use, a compatible CNI plugin, such as Calico or Cilium, installs packet filtering rules on the node, commonly through iptables, nftables, or eBPF programs, to enforce ingress and egress restrictions between pods according to policy selectors.

Per-Node Policy Programming

Because NetworkPolicy enforcement happens at the node hosting the relevant pods, each node independently programs the filtering rules necessary to enforce policies affecting the pods scheduled to it, watching the API server for NetworkPolicy, Pod, and Namespace changes that affect its local enforcement state.

Node Network Health and Reporting

Node Network Unavailable Condition

The kubelet, or in some configurations the cloud controller manager, can set a NetworkUnavailable condition on the node object when node-level routing configuration has not yet completed, preventing the scheduler from placing pods on a node before its networking is fully functional.

MTU and Interface Configuration Consistency

Consistent MTU settings across nodes are important for CNI plugins that rely on encapsulation, such as VXLAN overlays, since mismatched MTU values between nodes can lead to packet fragmentation issues or dropped traffic between pods on different nodes.