How Kubernetes Assigns IPs to Pods: Flannel, CNI, and CRI Explained

Kubernetes requires each Pod to have a unique IP address for communication. This article explains how Pods obtain IPs, focusing on the interaction of network components such as CNI plugins, the CRI, and the kube‑controller‑manager, using Flannel as the network provider and containerd as the container runtime.

Container Network Basics

On a single host, containers communicate via a Linux Bridge and veth pairs: one end of the veth resides in the container’s network namespace, the other connects to the host’s bridge, which also holds an IP address acting as a gateway for Pod traffic.

Across multiple hosts, Flannel uses VXLAN packet encapsulation over UDP to route traffic between Pods on different nodes.

CRI and CNI Overview

The Container Runtime Interface (CRI) allows kubelet to use different container runtimes. CNI (Container Network Interface) provides a plugin framework for configuring Pod networks. Both are invoked during Pod creation.

Node IPAM Controller

When the nodeipam controller is enabled via the --controllers flag, the kube‑controller‑manager assigns each node a dedicated subnet (podCIDR) from the cluster CIDR, ensuring unique Pod IPs. Nodes receive their podCIDR on first registration; changes require node re‑registration.

Flannel Configuration

Flannel’s daemon (flanneld) creates a VXLAN device on each node, retrieves network metadata from the API server, and generates CNI configuration files (e.g., /etc/cni/net.d/10-flannel.conflist). It assigns routes so Pods can reach each other by IP.

Interaction Between Components

When a Pod is scheduled, kubelet calls the container runtime (containerd) via the CRI plugin, which then invokes the appropriate CNI plugin (Flannel). Flannel may call the Bridge CNI plugin, which creates a Linux bridge (cni0) and veth pairs, and finally the host‑local IPAM plugin supplies IP addresses, storing allocation data under /var/lib/cni/networks/<network-name=cni0>/<ip>.

Summary

The kube‑controller‑manager allocates non‑overlapping podCIDRs to nodes, enabling unique IP assignment for every Pod. Administrators configure kubelet, container runtime, and network provider, distribute CNI plugins to nodes, and rely on the CRI‑CNI interaction to provision Pod networking.