How Do Kubernetes Pods Get Their IP? Inside Flannel, CNI, and CRI Interactions

Understanding the Kubernetes network model and the roles of its components is essential for ensuring each Pod receives a unique IP address and can communicate effectively.

Background Concepts

Container Network on the Same Host

Containers on the same node communicate via a Linux Bridge created with virtual Ethernet (veth) pairs; one end of each veth resides in the container's network namespace, the other connects to the bridge, which also holds an IP address acting as a gateway for inter‑node traffic.

Container Network on Different Hosts

Cross‑node communication relies on packet encapsulation; Flannel uses VXLAN to wrap original packets in UDP, sending them to the destination node where they are decapsulated and delivered to the target Pod.

Note: This is just one method of configuring container networking.

CRI (Container Runtime Interface)

CRI is a plugin interface that allows the kubelet to use different container runtimes; each runtime implements the CRI API, enabling flexible runtime selection.

CNI (Container Network Interface)

CNI provides a standardized plugin framework for configuring container networking; CNI plugins follow the CNI specification and are invoked when a Pod’s network is set up.

Assigning Pod IPs via Node Subnet Allocation

To guarantee unique Pod IPs across the cluster, each node receives a dedicated subnet (podCIDR) from the cluster CIDR. The node IPAM controller, enabled with the --controllers=nodeipam flag, allocates these non‑overlapping subnets, allowing the kube‑controller‑manager to assign unique IPs to Pods.

When a node first registers, it is assigned a podCIDR; changing it requires node deregistration and re‑registration.

Kubelet, Container Runtime, and CNI Plugin Interaction

When a Pod is scheduled, the kubelet invokes the container runtime (e.g., containerd) to create the container, then calls the appropriate CNI plugin to configure the Pod’s network.

Container Runtime ↔ CNI Plugin

Each network provider installs a CNI plugin; the container runtime calls this plugin during Pod startup. For containerd, the CNI configuration is placed in /etc/cni/net.d/, and the plugin binaries reside in /opt/cni/bin.

Flannel’s daemon (flanneld) creates a VXLAN device on each node, retrieves network metadata from the API server, and monitors Pod updates. It generates a CNI configuration file ( /etc/cni/net.d/10-flannel.conflist) that the container runtime uses.

CNI Plugin Interactions

The article focuses on three CNI plugins:

Flannel CNI Plugin

When Flannel is the network provider, the container runtime invokes the Flannel CNI plugin via the configuration file mentioned above.

Flanneld obtains the podCIDR and other network details from the API server and stores them in /run/flannel/subnet.env, which the Flannel CNI plugin uses to configure the Bridge CNI plugin.

Bridge CNI Plugin

The Bridge plugin creates a Linux bridge (cni0) and a veth pair for each Pod, connecting the container’s network namespace to the bridge, enabling IP‑based communication among all containers on the host.

After setting up the veth pair, the Bridge plugin calls a host‑local IPAM plugin to allocate IP addresses.

Host‑Local IPAM Plugin

This plugin returns the allocated IP for each container and stores the mapping under /var/lib/cni/networks/cni0/. The payload includes the container ID and assigned IP.

Summary

The kube‑controller‑manager assigns a unique podCIDR to each node, enabling non‑overlapping IP allocation for Pods. Cluster administrators configure and install kubelet, the container runtime, and the network provider, distributing CNI plugins to each node. When a Pod is scheduled, kubelet triggers the CRI plugin, which then invokes the appropriate CNI plugin to set up the Pod’s network, ensuring every Pod obtains a unique IP address.