Prefix Delegation

The simple way to give every pod a routable address is to reserve a block per node. It is also the way to consume an estate's address space four times faster than necessary: a /24 per node reserves 256 addresses for a node whose real density is 30 pods, and the unused 226 are unavailable to anything else.

Prefix delegation inverts the allocation. The host is handed a small prefix - /28 blocks of 16 addresses, in the AWS VPC CNI's implementation - and asks for another when it needs one, so consumption follows density. Per-node waste falls from the difference between the reserved block and real usage to at most a partial prefix.

Why it matters

Address space is a shared, finite estate resource with a long memory. A range handed to a cluster is effectively gone, because reclaiming it means re-provisioning nodes, and a range chosen badly collides with a partner network at the first VPN. Prefix delegation is the difference between a cluster that fits in the plan and one that forces a secondary range, new subnets and a conversation with whoever owns the estate's addressing.

It also changes the failure mode of a scale-out. With per-node blocks, exhaustion is a hard wall at a node count; with delegation, the same space supports several times the nodes and the warning signal - prefixes allocated versus used - is meaningful rather than structural.

Implementation patterns

• Keep a warm prefix per node. A node that must request a prefix before scheduling a pod adds latency to pod start; one spare prefix per node removes that from the common path at the cost of up to 15 idle addresses.
• Measure density before choosing the block size. Delegation's benefit is proportional to the gap between configured maximum and actual pods per node, so measure rather than assume.
• Ensure contiguous free space. Delegated prefixes must be allocated as contiguous blocks, and a long-lived fragmented subnet may not be able to supply them even when its free-address count looks healthy. Fresh subnets for node groups are the simple answer.
• Match the maximum pods per node to the prefix arithmetic, so the kubelet's limit and the addressing cannot disagree.
• Monitor prefixes allocated, prefixes used and addresses used per node, with the alert on the first of these as a share of the subnet.
• Plan the subnet sizes per zone from the node-group maximum, since the allocator cannot borrow space from another zone's subnet.

Industry example

The feature exists because the naive design did not scale. The AWS VPC CNI's documentation presents the arithmetic directly - secondary-address mode binds on addresses per network interface, which caps pods per node by instance type, while prefix mode assigns /28 blocks and raises the ceiling substantially while reducing waste. Flat routable pod networking is popular because it makes security groups, flow logs and direct reachability work the way operators expect, and prefix delegation is what keeps that model viable past a few dozen nodes. The alternative chosen by estates that ran out of space earlier is an overlay, which trades those properties for independence from the estate's addressing.

Failure scenarios

• Fragmentation blocks allocation, so a subnet with thousands of free addresses cannot supply a contiguous /28 and pods stay pending.
• Cold prefix requests on the pod-start path, adding seconds to scheduling during a scale-out when speed matters most.
• Address reuse delay. Addresses from deleted pods are not instantly reusable in some implementations, so a high-churn workload holds more prefixes than its steady-state density suggests.
• Mismatched pod limits, where the kubelet allows more pods than the delegated prefixes can address and the extra pods fail with network errors rather than a clear capacity message.
• Per-zone subnets sized unevenly, so one zone exhausts while another has room and the scheduler cannot use it.

Trade-offs

What is gained is several times the node capacity in the same address space, and allocation that tracks reality. What is paid is a more complex allocator with a new failure mode (fragmentation), some pod-start latency unless a warm prefix is held, and a tighter coupling between instance type, pod limits and subnet design. Against an overlay, the comparison is sharper: delegation keeps direct reachability, native security-group semantics and full-MTU paths, and still consumes estate addresses; an overlay consumes none and gives up all three.

When not to use it

Below roughly 30 nodes none of this is worth configuring - secondary-address mode with default settings is simpler and fits comfortably. It is also the wrong answer when the estate's address pressure is structural rather than marginal: if a merger has produced overlapping ranges, or several business units need space in the same private block, delegation only delays the problem and an overlay or a dedicated range is the real fix. And where pods genuinely do not need to be reachable from the rest of the network, the simplest design is the one that never asks the estate for addresses at all.

Interview question

Q: A cluster in a /16 with a /24 per node is projected to hit address exhaustion at 120 usable nodes against a 400-node roadmap. Prefix delegation is proposed. What do you check before agreeing, and what else would you consider?

What a strong answer covers: measuring real pod density to size the benefit; checking that subnets can supply contiguous prefixes rather than merely free addresses; warm-prefix configuration to keep allocation off the pod-start path; aligning kubelet pod limits with the addressing; per-zone subnet sizing; the monitoring change from addresses used to prefixes allocated; and weighing it against the alternatives - a right-sized per-node prefix (simplest), a secondary CIDR (fast, with the collision caveat), and an overlay (removes the constraint and gives up direct reachability, native security groups and full MTU).

Quick check

Quiz: Why can prefix delegation fail in a subnet with thousands of free addresses? Prefixes must be contiguous blocks, and a fragmented subnet may have no contiguous /28 to delegate.

Flashcard: What does a warm prefix per node buy? It keeps prefix allocation off the pod-start path, trading up to 15 idle addresses per node for scheduling latency during a scale-out.