Allocation & IPAM

Address allocation is split between the controller and the node plugin, coordinated through the per-node Allocation resource. How the split works depends on the network type.

L3 networks

Allocation is host-local — see Networks:

• The controller cuts the subnet into node-sized blocks (by the network’s host-local prefix length), reserves one block per node, and records it in that node’s Allocation.
• The node plugin allocates pod addresses from its own block.

L2 networks

Allocation is global, with no per-node blocks:

• The controller allocates each pod address directly from the subnet.
• The Allocation carries no prefixes; it exists only as a marker that the node participates in the network.

Releasing networks and allocations

Teardown is ordered from the bottom up and held by finalizers, so allocated state is never orphaned:

• An Allocation is not removed while the node still holds pod addresses from it. The node releases the Allocation only once its last address for that network is freed.
• A Network is not removed while any of its Allocations remain. Deleting a Network tears its Allocations down first.

A Network with live pods, or an Allocation with live addresses, therefore stays in terminating state until those addresses drain.

LoadBalancer pools

VIP allocation for type: LoadBalancer Services is central: the controller manages the VIPs drawn from a LoadBalancerClass’s per-family pools, while nodes own only the advertisements.

• Removing a pool or deleting a class stops new allocation from it but does not reclaim VIPs already allocated — existing advertisements keep their VIP and continue to be advertised.
• Adding a class or pool rebuilds the allocator from the existing advertisements first, so any in-use VIP that falls within the new pool is reserved and never handed to another Service.