Kubernetes Node Network Handling

Kubernetes Node Network Handling is the set of responsibilities a node carries out to give itself cluster connectivity and to give every Pod scheduled onto it a functioning network identity, spanning the node's own host networking configuration, the CNI-driven setup of each Pod's network namespace, and the kube-proxy-managed rules that implement Service-level traffic routing on that node. Unlike volume or image handling, which are almost entirely kubelet-driven, node network handling is split across several cooperating components — the kubelet, the CNI plugin it invokes, and kube-proxy — each responsible for a different layer of the node's networking stack.

Node-Level Network Prerequisites

Host Networking and CIDR Allocation

Every node is assigned a Pod CIDR range, a slice of the cluster's overall Pod network address space from which that node's Pods will draw their IP addresses; this allocation is typically performed by the control plane's node IPAM controller and recorded on the Node object, and it is this range that the node's CNI plugin uses when assigning addresses to new Pod sandboxes.

Node Readiness and Networking

The kubelet reports a node as not ready for scheduling until its network configuration, including the CNI plugin's readiness, is confirmed functional; a node whose CNI plugin binary or configuration is missing or broken will typically surface a NetworkNotReady condition, blocking Pods from being scheduled to it even if compute resources are otherwise available.

CNI-Driven Pod Networking

Invocation During Sandbox Creation

As described under Pod Sandbox Execution, the kubelet's container runtime invokes the configured CNI plugin at the point a Pod's sandbox network namespace is created, passing the plugin the sandbox's namespace path and the node's CNI configuration, and the plugin is responsible for wiring that namespace into the broader Pod network.

What the CNI Plugin Actually Does

A CNI plugin typically creates a virtual ethernet pair, placing one end inside the Pod's network namespace as its primary interface and the other end connected to a node-level bridge or routing construct, assigns an IP address to the Pod-side interface from the node's allocated CIDR, and configures routes so that traffic to and from that IP flows correctly across the underlying network fabric, whether that fabric is implemented through overlay encapsulation, direct routing, or cloud-provider-native networking.

Plugin Diversity and Chaining

Because CNI defines a plugin interface rather than a single implementation, clusters commonly run one of several CNI implementations, and CNI itself supports chaining multiple plugins together, such as combining a primary networking plugin with a separate plugin that applies NetworkPolicy enforcement or attaches additional network interfaces to a Pod.

kube-proxy and Service Traffic on the Node

Watching Services and Endpoints

kube-proxy runs on every node and watches the API server for Service and EndpointSlice objects, translating each Service's ClusterIP and port into a set of rules that redirect traffic destined for that virtual IP toward one of the Service's backing Pod endpoints, load-balancing across them according to its configured mode.

Proxy Modes

Depending on configuration, kube-proxy implements this redirection using iptables rules, IPVS virtual servers, or, in newer configurations, eBPF-based dataplanes such as those provided by certain CNI implementations acting as a kube-proxy replacement; regardless of mode, the effect is the same from a Pod's perspective — traffic sent to a Service's ClusterIP is transparently redirected to a healthy backend Pod without the sending Pod needing any awareness of which backend actually received it.

Node-Local and External Traffic Handling

kube-proxy's rules also govern how NodePort and LoadBalancer Service traffic arriving at the node is handled, including whether externalTrafficPolicy settings cause traffic to be routed only to Pods on the receiving node (preserving the original client source IP) or load-balanced across Pods cluster-wide (which may involve an additional network hop and SNAT).

DNS Resolution at the Node Level

kubelet-Configured Pod DNS

The kubelet configures each Pod's /etc/resolv.conf at sandbox creation time based on the Pod's dnsPolicy, typically pointing Pods to the cluster's internal DNS service address so that Service and Pod name resolution functions correctly from inside the Pod's network namespace, independent of whatever DNS configuration the node itself uses for its own host-level resolution.

Failure Modes in Node Network Handling

CNI Plugin Failures

A CNI plugin crash, misconfiguration, or IP address exhaustion within a node's allocated CIDR range will cause sandbox creation to fail, which the kubelet surfaces as a Pod stuck in ContainerCreating along with an event describing the underlying CNI error.

kube-proxy Rule Staleness

If kube-proxy falls behind in processing Service or EndpointSlice updates — due to being down, restarting, or under heavy load — Pods on that node may continue routing Service traffic to endpoints that have since been removed or may fail to pick up newly added healthy endpoints, producing intermittent connectivity issues that are local to the affected node rather than cluster-wide.