How Kubernetes Assigns IPs to Pods: Deep Dive into Flannel, CNI, and CRI

Understanding the Kubernetes network model is essential for ensuring each pod receives its own IP address and can communicate reliably. The article walks through the interaction of key networking components and demonstrates how they collectively provide IP allocation for pods.

Background Concepts

Container network on the same host : Linux Bridge and a veth pair connect the container’s network namespace to the host bridge, allowing containers on the same node to communicate via IP addresses. The bridge itself acts as a gateway for pod traffic leaving the node.

Containers on different hosts : Flannel uses VXLAN packet encapsulation, wrapping original packets in UDP to traverse the network. Each node creates a VXLAN device and routing tables so that inter‑node pod traffic is encapsulated, sent, and then decapsulated at the destination.

Node IPAM Controller and Pod CIDR Allocation

When the nodeipam controller is enabled via the --controllers flag of kube-controller-manager, each node receives a dedicated subnet ( podCIDR) from the cluster CIDR. These non‑overlapping subnets guarantee unique pod IPs. A node’s podCIDR is assigned when it first registers; changing it requires node removal and re‑registration.

Example command to list node names and their podCIDR:

kubectl get nodes -o wide

Kubelet, Container Runtime, and CNI Interaction

When a pod is scheduled, kubelet invokes the CRI plugin of the chosen container runtime (e.g., containerd). The CRI plugin then calls the appropriate CNI plugin to configure the pod’s network. The CNI configuration files reside by default in /etc/cni/net.d/<config-file>, and the plugins are located in /opt/cni/bin. For containerd, the paths can be set in the [plugins."io.containerd.grpc.v1.cri".cni] section of its config.

Flannel as Network Provider

Flannel’s daemon flanneld runs as a DaemonSet with an init‑container that creates the CNI config file /etc/cni/net.d/10-flannel.conflist. It obtains the node’s podCIDR and other metadata from the API server, creates a VXLAN device, and installs routes so that all pods can reach each other via IP.

Interaction diagram (illustrated in the article) shows kubelet → containerd CRI plugin → Flannel CNI plugin → VXLAN → Bridge CNI → host‑local IPAM.

CNI Plugin Chain

Flannel CNI plugin calls the Bridge CNI plugin, which creates a Linux bridge named cni0 and a veth pair for each pod. The bridge then invokes the host‑local IPAM plugin.

Host‑local IPAM plugin allocates an IP address and stores the allocation in /var/lib/cni/networks/<network-name=cni0>/<ip>. The file contains the container ID associated with that IP.

Summary

Kube‑controller‑manager assigns a unique podCIDR to each node, enabling distinct IPs for every pod. Cluster administrators configure kubelet, the container runtime, and the network provider, distributing the necessary CNI plugins to each node. Upon pod scheduling, kubelet uses the CRI plugin to create the pod, which then calls the designated CNI plugin (Flannel, Bridge, host‑local IPAM, etc.) to set up networking, ensuring pods obtain functional IP addresses across the cluster.