Kubernetes Pod and Service CIDR
Pod and service CIDR sizing, the per-node mask, and the node ceiling that falls out of them. Both ranges are fixed at cluster creation on every managed distribution, so this is the one sizing decision that cannot be revisited.
The kubeadm defaults are 10.244.0.0/16 for pods and 10.96.0.0/12 for services, with a /24 per node. Neither can be changed after the cluster exists.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Calculate. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Sizing the pod CIDR for today's node count
Both CIDRs are fixed at cluster creation on most platforms and cannot be changed without rebuilding. A pod CIDR sized for fifty nodes stops the fifty-first joining.
Instead:Size generously. Private address space costs nothing and the limit is permanent.
Overlapping the pod or service CIDR with the VPC
Routing becomes ambiguous, and peering or a VPN to anything using the same range fails in ways that are hard to diagnose from inside the cluster.
Instead:Keep both ranges outside every network the cluster will ever reach.
Forgetting the node CIDR mask sets pods per node
A /24 per node gives 254 pods, and a /26 gives 62. That mask, not the kubelet's maxPods, is often the real ceiling.
Instead:Compute nodes times pods-per-node against the pod CIDR before choosing the mask.
The per-node mask decides the node ceiling, and it is set once
Each node is carved a fixed slice of the pod CIDR. A /16 pod CIDR with a /24 per node allows 256 nodes and no more, and that arithmetic is fixed at cluster creation on every managed distribution.
A /24 per node gives 254 addresses and kubelet wants 110
kubelet defaults to 110 pods per node. When the per-node CIDR holds fewer addresses than that, the node runs out of pod IPs before it runs out of its pod limit, and new pods fail with a CNI allocation error rather than with anything naming the CIDR. A /25 per node gives 126 addresses, which is above 110 and doubles the node ceiling: that trade is usually the right one.
Overlapping ranges produce the strangest symptoms available
When the pod and service CIDRs overlap, an address can be a pod IP and a ClusterIP at once, and which one wins depends on the order rules were programmed into the dataplane. The result is intermittent connection failures to one service, which is close to undiagnosable from inside the cluster. The conventional pairing keeps them far apart for exactly this reason.
What this cannot see
Your CNI, which may not use the node-CIDR model at all: AWS VPC CNI assigns real VPC addresses and is bounded by the subnet and the instance type instead. Whether the ranges collide with something in your VPC or on-premises network, which is a routing question outside the cluster.