Kubernetes Pod and Node Subnet Planning

Kubernetes Pod and Node Subnet Planning

Kubernetes assigns three CIDR ranges: one for nodes, one for pods, one for Services. Overlapping any two causes cluster failure.¹

The pod CIDR (clusterCIDR) is divided among nodes by the controller manager; each node receives a /24 block from which the CNI plugin assigns pod IPs. The service CIDR (serviceClusterIPRange) is purely virtual, meaning no packets leave the node using these addresses. Node IPs come from the VPC or on-premises subnet. All three ranges must be non-overlapping, and none should conflict with external networks the cluster must reach, including cloud metadata endpoints and corporate subnets.

Kubernetes CIDR allocation architecture

Inside a Kubernetes cluster, three independent CIDR ranges operate simultaneously. The node CIDR is a real network range: node IPs come from a VPC subnet or on-premises VLAN and appear in routing tables. The pod CIDR is a virtual overlay range; the controller manager slices it into per-node blocks and the CNI plugin assigns individual pod IPs from each node's block. The service CIDR is purely virtual, as Service IPs exist only as iptables or eBPF rules on each node and never appear on the wire. Consequently, the service CIDR only needs to avoid conflicts with real destinations reachable from the cluster, not with subnets behind a VPN or in a corporate network.

Node CIDR vs. pod CIDR vs. service CIDR

The node CIDR is the only one that must align with your VPC or on-premises routing. Pod and service CIDRs are local to the cluster; they never appear in external routing tables. This means you can safely use 10.96.0.0/12 for pods even if your corporate network uses 10.0.0.0/8, because no pod traffic leaves the cluster without NAT or egress gateway translation. Node IPs appear in VPC route tables and must not overlap with any peered VPC or on-premises CIDR. Pod IPs are assigned from the per-node block and only need to be unique within the cluster. Service IPs are purely virtual and only need to avoid overlapping with real destinations the cluster must reach through a VPN or peering connection.

Sizing pod CIDRs for density

Kubernetes assigns one /24 block per node from the cluster pod CIDR by default.² A 100-node cluster consumes 100 /24 blocks from the pod CIDR. A /16 pod CIDR provides 256 /24 blocks, comfortably covering a 100-node cluster with room for 156 additional nodes.³ Building on this, the per-node pod limit defaults to 110 pods per node, so each /24 (256 addresses) has enough capacity for the maximum density plus gateway addresses. For clusters larger than 256 nodes, a /15 or /14 pod CIDR is necessary. Furthermore, the pod CIDR must not overlap with the service CIDR or with any external network; RFC 1918 ranges used in the corporate network make 10.96.0.0/12 a common choice for the pod CIDR when corporate infrastructure uses 10.0.0.0/8.

Calculating node count from pod CIDR size

To determine how many nodes your pod CIDR can support, divide the total addresses by 256 (one /24 per node). A /16 supports 256 nodes, a /15 supports 512, and a /14 supports 1,024. CapyToolkit shows the total address count for any prefix, so you can verify your pod CIDR supports your planned node count before provisioning. This calculation gives you a hard upper bound based on the per-node /24 block size, independent of how many pods each node actually runs.

Leave headroom for cluster growth when you pick the pod CIDR. A team expecting 150 nodes today fits in a /16, but a future expansion to 300 nodes forces a wider prefix that cannot be changed after the cluster is created. CapyToolkit displays the node ceiling for each prefix, so choosing a /15 now costs nothing extra and avoids a painful cluster rebuild later.

Avoiding CIDR conflicts

The most dangerous Kubernetes CIDR conflict is between the pod CIDR and a reachable external network. If pods are assigned IPs from 192.168.0.0/16 and the cluster must reach corporate services at 192.168.10.0/24, pod traffic destined for those services routes locally instead of through the corporate VPN, silently dropping external connectivity. Consequently, always check all corporate and VPN-connected ranges before choosing pod and service CIDRs. Building on this, cloud metadata services at 169.254.169.254 must remain reachable from every node; the pod CIDR must not contain this address, and service CIDRs must not overlap with 169.254.x.x. The standard approach is to use 10.96.0.0/12 for pods and 10.112.0.0/12 for services in environments where corporate infrastructure lives in different 10.x.x.x ranges.

Choosing between 10.96.0.0/12 and 172.16.0.0/12 for pods

Both ranges work well for pod CIDRs because they sit inside the RFC 1918 10.0.0.0/8 or 172.16.0.0/12 blocks but are large enough for most clusters. The 10.96.0.0/12 is the kubeadm default and provides about 4 million addresses. Use 172.16.0.0/12 when your corporate network already occupies the 10.0.0.0/8 space and you need a pod CIDR that will not conflict. The key constraint is that the pod CIDR must not overlap with any network the cluster needs to reach through a VPN or peering connection.

EKS IP address management with VPC CNI prefix delegation

AWS VPC CNI prefix delegation assigns a /28 prefix (16 IPs) to each node ENI instead of individual IPs, dramatically increasing pod density per node.⁴ Without prefix delegation, a c5.large node (3 ENIs, 10 secondary IPs per ENI) supports 30 pods maximum. With prefix delegation, each ENI gets 8 /28 prefixes, giving 128 pod IPs per ENI and 384 pods per node. The tradeoff: each /28 prefix is reserved for one node even if only 2 pods are running, which consumes VPC address space faster.

Building on this, plan your node subnet CIDRs to accommodate the prefix-delegated capacity. A /22 node subnet (1,019 usable after AWS reservations) supports 254 /28 prefixes, enough for 254 nodes at maximum prefix allocation. If your cluster has 50 nodes, a /22 is generous; if it has 200 nodes, you need at least a /21. The subnet calculator shows the exact usable count for any prefix, which you divide by 16 (addresses per /28) to get the prefix count, then compare against your node count. Consequently, prefix delegation changes the subnet sizing formula from "pods per node" to "nodes per subnet," which is a simpler and more predictable planning model.

Calico and Cilium overlay modes: reducing subnet dependency

Calico and Cilium both offer overlay (tunnel) modes that decouple pod IPs from the underlying VPC subnet. In overlay mode, pods receive IPs from a private range (Calico defaults to 192.168.0.0/16; Cilium uses 10.0.0.0/8 by default) that is encapsulated in VXLAN or Geneve tunnels between nodes.⁵⁶ The VPC subnet only needs to accommodate node IPs, not pod IPs, which means a /24 node subnet supports any number of nodes up to 251 regardless of pod count.

Building on this, overlay mode trades some performance (encapsulation overhead of 50 to 100 bytes per packet and additional CPU for tunnel processing) for dramatically simpler IP planning. For clusters where pod-to-pod latency is not critical (batch processing, internal tools), overlay mode eliminates the need for large pod CIDRs entirely. The subnet calculator still applies: size the node subnet for your node count, and size the overlay pod CIDR for your maximum pod count. The difference is that the overlay pod CIDR does not consume VPC address space, so you can use a generous /16 without impacting your cloud IP budget.

When to use this

Use the subnet calculator to verify pod and service CIDRs don't overlap when provisioning a Kubernetes cluster; conflicts produce routing failures that are difficult to diagnose post-deployment.

Examples