Skip to content
OpsAtlas

Planning Kubernetes Node, Pod and Service CIDRs

By OpsAtlas · · 3 min read

Table of contents

Most Kubernetes settings can be changed later. The IP ranges mostly cannot. Pick a pod range that is too small and the cluster stops scheduling at node 65. Pick one that overlaps your office VPN and some requests silently go to the wrong network. Planning the three ranges takes about ten minutes, and it is much easier before the cluster exists.

The three ranges

RangeWho uses itTypical default
Node CIDRnode IPs, from the VPC or LAN subnetyour VPC subnet
Pod CIDRone IP per poddepends on the CNI, e.g. 10.244.0.0/16 (Flannel)
Service CIDRone virtual IP per Service10.96.0.0/12 (kubeadm)

All three must be disjoint from each other and from every network the cluster needs to reach: peered VPCs, on-premises ranges and VPN clients.

Pod CIDRs run out per node, not per cluster

With most overlay CNIs, the pod range is split into one block per node. kube-controller-manager gives each node a /24 by default (--node-cidr-mask-size). That makes the arithmetic simple:

  • A /16 pod range split into /24 blocks gives 256 node slots.
  • Each /24 holds 256 addresses, which comfortably covers the default limit of 110 pods per node.

So a /16 pod range does not mean “65,536 pods”. It means 256 nodes, however few pods each node runs. If you expect more nodes than that, choose a larger range (a /14 gives 1,024 nodes) or a smaller per-node block.

Use the CIDR calculator to check the numbers. Enter the pod range and split it by “hosts per subnet” or into /24s, and the subnet count is your node limit.

When pods use VPC addresses

Some CNIs give pods real addresses from the node’s subnet instead of an overlay. The Amazon VPC CNI on EKS works this way by default, and Azure CNI has similar modes. That removes the overlay, but now the node subnet has to hold every pod.

Take a /24 node subnet on AWS: 256 addresses, minus 5 reserved by AWS, leaves 251. With 30 pods per node, the subnet fills up after about eight nodes, long before you expected it to. Before you pick these subnets:

  • Size node subnets for nodes × max pods per node, not just for nodes.
  • Consider prefix delegation (EKS assigns /28 prefixes to nodes instead of individual IPs), or a secondary CIDR just for pods.
  • Remember that pods keep their addresses during rolling updates, so the peak can be well above the steady state.

The Service CIDR

Service IPs are virtual. Only kube-proxy or the CNI on each node knows about them, so they never appear on the wire outside the cluster. They still must not overlap with anything the pods need to reach: a pod that sends a request to 10.96.0.10 hits a Service, even if a real host has that address on your corporate network.

A /16 (65,536 Services) is enough for almost any cluster. Managed services choose a default for you. EKS, for example, uses 10.100.0.0/16 or 172.20.0.0/16 depending on your VPC range. Check which one you got.

Overlaps that catch people out

  • Docker’s default bridge, 172.17.0.0/16. Nodes or CI runners with Docker installed route that range locally. A pod CIDR or VPC inside it breaks traffic from those hosts.
  • Home and office networks. 192.168.0.0/16 is Calico’s default pod range and also the range most home routers use. Engineers on VPN can’t reach pods whose IPs collide with their own LAN.
  • Peered VPCs and other clusters. If clusters might ever be connected through peering, a transit gateway or a service mesh, give every cluster its own pod and service ranges from the start.

A worked plan

One /16 per environment, carved up with room to grow:

10.40.0.0/16        production environment
├─ 10.40.0.0/19     node subnets (3 AZs × /21, one /21 spare)
├─ 10.40.32.0/19    spare
├─ 10.40.64.0/18    spare (second cluster)
└─ 10.40.128.0/17   reserved

100.64.0.0/16       pod CIDR (overlay; 256 nodes at /24 each)
10.96.0.0/16        service CIDR

The pod range here comes from 100.64.0.0/10, the shared address space, which rarely clashes with corporate networks. Some teams use it for exactly this purpose. Check that nothing on your network already uses it.

Use the CIDR calculator to split each block and check usable host counts, including the per-subnet reservations of AWS, Azure and GCP. Export the result as CSV and keep it with your infrastructure code. That gives the next person who adds a cluster a record of which ranges are already taken.

Checklist

  1. List every range the cluster must reach: VPCs, on-prem, VPN pools and other clusters.
  2. Choose node, pod and service ranges outside all of them, and outside 172.17.0.0/16.
  3. Pod CIDR: divide by the per-node block size to get your maximum node count.
  4. VPC-native CNI: size node subnets for nodes × pods.
  5. Write the plan down before you create anything.

Try it yourself

  • CIDR calculator and subnet splitter

    Calculate network, broadcast, host range, netmask and wildcard for any IPv4 CIDR, then split it into subnets by prefix, count or host size.

    Network