Kubernetes CIDR Planning: A Practical Guide

Kubernetes makes networking look simple from inside a namespace. A Pod gets an IP, a Service gets a stable virtual IP, and a Load Balancer gets an address that users can reach. The planning becomes much harder when you place the cluster beside a VPC, a corporate WAN, a VPN, a second cluster, and the subnets that already support everything else.

The solution is to treat each address family as a separate design decision. Pod addresses serve workload traffic, Service addresses serve virtual endpoints, Node addresses belong to the hosts, and Load Balancer addresses belong to the external exposure path. They interact during routing, but they should not be treated as one large pool.

Start With the Kubernetes Network Model

Kubernetes describes four networking problems: container to container communication inside a Pod, Pod to Pod communication, Pod to Service communication, and external to Service communication. Those paths use different objects and can cross different address domains. The Kubernetes cluster networking documentation describes the required separation between Pod, Service, and Node addresses.

Every Pod receives an address from the Pod network. Every ClusterIP Service receives a virtual address from the Service range. Every Node uses addresses from the infrastructure network that hosts the machine. The network plugin, API server, kubelet, or cloud controller each participate in allocating these addresses, so one CIDR flag does not control the whole cluster.

The first planning rule is simple: do not reuse a range just because one of the networks is virtual. A virtual Service address can still appear in application configuration, DNS responses, logs, firewall rules, and routing decisions. A Pod range can still become visible to a router when the CNI routes it across Nodes. An overlap that looks harmless on paper can become a difficult incident when the destination exists in two places.

Size the Pod Network From Nodes and Workloads

The Pod network must have enough addresses for the Pods that can exist at the same time, not only the Pods running today. Start with the maximum number of Nodes, the maximum Pods per Node, the address block your CNI assigns to each Node, and a growth factor for new pools and temporary scheduling pressure.

Many designs assign a block such as /24 to each Node and allocate those blocks from a larger cluster range such as /16. That is a useful planning pattern, not a Kubernetes requirement. A /24 contains 256 IPv4 addresses before CNI reservations and implementation details. If your Nodes run fewer workloads, a smaller block may be appropriate. If you run dense workloads or need more room for churn, a larger block may be safer.

Use this rough capacity check before you choose the cluster range:

required Pod blocks = maximum Nodes x Pod block per Node
required Pod addresses = maximum Pods per Node x maximum Nodes x headroom

For example, a three zone cluster with 36 Nodes and a /24 block per Node needs 36 /24 blocks immediately. A /16 contains 256 such blocks, leaving room for additional Node pools, rolling upgrades, and future clusters if the surrounding address plan permits it. The usable Pod capacity still depends on the CNI, scheduling limits, host networking, and how many addresses each implementation reserves.

Do not size only for replica counts. DaemonSets place a copy on many Nodes, Jobs can create short lived bursts, and a rolling deployment can temporarily require old and new replicas at the same time. Account for system Pods, failed Pods waiting for cleanup, and the extra capacity needed during a node pool replacement.

Choose a Service CIDR With More Than Today in Mind

The Service CIDR supplies ClusterIP addresses. These are stable virtual addresses that represent Services, not the changing addresses of their backend Pods. The Kubernetes Service documentation explains that ClusterIP is the default Service type and that NodePort and LoadBalancer build on that Service behavior.

Kubernetes does not require every cluster to use 10.96.0.0/12. That range is common in kubeadm based installations, but the correct range is the one that fits your environment and is configured consistently across the control plane. A smaller block such as 10.96.0.0/20 provides 4,094 IPv4 addresses before reserved values, which is plenty for many clusters with a few hundred Services and room for growth.

Count more than application Services. Include DNS, metrics, admission webhooks, operators, system controllers, preview environments, and Services created by platform teams. Headless Services do not consume a ClusterIP, but you should not rely on every future team knowing that distinction when you estimate capacity.

The Service range deserves special care because changing it after cluster creation can be disruptive. Put it in the allocation plan before the first control plane starts. Keep it distinct from Pod ranges, Node subnets, corporate networks, VPN pools, peering networks, and the Service ranges of every cluster that must communicate with it.

Treat Node Addresses as Real Infrastructure

Node addresses are the addresses assigned to the host interfaces. In a cloud they usually come from a subnet in a VPC or virtual network. On premises they may come from a server VLAN, a routed data center subnet, or a dedicated network for the cluster. These are the addresses your switches, routers, firewalls, monitoring systems, and access controls can usually see directly.

Plan Node subnets by location and failure domain. If a cluster spans three availability zones, racks, or sites, reserve a separate subnet for each location when the surrounding network design calls for it. Leave room for autoscaling, replacement Nodes, maintenance capacity, and a second pool with different hardware or workload policies.

Node subnet sizing is often the first place a cluster grows into a physical limit. A cluster can have plenty of Pod addresses and still fail to add Nodes because its VPC subnet has no free infrastructure addresses. Count control plane interfaces, worker interfaces, secondary interfaces, provider reservations, load balancer interfaces, and any other resources sharing the subnet.

