## TL;DR
Each node gets a fixed pod CIDR block (commonly 110 IPs by default); when it is full, new pods cannot get IPs and stay Pending. The immediate relief is clearing the backlog (deleted pods holding IPs, leaked allocations), and the durable fix is a larger pod CIDR per node or fewer IPs wasted per pod. This is a capacity problem wearing an error message.

## The query
```text
Kubernetes "failed to allocate IP for range": pod CIDR exhaustion fix
```

## Use this when
- Pods stay Pending with IP allocation errors
- A node cannot place any more pods despite free CPU/memory
- Planning CIDR sizes for new clusters
- After increasing pod density per node

## Not for when
- Service ClusterIP range exhaustion (different range)
- CNI misconfiguration (pods never got IPs at all)
- IP conflicts (duplicate assignment, different error)

## Steps

### Step 1: Confirm the node's CIDR is actually full
Check the node's podCIDR and count assigned IPs vs the range size. Confirm that the Pending pods target this node and that IP exhaustion (not another scheduler reason) blocks them.
Expected output: the CIDR usage quantified: X of Y IPs allocated.

### Step 2: Clear leaked and stale allocations
Look for IPs held by deleted pods, terminated containers not yet garbage collected, or CNI state out of sync with reality. Node reboots and CNI restarts can leak allocations; cleaning them frees real IPs.
Expected output: leaked IPs reclaimed, possibly enough to relieve the immediate pressure.

### Step 3: Reduce IP waste per pod
Check for pods requesting more IPs than they use (some CNIs allocate per-container or reserve blocks). Init containers and sidecars that exited still hold the pod IP; that is normal, but account for it in capacity math.
Expected output: the true IPs-per-pod cost understood.

### Step 4: Expand the pod CIDR for the long term
For a durable fix, provision nodes with larger pod CIDRs or add new node pools with bigger ranges. This usually means new nodes; existing node CIDRs cannot be resized in place on most setups.
Expected output: new nodes with CIDR capacity matching the pod density target.

### Step 5: Alert on CIDR usage before it blocks
Monitor IP allocation per node and alert at 80 percent. CIDR exhaustion is entirely predictable; there is no reason for the first symptom to be Pending pods.
Expected output: advance warning with time to add capacity.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G3diOsbRZS07cvhz5Hlcbw