The number one operational mistake in production Kubernetes is undersizing the pod CIDR. Unlike VPC sizes (which most clouds let you expand), the pod CIDR is fixed at cluster creation and cannot be changed. Get it wrong, and the only fix is to build a new cluster and migrate workloads — typically a multi-week project.
This article walks through the three CIDRs every Kubernetes cluster needs, how to size each one, and the cloud-specific patterns that prevent VPC address exhaustion under load.
The three CIDRs every cluster needs
A Kubernetes cluster requires three independent IP address ranges:
| CIDR | What it covers | Resizable later? |
|---|---|---|
| Node CIDR | IPs for the underlying VMs (EC2 instances, etc.) | Yes, via VPC expansion |
| Pod CIDR | IPs for every pod in the cluster | NO — fixed at creation |
| Service CIDR | Virtual IPs for Services (ClusterIP) | NO — fixed at creation |
The node CIDR is just your VPC subnet space, which you can extend by adding more subnets or growing the VPC. The pod and service CIDRs, however, are baked into the cluster's API server and kubelet config — changing them requires building a new cluster.
Sizing the pod CIDR (the hard one)
The pod CIDR is the largest of the three because every pod gets at least one IP. The rule of thumb:
Pod CIDR ≥ 4× expected peak pod count.
The 4× multiplier accounts for in-flight pod restarts, IPAM padding (most CNIs hold spare IPs per node), DaemonSets, and growth headroom. A cluster that runs 5,000 pods at peak needs roughly 20,000 pod IPs — at minimum a /17, more comfortably a /16.
| Target peak pods | Min pod CIDR | Recommended | Recommended addresses |
|---|---|---|---|
| 500 | /22 (1,024) | /20 (4,096) | 4,096 |
| 2,000 | /20 (4,096) | /19 (8,192) | 8,192 |
| 5,000 | /18 (16,384) | /16 (65,536) | 65,536 |
| 20,000 | /16 (65,536) | /15 (131,072) | 131,072 |
| 50,000 | /15 (131,072) | /14 (262,144) | 262,144 |
Always round up to the next power of 2. The cost of over-provisioning is zero in terms of money — you are not paying per pod IP. The cost of under-provisioning is a cluster rebuild.
Sizing the service CIDR
The service CIDR is much smaller because services are sparse compared to pods. Each Service gets one ClusterIP — a virtual address that kube-proxy or eBPF translates to actual pod IPs.
A /16 service CIDR (65,536 IPs) is plenty for almost any cluster. Even a 100,000-pod cluster rarely has more than a few thousand Services. The kubeadm default of 10.96.0.0/12 (1M addresses) is wildly overprovisioned; that is fine because the service CIDR is virtual and does not consume any real network space.
Critical constraint: the service CIDR must not overlap with the pod CIDR or the node CIDR. If they overlap, traffic to a service can be misrouted to a pod or a node and silently fail.
Sizing the node CIDR
Node CIDR sizing depends on:
- Maximum simultaneous nodes you expect (be generous — autoscaling spikes can double node count for hours).
- Whether you use VPC-native CNI (AWS VPC CNI, Azure CNI) — if so, the node CIDR also has to hold pod IPs in some configurations.
- Cloud reserved IPs per subnet (5 for AWS, 5 for Azure, 4 for GCP).
A standard production EKS cluster with VPC CNI prefix delegation, expecting 50-200 nodes, fits in a single /22 subnet (1,024 IPs) per AZ comfortably. Without prefix delegation, you need to oversize substantially.
The VPC CNI vs overlay decision
Two fundamentally different approaches to pod networking:
| Model | Examples | Pod IPs come from | Address efficiency |
|---|---|---|---|
| VPC-native | AWS VPC CNI, Azure CNI | Your VPC subnets directly | Low (each pod = 1 VPC IP) |
| Overlay | Calico, Flannel, Cilium | Separate virtual range | High (overlay independent of VPC) |
VPC-native gives pods real, routable cloud IPs. Direct connectivity to other VPC resources, no overlay overhead. The downside is that pods burn VPC space fast — a 5,000-pod cluster consumes 5,000+ VPC addresses.
Overlay pods live in a virtual range (often a /16 like 172.20.0.0/16 or 192.168.0.0/16). Encapsulated traffic (VXLAN, IP-in-IP) between nodes. Pods are invisible outside the cluster. Address-efficient but adds packet overhead.
For production EKS, the dominant pattern is VPC CNI with prefix delegation (16x density improvement) and a secondary VPC CIDR in CGNAT space for pod IPs. This combines the connectivity of VPC-native with the address efficiency of overlay. See our deep dive on EKS VPC CNI prefix delegation.
Multi-cluster networking
If you run multiple clusters that need to communicate (active-active, multi-region, edge sites), the pod CIDRs must not overlap across clusters. This is true for:
- Cilium ClusterMesh — direct pod-to-pod via WireGuard or VXLAN
- Istio multi-primary — service mesh handles cross-cluster routing
- Submariner — IPsec tunnels across clusters
- Any VPC-peering-based connectivity — VPC peering rejects overlapping CIDRs as discussed in our multi-cloud CIDR planning article
Plan your cluster allocation chart upfront. A reasonable pattern: each cluster gets a unique /16 from a coordinated /12 pool. 100.64.0.0/16 for cluster A, 100.65.0.0/16 for cluster B, and so on. CGNAT space gives you 64 such /16 cluster allocations.
Pod-per-node density limits
Maximum pods per node depends on:
- Kubernetes default kubelet limit: 110 pods/node. Raising this requires kubelet config changes and cluster-CIDR sizing.
- AWS VPC CNI: limited by ENI capacity per instance type (e.g., m5.large = ~29 pods without prefix delegation, ~110 with).
- GKE: 110 by default, configurable up to 256.
- AKS: 110 with kubenet, 30 with Azure CNI (no prefix delegation).
Calculating total cluster capacity: pods_per_node × nodes = total_pods. For a 5,000-pod cluster at 110 pods per node, you need at least 46 nodes — but practically you want headroom for scheduling, so size for 60+ nodes.
Common sizing mistakes
- Sizing for today's pods, not 3 years out. Multiply your current peak pod count by 4-10x for the pod CIDR.
- Putting pod CIDR in your primary VPC range. Forces pods to share address space with VMs and managed services. Use a secondary CIDR (CGNAT) for pods on AWS.
- Service CIDR overlapping VPC ranges. Silent breakage. Use something distinct like
172.20.0.0/16(the EKS default). - Forgetting Lambda and managed services. A subnet's IPs are not just for pods — Lambda, RDS, ELBs all use the same pool.
Tools for planning
Our CIDR calculator validates pod, service, and node CIDR ranges. The AI assistant has dedicated Kubernetes intent handlers — try "Plan Kubernetes for 5000 pods" for a complete CIDR breakdown.
Key takeaways
- Pod CIDR is fixed at cluster creation. Oversize by 4-10x your peak pod estimate.
- Service CIDR can be small (
/16); pod CIDR is usually/16to/14for production. - None of the three CIDRs may overlap each other or other VPCs you peer with.
- For EKS, use VPC CNI prefix delegation + CGNAT secondary CIDR for the best of both worlds.
- Plan multi-cluster pod CIDRs from a shared allocation chart so future ClusterMesh, Istio, or Submariner deployments do not require re-IPing.