A 110-Pod node can reserve 256 Pod addresses

With the common 110-Pod maximum, GKE normally allocates a /24 Pod block to each node. Size the secondary range from maximum nodes, not today's replicas.

Per-node block

/24 = 256 addresses reserved to support up to 110 Pods.

Shopwave target

60 nodes × 256 addresses = 15,360 Pod addresses.

Choose /18

16,384 total addresses gives the planned ceiling with little spare margin.

Prefer headroom

A /17 doubles the address pool and reduces readdressing risk.

Lowering max Pods per node can reduce per-node allocation, but it also changes scheduling density.

A 110-Pod node can reserve 256 Pod addresses

Pod range sizing is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. GKE allocates a per-node Pod CIDR based on the maximum Pods per node. At the usual 110-Pod setting that allocation is a /24 even though only 110 Pods run there. The Kubernetes objects stay familiar, but GKE supplies controllers, infrastructure and safe defaults around them. This is why a team can move from an on-premises cluster without rewriting every workload, while still needing to redesign networking, identity and operational ownership for the cloud environment.

A useful inspection step is `gcloud container clusters describe shopwave-prod --format='value(defaultMaxPodsConstraint.maxPodsPerNode)'`. Read the output as evidence, not as a ritual: first confirm the desired object exists, then look at status conditions, events and the Google Cloud resource it represents. In production, capture the expected result in a runbook or automated check so an operator can distinguish slow reconciliation from a configuration error.

Production gotcha: Multiplying desired Pods by one address is wrong because allocation happens in node-sized blocks; calculate from the maximum node count. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. Private connectivity adds the next boundary.