Pod CIDR Planner
Plan Kubernetes Cluster Pod CIDR topologies, calculate max node capacity, subnet slices, and address exhaustion limits — entirely on this device.
Do it offline:$
How to use it
- Enter your top-level Cluster Pod CIDR block (e.g. 10.244.0.0/16 or 10.0.0.0/14).
- Specify the target per-node subnet mask (typically /24 for 256 IPs or /25 for 128 IPs).
- Set your kubelet maxPods constraint (default 110 pods, or up to 250 for custom CNI profiles).
- Review total schedulable worker nodes, IP allocation efficiency, and first node CIDR assignments.
Plan and calculate Kubernetes Pod CIDR network topologies, node subnet allocations, maxPods thresholds, and IP address exhaustion limits across cloud and bare-metal environments.
How it works
In Kubernetes, the Container Network Interface (CNI) allocates a dedicated Pod CIDR subnet to each node joined to the cluster.
A standard /16 network yields 65,536 total addresses. Slicing with a /24 mask per node provides up to 256 worker nodes, with 254 usable pod IP addresses each.
Because Kubernetes schedulers allocate IP addresses rapidly during rolling restarts and deployment scale-outs, maintaining at least a 2x IP buffer relative to maxPods prevents CNI IP exhaustion errors.
Calculations are performed deterministically in your browser, enabling rapid cluster sizing without submitting infrastructure topology data to external servers.
Examples
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Common errors
FAQ
Why does Kubernetes recommend a 2x buffer of IPs relative to maxPods?
When pods are created during rolling updates or autoscaling surges, new pods are spun up and assigned IPs before terminating pods release theirs. A 2x IP buffer ensures smooth rollouts without running out of node subnet addresses.
Can I resize the Pod CIDR on an existing live Kubernetes cluster?
Changing the cluster Pod CIDR on an existing cluster is extremely disruptive and often requires reconfiguring kube-controller-manager, updating CNI daemonsets, and cordoning/draining every node. It is best planned accurately prior to cluster creation.
How does AWS VPC CNI differ from Calico or Flannel CIDR allocations?
AWS VPC CNI assigns secondary private IP addresses directly from your VPC subnet to EC2 elastic network interfaces (ENIs), rather than carving out an overlay Pod CIDR. In that model, VPC subnet sizing and EC2 instance ENI limits dictate pod density.