The Node range also affects routing. Some CNI designs route Pod CIDRs through the Nodes, while others use encapsulation or provider networking. Document which component advertises or carries the Pod routes, then confirm that firewalls and transit gateways know where those routes terminate. A CIDR plan is incomplete if it lists ranges but not the path that makes them reachable.

Separate Load Balancer Pools From Cluster IPs

A LoadBalancer Service has two relevant addresses. It still has a ClusterIP from the Service CIDR, and it may receive an external address from a cloud provider or a local load balancer implementation. The external address is not automatically part of the Service CIDR.

In a cloud, the provider may allocate a public or private address, attach a managed load balancer, and publish the result in the Service status. In an on premise environment, a team may reserve a private or public pool and advertise addresses through its chosen load balancing and routing design. In either case, record who owns the pool, how addresses are allocated, which VLAN or route carries them, and what happens when a Service is deleted.

NodePort is a different concern. A NodePort exposes a Service on every Node at a port from the configured NodePort range, which defaults to 30000-32767. It does not allocate a new IP range, but it creates a firewall and exposure decision on the Node addresses. If an external load balancer forwards to NodePorts, document the Node subnet, the port range, and the health check path together.

Build an Allocation Plan Before the Cluster

The easiest time to solve an overlap is before the first cluster exists. Create a table with one row per address domain and include the owner, purpose, location, allocation method, route, and expansion boundary. Do not leave the plan as a diagram only. A diagram shows relationships, while an allocation table tells you which block is reserved, available, or already in use.

For a small multi zone cluster, a plan might look like this:

The ranges in this table are examples, not defaults to copy without checking. The important properties are separation, documented ownership, and enough unused space to support the next change. If the cluster may connect to a partner network that already uses 10.244.0.0/16, choose a different Pod range before the conflict becomes a migration project.

Check for Overlap Across Every Network Boundary

Run an overlap review against more than the local VPC or server VLAN. Compare Pod and Service ranges with corporate RFC 1918 space, VPN client pools, site to site tunnel networks, transit gateways, peering connections, container platforms, home lab ranges used by engineers, and the networks used by managed databases or appliances.

Then check the operational paths. Can a worker Node route to every Pod range? Can the chosen ingress or load balancer reach the NodePort or Service endpoint? Can an administrator reach the API server without confusing a ClusterIP for a real host? Does the firewall allow the required Pod, Service, Node, and health check traffic? Are return routes symmetrical across zones and sites?

Overlaps are especially difficult when two clusters do not need to communicate today but may need to communicate during a migration. If the ranges overlap, NAT can hide the conflict temporarily, but it adds translation rules, observability gaps, and another dependency during an outage. Unique ranges are easier to operate than clever translations.

Dual stack adds another planning dimension. Treat IPv4 and IPv6 as separate address plans with their own routes, firewall rules, service families, and external exposure decisions. A cluster can be valid in one family and still fail because the other family has an overlap or an incomplete route.

Keep the Record Useful During Change

CIDR planning is not finished when the cluster is created. Record the configured Pod range, every Node range, the Service CIDR, the NodePort range, the Load Balancer pool, the address allocator, and the route ownership. Include the date, the cluster name, the environment, and the person or team responsible for changing each range.

When a new Node pool is added, update capacity and subnet usage. When an ingress controller gets a new external address, update the Load Balancer allocation and firewall rule. When a second cluster is created, compare every range before applying its bootstrap configuration. When a cluster is retired, mark its ranges as held until routes, DNS, firewalls, and provider allocations have been removed.

Use live commands to verify the record, not to replace it. Useful checks include kubectl get nodes -o wide, kubectl get pods -A -o wide, kubectl get svc -A, and the relevant cluster or CNI configuration. The command output tells you what exists now. The allocation record tells you why the ranges exist, who owns them, what they connect to, and what must remain true during the next change.

Kubernetes CIDR Planning Checklist

Before approving a cluster network plan, confirm that you can answer these questions:

• What is the Pod CIDR, and how many Pod blocks can it provide to Nodes?
• How many Pods can each Node host, including system Pods and rollout headroom?
• What is the Service CIDR, and how many ClusterIP addresses does the platform expect to consume?
• Which VPC, VLAN, or data center subnets provide Node addresses?
• Are Node subnets large enough for autoscaling, replacement Nodes, and provider reservations?
• Where do Load Balancer addresses come from, and who owns their lifecycle?
• What NodePort range is enabled, and which firewalls allow it?
• Do any Pod, Service, Node, or Load Balancer ranges overlap with connected networks?
• Which component routes Pod traffic, and where are those routes enforced?
• What changes when the cluster adds a region, a second cluster, dual stack, or a site to site connection?

The practical lesson is to plan the address domains separately and validate them together. Pod and Service ranges are not interchangeable, Node subnets are not just another pool of cluster IPs, and a Load Balancer address usually has an owner outside the Kubernetes control plane. Once those boundaries are explicit, CIDR planning becomes a capacity and routing exercise instead of a collection of defaults copied from a tutorial.