Kubernetes Node Network Integration

Kubernetes Node Network Integration refers to the set of mechanisms, components, and configuration layers that connect a worker or control-plane node to the cluster network fabric so that pods scheduled on that node can communicate with pods on other nodes, with cluster services, and with external endpoints. It encompasses the node's participation in the Container Network Interface (CNI) plugin lifecycle, the routing and encapsulation rules that make pod IP addresses reachable cluster-wide, the kube-proxy or eBPF-based service routing layer, and the underlying host networking (interfaces, routes, iptables/nftables or IPVS tables) that Kubernetes relies on but does not manage directly.

Node Network Bootstrapping

Kubelet and CNI Invocation

When a pod is scheduled onto a node, the kubelet does not configure pod networking itself. Instead, it delegates this responsibility to a CNI plugin binary installed on the node, invoking it with a standardized JSON configuration read from /etc/cni/net.d/. The CNI plugin is responsible for creating a network namespace for the pod, attaching a virtual interface (commonly a veth pair), assigning an IP address from the node's allocated pod CIDR block, and configuring routes inside the pod namespace.

Pod CIDR Allocation

Each node is typically assigned a distinct subnet carved out of the cluster-wide pod CIDR range. This allocation is tracked in the Node object's spec.podCIDR field and is used by the CNI IPAM (IP Address Management) plugin to hand out non-overlapping addresses. Because each node owns a disjoint subnet, routing pod-to-pod traffic across nodes reduces to routing between subnets, which can be handled through static routes, overlay encapsulation, or BGP-advertised routes depending on the chosen network plugin.

Cross-Node Pod Connectivity Models

Overlay Networking

Overlay-based CNI plugins encapsulate pod traffic inside a tunneling protocol such as VXLAN or Geneve before it leaves the node. The node maintains a virtual tunnel endpoint (VTEP) interface, and traffic destined for a pod on a remote node is wrapped in an outer packet addressed to that node's tunnel endpoint, then decapsulated on arrival. This model requires no changes to the underlying physical network but introduces encapsulation overhead and can complicate MTU handling.

Native Routing (Unencapsulated)

Some CNI plugins avoid encapsulation entirely by programming routes directly into the node's routing table or by peering with the physical network fabric using a routing protocol such as BGP. In this model, each node advertises its pod CIDR to its peers, and the underlying network (or adjacent nodes acting as routers) forwards packets to the correct node based on standard IP routing. This approach typically yields lower latency and higher throughput than overlay networking but requires either a flat Layer 3 network or router cooperation.

IPAM and Address Conflict Avoidance

Regardless of the connectivity model, the node's CNI plugin must coordinate with a cluster-wide IPAM authority, often backed by the Kubernetes API server or an external datastore, to prevent two nodes from allocating overlapping pod IP ranges. Misconfigured IPAM is a common source of node network integration failures, manifesting as intermittent packet loss or asymmetric routing.

Service Routing Integration

kube-proxy Modes

The node also participates in cluster service routing through kube-proxy, which runs as a daemon (or DaemonSet pod) on every node. kube-proxy watches the API server for Service and EndpointSlice objects and programs the node's packet-forwarding layer accordingly. It supports several backend modes:

• iptables mode: programs NAT rules that probabilistically load-balance traffic across service endpoints using chains of iptables rules.
• IPVS mode: uses the Linux kernel's IP Virtual Server subsystem, offering better performance at high service/endpoint counts through hash-table-based lookups rather than sequential rule evaluation.
• eBPF-based dataplanes: certain CNI implementations replace kube-proxy entirely with eBPF programs attached to network hooks, performing service load balancing and network policy enforcement with lower per-packet overhead.

ClusterIP Resolution at the Node Level

When a pod sends traffic to a Service's ClusterIP, the node intercepts the packet before it leaves the host, rewrites the destination address to one of the Service's backing pod IPs, and forwards it using the same cross-node pod connectivity path described above. This interception happens transparently to the pod, which only ever sees the stable ClusterIP.

Network Policy Enforcement at the Node

Policy Programming

If the cluster's CNI plugin supports NetworkPolicy objects, each node is responsible for enforcing policies that apply to pods scheduled on it. The node-local policy agent translates NetworkPolicy specifications into packet filtering rules, most commonly through iptables, nftables, or eBPF, evaluated as traffic enters or leaves a pod's veth interface.

Ingress and Egress Scoping

Because policy enforcement is node-local, the node must have visibility into pod labels and namespace selectors, which it obtains by watching the relevant API objects. A node that loses connectivity to the API server can enforce stale policy state but cannot react to policy changes until connectivity is restored.

Node-Level Network Interfaces

Bridge and veth Topology

A common node network topology uses a Linux bridge (or equivalent virtual switch) to which every pod's veth interface is attached. The bridge forwards traffic between pods on the same node at Layer 2, while traffic destined for other nodes is handed off to the routing or encapsulation layer.

Host Network Namespace Interaction

Pods configured with hostNetwork: true bypass this pod-networking layer entirely, sharing the node's own network namespace and interfaces directly. This is used sparingly, typically for system-level daemons that need direct access to node interfaces, such as network plugins themselves.

MTU and Packet Fragmentation Considerations

Encapsulation Overhead

When overlay networking is used, the outer encapsulation header consumes part of the packet's available payload space. If the node's physical interface MTU is not adjusted downward, or the pod interface MTU is not correspondingly reduced, packets can be fragmented or silently dropped at the point of encapsulation, producing intermittent connectivity issues that are difficult to diagnose without packet capture.

Path MTU Discovery Interaction

Kubernetes node network integration must also account for how Path MTU Discovery interacts with encapsulated traffic, since ICMP "fragmentation needed" messages generated inside the overlay may not propagate correctly back to the originating pod, requiring the CNI plugin to explicitly clamp TCP MSS values on node-level interfaces.

Node Readiness and Network Health Signals

CNI Readiness Gating

The kubelet reports a node as NotReady if the configured CNI plugin has not been successfully initialized, since without functioning pod networking the node cannot safely host workloads. This is surfaced through the node's NetworkUnavailable condition, which is cleared once the CNI plugin confirms successful configuration.

Route and Interface Reconciliation

Network plugins commonly run a node-local reconciliation loop that continuously verifies that expected routes, bridge interfaces, and tunnel endpoints remain correctly configured, correcting drift caused by host reboots, interface renumbering, or manual intervention.