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

Background

Kubernetes requires every Pod to have its own IP address for inter‑Pod communication. New users often know the components (CNI, CRI, container runtime) but not how they work together to allocate these IPs.

Container Network Basics

On a single host, containers communicate via a Linux Bridge created with virtual Ethernet (veth) pairs: one end lives in the container’s network namespace, the other attaches to the host bridge, which also receives an IP address acting as a gateway for outbound traffic.

Across different hosts, Flannel uses VXLAN packet encapsulation. Each node creates a VXLAN device and routing entries; packets are wrapped in UDP, sent to the destination node, unwrapped, and delivered to the target Pod.

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

CRI and CNI Overview

The Container Runtime Interface (CRI) lets kubelet interact with various container runtimes. Those runtimes implement the CRI API, enabling Kubernetes to use the runtime of choice.

The Container Network Interface (CNI) project defines a plugin model for Linux container networking. CNI plugins follow the CNI specification and are invoked when a Pod’s network is set up.

Assigning Pod IPs via Node IPAM

When the nodeipam controller is enabled via the --controllers flag on kube-controller-manager, each node receives a dedicated subnet (podCIDR) from the cluster CIDR. Because these subnets are non‑overlapping, every Pod can be assigned a unique IP address.

On first registration, a node gets a podCIDR. Changing a node’s podCIDR requires deregistering the node and re‑adding it with the new configuration.

Kubelet, Container Runtime, and CNI Interaction

When a Pod is scheduled, kubelet triggers the container runtime (e.g., containerd) to create the container, then calls the appropriate CNI plugin to configure networking. The network provider (Flannel) installs a CNI plugin on each node and provides a configuration file, typically /etc/cni/net.d/10-flannel.conflist.

Flannel’s daemon (flanneld) obtains the podCIDR and other network metadata from the API server, stores them in /run/flannel/subnet.env, and creates a VXLAN device. It then uses the Bridge CNI plugin to create a Linux bridge (cni0) and veth pairs for each Pod.

Bridge CNI and Local IPAM

The Bridge CNI plugin creates a Linux bridge named cni0 and connects each Pod’s veth pair to it. After the veth pair is set up, Bridge CNI calls a local IPAM plugin, which stores allocated IPs under /var/lib/cni/networks/<network-name=cni0>/<ip>.

The IPAM plugin returns a payload containing the assigned IP address and related metadata, which the runtime uses to complete Pod network configuration.

Summary

Kube‑controller‑manager assigns a unique podCIDR to each node; the non‑overlapping subnets ensure every Pod gets a distinct IP. Cluster administrators configure kubelet, the container runtime, and the network provider (Flannel) on each node, distribute CNI plugins, and rely on the CRI‑CNI interaction to provision Pod networking.