Configure pod and service subnets
Set the pod and service CIDRs before you create the cluster, because they are fixed at creation and cannot change on a running cluster. Every cluster carves two private IP ranges out of spec.clusterNetwork: the pod CIDR and the service CIDR. A CIDR is simply the notation for a range of addresses. The only way to change a range later is to rebuild the cluster, so setting them correctly up front is worth the few minutes it takes.
Default CIDR ranges
A new cluster uses ranges in the RFC 6598 carrier-grade NAT space (100.64.0.0/10):
spec:
clusterNetwork:
pods:
cidrBlocks: ["100.64.0.0/11"]
services:
cidrBlocks: ["100.96.0.0/16"]
serviceDomain: "cluster.local"
RFC 6598 space is chosen deliberately. Most private networks you might connect to, such as an office LAN, a VPN, or another cloud VPC, live in RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Putting the cluster's own ranges in 100.64.0.0/10 keeps them clear of those, so a pod's address never collides with a host you are trying to reach over a VPN.
Kubernetes assigns each node a slice of the pod range. On this platform that slice is a /24. How many pods actually fit per node is bounded by the pod range slice together with the kubelet's maxPods cap; the exact numbers live in Node resources and limits .
Change the ranges before you create the cluster
If a default range overlaps a network you connect to, set your own under spec.clusterNetwork before you apply the Cluster:
spec:
clusterNetwork:
pods:
cidrBlocks: ["10.128.0.0/12"]
services:
cidrBlocks: ["10.144.0.0/16"]
serviceDomain: "cluster.local"
Rules for the values:
- Each entry is an array of IPv4 CIDR strings.
- The pod and service ranges must not overlap each other, and neither may overlap a network you plan to reach (plan cross-network CIDRs before creation, see Connect to on-prem or another VPC ).
- Size the pod range for the cluster you will grow into: a larger range allows more nodes, since each node takes a
/24. serviceDomainsets the in-cluster DNS suffix (cluster.localby default). Change it only if you have a specific reason, because it affects every in-cluster name.
Warning
The CIDR blocks cannot be changed on a running cluster, only at creation. If you outgrow a range or encounter an overlap later, the remedy is a new cluster with the correct ranges and a migration onto it.
Verify a node's ranges
Each node writes its resolved ranges to a file. Read it to confirm what the cluster actually uses:
$ cat /etc/kubernetes/cluster-network
POD_CIDRS=100.64.0.0/11
SERVICE_CIDRS=100.96.0.0/16
An empty or missing file is a genuine problem: the node's tunnel refuses to route pod traffic without these ranges, which appears as the API server failing to reach pods. See Debug node networking .