Kubernetes Pod & Service CIDR Calculator
Size your pod and service CIDRs before cluster creation and check them against your existing networks — both are effectively immutable once the cluster exists.
Kubernetes Pod & Service CIDR Calculator
Capacity Summary
Note: recommendations deliberately avoid 192.168.0.0/16 — it's the default range on most home routers and consumer VPN clients, which routinely causes silent conflicts when engineers connect from home.
Copy-paste config
kubeadm init --pod-network-cidr=10.0.0.0/17 --service-cidr=10.255.0.0/20
Managing CIDRs across multiple clusters and sites?
💾 Join the SubnetVault waitlistAlso see: general subnet calculator · CIDR to IP range · EKS max pods per node calculator
Why pod and service CIDR sizing matters up front
Kubernetes hands out IP addresses to pods in fixed-size blocks per node — the node-cidr-mask-size, /24 by default, which gives each node 256 addresses regardless of how many pods it actually runs. That means the cluster-wide pod CIDR has to be large enough to hand out one of those blocks to every node you'll ever run, not just the nodes you have today. Run out, and there's no clean way to extend it: the pod CIDR is set at cluster creation and changing it means reconfiguring the CNI across every node, which in practice usually means rebuilding the cluster.
This calculator applies a growth factor (2x by default) on top of your expected node count before picking a block size, so a cluster that starts at 20 nodes and grows to 35 doesn't hit a wall. It also recommends a separate, non-overlapping service CIDR — /20 for smaller clusters and /16 for larger ones — sized for ClusterIP allocations rather than pod IPs, which follow a completely different consumption pattern.
The overlap check
A pod or service CIDR that overlaps your VPC, VNet, or on-prem ranges causes routing that's technically valid but practically broken — traffic destined for a pod IP can get silently routed somewhere else entirely, and the failure mode is usually intermittent and hard to reproduce. Paste your existing ranges into the calculator and it checks every pair — pod CIDR, service CIDR, and each range you supply — using the same overlap-detection logic as the site's subnet overlap checker.
One specific trap worth calling out: 192.168.0.0/16 is the default range on most home routers and consumer VPN clients. A pod or service CIDR drawn from that space works fine in testing and then breaks the moment someone connects to the cluster's network over a home VPN — this calculator deliberately recommends ranges elsewhere in 10.0.0.0/8 to avoid that entire class of conflict.
Kubernetes CIDR FAQ
Can the pod CIDR be changed after the cluster is created?
No, not without significant disruption. The pod CIDR is baked into the cluster's networking at creation time (kubeadm --pod-network-cidr, EKS VPC CNI configuration, GKE's ip_allocation_policy). Changing it typically means draining every node, reconfiguring the CNI, and often rebuilding the cluster. Sizing it correctly up front — with headroom for growth — avoids that entirely, which is why this calculator recommends a block sized for 2x your expected node count by default.
What's the difference between the pod CIDR and the service CIDR?
The pod CIDR supplies IP addresses to individual pods and is consumed per-node in fixed-size blocks (the node-cidr-mask-size, /24 by default). The service CIDR is a separate, usually much smaller range that only backs virtual ClusterIP addresses for Kubernetes Services — those IPs are handled by kube-proxy/iptables rules and never appear on the wire, so the service range doesn't need to scale with node count the way the pod range does.
Why shouldn't I use 192.168.0.0/16 for pod or service CIDRs?
192.168.0.0/16 is the default range on most home routers and consumer VPN clients. If your pod or service CIDR overlaps it, anyone connecting to the cluster's network from home over a VPN — or running local tooling that also defaults to that range — will see silent, hard-to-diagnose routing conflicts. Picking a range elsewhere in 10.0.0.0/8 avoids that entire class of problem.
How big should the pod CIDR be?
Big enough that (node count) x (growth factor) x (addresses per node block) fits inside it, with room to spare — running out mid-cluster-life means hitting the immutability problem above. This calculator applies a 2x growth factor by default: enough headroom for a typical scale-up without wasting an entire /8 on a five-node cluster.
More Network Tools
Free tools for network engineers — no signup, no rate-limit walls.