Kubernetes Pod & Node CIDR-Planer - EKS, AKS, GKE Subnetz-Rechner
← Back to Main Calculator

Kubernetes Pod & Node CIDR Planner

Size, plan, and validate Pod, Node, and Service CIDR blocks for EKS, AKS, GKE, and self-managed Kubernetes clusters with real-time overlap detection.

Cluster Configuration

CIDR Block Configuration

Total Usable Pod IPs
65,536
From 10.244.0.0/16
Max Supported Nodes
256
With /24 per node
Pod CIDR per Node
/24
256 IPs (110 usable)
IP Utilization Efficiency
43%
1,650 of 65,536 IPs needed

CIDR Allocation Map

Kubernetes Configuration Manifest

Kubernetes CIDR Planning Guide
How to Size Pod CIDRs in Kubernetes to Avoid IP Exhaustion
IP exhaustion is one of the most common and painful problems in production Kubernetes clusters. The root cause is almost always under-provisioning the Pod CIDR block at cluster creation time. Unlike compute or memory, you cannot easily expand a CIDR block after a cluster is deployed — it requires migrating to a new cluster.
Use this formula to calculate your minimum Pod CIDR size: Required Pod IPs = Target Nodes × Max Pods per Node × (1 + Growth Buffer). Always round up to the next power of 2. For production clusters, a /14 (262,144 IPs) or larger is recommended to accommodate future growth, node pool expansions, and cluster autoscaler headroom.
Overlay vs. Non-Overlay Networking (AWS VPC CNI vs. Calico/Cilium)
Overlay networking (Calico VXLAN, Cilium Geneve, Flannel) creates a virtual Layer 2 or Layer 3 network on top of your existing infrastructure. Pod IPs come from a separate CIDR range that is independent of the node network. This gives you maximum flexibility in IP planning — your Pod CIDR can use any RFC 1918 range regardless of your VPC. The tradeoff is encapsulation overhead (~50 bytes for VXLAN, ~30 bytes for Geneve) which slightly reduces maximum throughput on high-bandwidth links.
Non-overlay networking (AWS VPC CNI, Azure CNI) assigns pod IPs directly from the VPC or VNet subnet. This eliminates encapsulation overhead and provides native VPC routing, security group integration, and flow logs visibility. However, it requires careful IP planning because pods and nodes compete for the same address space. Each node consumes MaxPods + 1 IPs from the VPC subnet. AWS VPC CNI also has per-instance ENI limits that constrain max pods per node.
Use this K8s CIDR planner to visualize exactly how many IPs each approach requires and whether your planned CIDR blocks overlap.
Why Service CIDR and Pod CIDR Must Never Overlap with Node VPCs
Kubernetes relies on IP routing tables and iptables rules to direct traffic between pods, services, and external endpoints. If the Pod CIDR or Service CIDR overlaps with the VPC/Node CIDR, the kernel routing tables become ambiguous — traffic intended for a VPC resource (e.g., an RDS database at 10.0.1.50) may be intercepted by a pod or service, or vice versa. This causes silent connectivity failures that are extremely difficult to debug because packets are delivered to the wrong destination without any error signal.
The golden rule: Pod CIDR, Service CIDR, and VPC CIDR must be three mutually exclusive address ranges. A common and safe convention is VPC = 10.0.0.0/16, Pods = 10.244.0.0/16, Services = 10.96.0.0/12. This planner's overlap detection matrix will immediately flag any collisions before you deploy your cluster.
Verwandte Tools
CIDR CalculatorSubnet CalculatorVLSM CalculatorAWS Subnet CalculatorAzure Subnet CalculatorGCP Subnet CalculatorTerraform GeneratorMTU & MSS Calculator
Frequently Asked Questions
What Pod CIDR size should I use for my Kubernetes cluster?
For clusters under 50 nodes: /16 (65,536 IPs) is sufficient. For 50-200 nodes: use /15 (131,072 IPs) or /14 (262,144 IPs). For enterprise clusters over 200 nodes or with aggressive autoscaling: use /14 or larger. Always factor in a 50-100% growth buffer. If using AWS VPC CNI or Azure CNI (non-overlay), the Pod CIDR is your VPC subnet, so ensure the entire VPC is sized appropriately with at least /16. For overlay CNIs like Calico and Cilium, the Pod CIDR is independent and can be changed more easily, but it is still painful to expand — size it generously from the start.
Can I change the Pod CIDR after cluster creation?
Changing the Pod CIDR after cluster creation is extremely difficult and not officially supported by most Kubernetes distributions. In practice, it requires redeploying the cluster or migrating workloads to a new cluster with the desired CIDR. For EKS, the Pod CIDR (VPC CIDR) is fixed at VPC creation time. For AKS, the service CIDR and Pod CIDR are set at cluster creation and cannot be changed. For self-managed clusters using Calico or Cilium, you can theoretically change the IP pool, but all existing pods must be recreated. This is why proper CIDR planning before deployment is critical — use this planner to get it right the first time.
How does AWS VPC CNI prefix delegation affect pod density?
AWS VPC CNI Prefix Delegation mode assigns /28 subnets (16 IPs) to each ENI instead of individual /32 IPs. This dramatically increases pod density per node because each ENI can hold up to 16 IPs per prefix, and each node can have multiple ENIs. For example, an m5.large with 3 ENIs can support 3 × 16 = 48 pods with prefix delegation, compared to 3 × (10 - 1) + 2 = 29 pods without. For m5.4xlarge with 8 ENIs: 8 × 16 = 128 pods vs 8 × (30 - 1) + 2 = 234 pods without (in this case prefix delegation actually reduces max pods). Always check both modes against your instance type to choose the optimal configuration.
What are the default Pod and Service CIDRs for EKS, AKS, and GKE?
AWS EKS: There is no default Pod CIDR — pods use the VPC CIDR directly via the VPC CNI. The VPC CIDR is determined by your VPC configuration (typical default is 10.0.0.0/16). The Service CIDR is configured at cluster creation, commonly 10.100.0.0/16 or 10.96.0.0/12. Azure AKS: Default Pod CIDR is 10.244.0.0/16 (using Calico overlay) or 10.224.0.0/12 (Azure CNI); default Service CIDR is 10.0.0.0/16. GCP GKE: Default Pod CIDR depends on the cluster type — VPC-native clusters use a secondary IP range (/14 default for pods), and the Service CIDR defaults to 10.96.0.0/12. Always verify and explicitly configure these values rather than relying on defaults.