Learn Cilium - IPAM (IP Address Management)

#Introduction

Every pod that is born needs an IP address, and who allocates it and from which pool is the domain of IPAM (IP Address Management). In episode 4 we mentioned IPAM briefly; episode 9 covers it fully because IPAM decisions affect pod capacity per node and how traffic is routed.

Cilium supports several IPAM modes with different levels of complexity: cluster-pool for simplicity, Multi-Pool for granular control, and cloud-native modes such as ENI and Azure for deep cloud provider integration. We will discuss them one by one along with their use cases.

Throughout this episode, pay attention to one important dimension: IPAM determines the capacity limits of your cluster. How many pods per node? How many pools are available? The answers to these questions live in the IPAM configuration, and planning mistakes here are usually only felt once the cluster starts getting dense.

#The cluster-pool Mode

The most common mode and recommended for most clusters: cluster-pool. Cilium takes one large block from the address space (usually from the cluster's pod CIDR), divides it into per-node pools, and each node allocates IPs for local pods from its own pool. There is no DHCP server or cloud integration — everything runs inside the cluster.

The default configuration can be seen and changed via Helm:

helm get values cilium -n kube-system | grep -A5 ipam

helm get values cilium -n kube-system shows the currently active values. The default cluster-pool uses an IPv4 /24 mask per node, meaning roughly 250 pods per node. This size can be adjusted with ipv4.nativeRoutingCIDR and ipam.maskSize.

The main advantage of cluster-pool is that there is no external point of failure: all allocation runs inside the cluster handled by the Cilium Operator. There is no need to depend on a DHCP server or a cloud API to allocate pod IPs. This lets the cluster keep providing pod IPs even when there is a disruption in the cloud provider's services.

#Multi-Pool IPAM

Multi-Pool IPAM, stable since Cilium 1.19, allows allocation from several different pools simultaneously. This is useful when some workloads need a special IP range, for example for compliance, or when several namespaces must be separated by address. Multi-Pool works through a CRD named CiliumPodIPPool:

apiVersion: cilium.io/v2alpha1
kind: CiliumPodIPPool
metadata:
  name: pool-akunting
spec:
  ipv4:
    cidrs:
      - "10.100.0.0/24"

apiVersion: cilium.io/v2alpha1 marks this resource as an IP pool. The pool-akunting pool provides the 10.100.0.0/24 range which is only used by namespaces or nodes directed to this pool. With Multi-Pool, you do not need to guess all workloads' needs from the start — just add a new pool when the need arises.

Another real scenario well suited for Multi-Pool: integrating pods with external network security. Some firewalls or security groups need to allow specific IP ranges for pods. With Multi-Pool, you can isolate pods that need special access into one pool, then allowlist that pool — without opening access for the entire cluster pod range.

#Cloud-Native IPAM (ENI, Azure)

For clusters on public clouds, Cilium can integrate directly with the cloud provider's IP services:

• AWS ENI: every pod gets an IP from the Elastic Network Interface attached to the node. Pod traffic flows through the ENI so it can leverage AWS security groups and does not need an overlay.
• Azure IPAM: IP allocation from the Azure VNet with integration into Azure networking.

These modes are enabled at install time by pointing to the provider:

cilium install --set ipam.mode=eni

cilium install --set ipam.mode=eni tells Cilium to use AWS ENI IPAM. The advantage: pods have IPs routable inside the VPC and are subject to security groups. However, the pod capacity per node is limited by the number of ENIs per instance — a trade-off that must be carefully calculated.

It is important to note that the ENI and Azure modes do not use an overlay. Pods have addresses routable directly in the VPC, so cross-node pod-to-pod communication does not require encapsulation. This reduces per-packet overhead, but demands more careful capacity planning because the number of IPs is limited by the cloud resources per node.

#Dual-Stack IPv4 and IPv6

IPv6 support in Cilium is developing rapidly. Cilium supports dual-stack: pods get both IPv4 and IPv6 addresses, and Services can be exposed on both stacks. Enable it by providing CIDRs for both:

cilium install --set ipv4.enabled=true --set ipv6.enabled=true

cilium install --set ipv4.enabled=true --set ipv6.enabled=true makes the cluster run dual-stack. Every pod receives addresses from both families, allowing a gradual transition toward IPv6-only without stopping existing IPv4 services.

Enabling dual-stack from the start is cheaper than adding it later. Migrating from IPv4-only to dual-stack requires configuration changes and a Cilium restart, which means planned downtime. Conversely, using dual-stack from installation leaves you free to experiment with IPv6 at any time.

To verify the IP allocation on a node:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg ipam list

cilium-dbg ipam list shows the pools available on the node and the allocated addresses. If capacity is exhausted, you will see errors here — one of the common problems we will discuss during troubleshooting in episode 19.

#Measuring Capacity and Choosing a Mask

Before the cluster gets crowded, do a simple capacity calculation so you are not surprised later. For cluster-pool, the pod capacity per node is determined by the IPAM mask:

helm get values cilium -n kube-system | grep -E "maskSize|ipam" 
kubectl get ciliumnode -o wide

helm get values cilium -n kube-system shows the active values; note ipam.maskSize. kubectl get ciliumnode -o wide shows every node along with its allocated IPv4 pool — this column shows how many addresses are available for pods on that node.

The simple formula: a /24 mask gives about 250 usable addresses per node, /26 gives about 62, and /28 only about 14. Choosing too large a mask wastes addresses, too small makes nodes run out quickly. Estimate the maximum pods per node from the planned workloads, then add room for spikes.

cilium install --set ipam.mode=cluster-pool --set ipam.maskSize=25

cilium install --set ipam.maskSize=25 changes the per-node pool size. Remember that changing the mask only affects new allocations; already-running pods are not automatically moved. This change is best done before large workloads arrive — we discuss the consequences deeper in episode 21 when planning the production architecture.

#Closing

Key takeaways:

• cluster-pool divides one IP block into per-node pools for simple allocation.
• Multi-Pool IPAM, stable in 1.19, uses CiliumPodIPPool for special pools.
• The ENI and Azure modes integrate pod IPs directly into the cloud VPC.
• Dual-stack gives pods both IPv4 and IPv6 addresses.
• cilium-dbg ipam list is the door to reading allocation status.
• Pod capacity per node is determined by the IPAM mode and pool configuration.

In the next episode 10, we will discuss DNS-based policy (FQDN) — how the DNS proxy works, egress rules based on domains with toFQDNs, TTL and cache management, and the practice of allowing outbound access only to specific domains such as api.external.com. This completes our egress policy which so far has still been IP-based.