Skip to main content
Hello and welcome — this lesson explains IP address management (IPAM) for Kubernetes networking. This article focuses on how Pod IPs and node-level bridge networks are assigned and tracked by CNI plugins. It does not cover the IP addresses assigned to Kubernetes nodes by your cloud provider or on-prem network — those are managed externally. Instead, we’ll cover:
  • How each node’s virtual bridge gets a subnet
  • How Pods receive IP addresses
  • Where allocation state is stored
  • Who ensures IP uniqueness across allocations
Who is responsible? The CNI (Container Network Interface) specification delegates IP allocation to the CNI plugin. The plugin must ensure Pods receive unique IPs and maintain allocation state (locally or via an external allocator).
A technical diagram of the Container Network Interface (CNI), showing CNI plugin responsibilities on the left and three nodes on the right with bridge networks (v-net-0), pod IPs in the 10.244.x.x ranges, and node IPs connecting to a LAN (192.168.1.0).

How IP allocation is typically implemented

A minimal CNI-style network script can both create the veth pair and configure the Pod-side IP. A simplified implementation might follow these steps:
Kubernetes itself does not prescribe how a plugin must choose IPs — it only requires no duplicate assignments. Simple plugins can store allocations in a local file (and update it atomically). However, the CNI ecosystem provides reusable IPAM plugins that handle allocation details for you.

Common IPAM approaches

How a plugin invokes IPAM

Instead of hard-coding an allocator, a network plugin reads the ipam block in the CNI configuration and invokes the indicated IPAM implementation. Conceptually:
A good plugin parses the ipam block, calls the configured IPAM plugin binary, reads the JSON response (which contains the allocated IP and any routes), and then applies the IP and routes inside the Pod network namespace.

Example CNI configuration (with IPAM block)

Place CNI configs in /etc/cni/net.d/. The ipam section tells the network plugin which IPAM implementation to invoke and any subnet or routes to use:
When "type": "host-local" is configured, the host-local IPAM plugin will allocate an IP and return JSON like:
Your network plugin then configures the interface and routes inside the Pod namespace based on that output.
The CNI spec expects the network plugin to invoke the configured IPAM plugin. Using host-local stores allocations on the node (under /var/lib/cni/networks/<network-name>), while other IPAM plugins can provide cluster-wide coordination if you need globally unique addresses.

Host-local storage location

The host-local IPAM plugin persists allocation state on the node under:
  • /var/lib/cni/networks/<network-name>
Each file records which IPs are allocated for that network on that host. This local persistence makes host-local straightforward to inspect and debug.

Best practices

  • Prefer a maintained IPAM plugin (like host-local) instead of rolling custom file allocators.
  • Use external IPAM controllers if you need cluster-wide IP coordination or integration with enterprise IPAM systems.
  • Always parse and respect the ipam block in the CNI config so your plugin can support different IPAM implementations.
  • Inspect /var/lib/cni/networks/ and the CNI config files in /etc/cni/net.d/ when troubleshooting Pod IP allocation issues.
That concludes this lesson. Try experimenting with different ipam types and observe where allocations are stored on each node using a hands-on lab or a practice cluster.

Watch Video

Practice Lab