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.

The Allocation resource

• Lifecycle — one per (node, network), created and owned by the controller when it admits a node to a network. A node-held finalizer keeps it from being removed while the node still holds addresses from it, and a Network is not deleted until its Allocations are gone (see Releasing).
• Contents — for an L3 network, the prefix block(s) reserved for the node; for an L2 network, no prefixes — it exists only as a marker that the node participates in the network.
• Use — the node plugin allocates pod addresses from its block (L3 only) and treats the resource’s presence as authorisation to serve the network; it also anchors teardown ordering so allocated state is never orphaned.

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 anything still uses it: the Allocations admitting its nodes, and — on an L2 network, whose Allocations are prefix-less markers that drain at once — the pod addresses the controller handed out from its subnet. Each kind of user holds the Network with a finalizer of its own and drops it once it has nothing left on that network, so the Network is released only when the last one is gone.

Deleting a Network closes it to new work at once: from that point no node is admitted to it and no address is handed out from it, while the nodes and pods already on it are torn down. A request that was already in flight when the deletion landed is either finished and counted as a user of the Network, or refused — it can never be admitted behind a Network that has already been released.

While it waits, the Network stays in terminating state and reports phase Draining. Its network ID stays reserved for the whole wait, so a Network created afterwards can never be given an ID that live pods are still addressed on.

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.