A platform's cloud subnets are running out of addresses because container workloads consume one IP per pod. What happens as exhaustion approaches, and what are the options?

What happens as exhaustion approaches

Scheduling failures that do not look like network problems. Pods stay pending. The scheduler reports insufficient resources or a failure to allocate a network interface, and the team investigates CPU and memory because that is what "insufficient resources" usually means.

Then, in rough order:

• Autoscaling silently stops working. Capacity is available; addresses are not. The cluster cannot grow during exactly the traffic event that triggered the scale-up.
• Rolling deployments fail. A rolling update needs headroom for new pods before old ones terminate. Near exhaustion, that headroom does not exist, so deployments stall halfway — which is worse than not starting.
• Recovery from node failure fails. Replacement pods cannot be scheduled, so a routine node loss becomes an availability incident.
• Address reuse delays bite. Addresses are held briefly after release; at high churn, effective capacity is lower than the arithmetic suggests, and the shortfall appears intermittently.

The characteristic experience is intermittent, load-correlated failures that look like a scheduler problem.

The options

1. Add secondary address ranges to the existing network. Usually possible without disruption and the first thing to try, provided the enterprise address plan has spare adjacent space — which is precisely why that plan matters.

2. Change the networking model so pods do not consume routable addresses. Overlay networking gives pods addresses from a private range that is not part of the shared address space, removing the constraint entirely. The trade is an encapsulation overhead and reduced visibility: pod addresses are no longer directly reachable or diagnosable from outside the cluster, which complicates some integrations and some security tooling.

3. Increase address density per node. Fewer, larger nodes with more pods each consume fewer node addresses, though pod addresses still dominate. Helps at the margin.

4. Prefix delegation, where a node is allocated a block of addresses rather than individual ones. This substantially increases the effective addresses per node in provider-native networking models and is often the cleanest fix.

5. Segment by cluster. Separate clusters in separate networks, which also improves blast-radius isolation — turning a forced network change into an opportunity to fix a tenancy problem.

The design lesson

Address space is a capacity dimension and must be planned like any other. Teams plan CPU and memory carefully and treat addresses as unlimited, because in a virtual machine world one instance consumed one address and the numbers were comfortable. Container density changed the arithmetic by an order of magnitude, and many address plans were written before that.

The practical control is to monitor address utilisation per subnet as a first-class metric with an alert well before exhaustion, because the remedies all take time — and the moment you discover the problem is usually the moment you most need to scale.