GKE Max Pods per Node Calculator
Size every VPC-native range before you create the cluster — per-node alias CIDR, maximum nodes, Pod and Services secondary ranges, and the private control plane /28 — with overlap checks and copy-ready gcloud and Terraform.
GKE Max Pods & IP Address Planner
Every range below is fixed at cluster creation — the Services range can never be changed. Rules follow Google's VPC-native documentation.
Cluster ceiling
Also capped, regardless of addressing: 15,000 VMs per VPC network, and 65,000 nodes per Standard cluster.
Limited by the Pod secondary range.
Range overlap check
✓ No overlaps between the node subnet, Pod range, Services range.
Address plan
Copy for your cluster config
gcloud container clusters create CLUSTER_NAME \ --region=REGION \ --enable-ip-alias \ --network=VPC_NAME \ --subnetwork=SUBNET_NAME \ --cluster-ipv4-cidr=10.4.0.0/14 \ --services-ipv4-cidr=10.8.0.0/20 \ --default-max-pods-per-node=110
resource "google_compute_subnetwork" "gke" {
name = "gke-subnet"
region = var.region
network = google_compute_network.vpc.id
ip_cidr_range = "10.0.0.0/20"
secondary_ip_range {
range_name = "gke-pods"
ip_cidr_range = "10.4.0.0/14"
}
secondary_ip_range {
range_name = "gke-services"
ip_cidr_range = "10.8.0.0/20"
}
} resource "google_container_cluster" "primary" {
name = "my-cluster"
location = var.region
network = google_compute_network.vpc.id
subnetwork = google_compute_subnetwork.gke.id
networking_mode = "VPC_NATIVE"
default_max_pods_per_node = 110
ip_allocation_policy {
cluster_secondary_range_name = "gke-pods"
services_secondary_range_name = "gke-services"
}
} Also see: GCP subnet calculator · EKS max pods calculator · Kubernetes pod & service CIDR calculator
GKE inverts the EKS max-pods problem
On Amazon EKS, the maximum pods per node is derived from the instance type — it falls out of
how many Elastic Network Interfaces the instance supports and how many IPv4 addresses each one can
hold. On GKE it works the other way round. In a VPC-native cluster every pod gets an alias IP from a
secondary range on the node's subnet, and
--default-max-pods-per-node
is something you choose. GKE then derives the per-node alias range from your choice.
The rule is that GKE always allocates the smallest block holding at least twice the maximum pods, so a pod IP isn't immediately handed to the next pod as workloads churn on a node. That doubling is why the Standard default of 110 pods burns a full /24 — 256 addresses — on every single node, and why the per-node block is the lever that quietly determines how large your cluster can ever grow.
Max pods per node → alias IP range
| Max pods per node | Alias range per node | IPs reserved | Nodes in a /14 Pod range |
|---|---|---|---|
| 8 | /28 | 16 | 16,384 |
| 16 | /27 | 32 | 8,192 |
| 32 (Autopilot) | /26 | 64 | 4,096 |
| 64 | /25 | 128 | 2,048 |
| 110 (Standard default) | /24 | 256 | 1,024 |
| 128 | /24 | 256 | 1,024 |
| 256 | /23 | 512 | 512 |
Notice the 110 and 128 rows: both land on a /24, so a cluster left at the default is paying for 128 pods of address space while the kubelet will only schedule 110. Notice too that 128 pods per node is not twice as address-hungry as 64 — it is exactly twice, which is the whole point. Halving max pods per node halves your Pod range consumption and doubles the nodes the same range can hold.
What a GCP architect should fix before creating the cluster
- The Services secondary range is immutable. Once the cluster exists you cannot resize it. The default /20 gives 4,096 ClusterIP services, which is generous for most clusters and impossible to fix later if it isn't.
- The node subnet's primary range is a second ceiling. It holds one address per node plus internal load balancer VIPs, minus the four addresses Google Cloud reserves in every subnet. Teams routinely plan against the Pod range and get stopped by this one instead — the calculator above shows both and names which is limiting.
- A private control plane needs exactly a /28. It's peered into your VPC, so it must not collide with the node subnet, either secondary range, or any on-premises range reaching you over Cloud VPN or Interconnect.
- Plan for surge, not steady state. Node pool upgrades and cluster autoscaling both create nodes above your normal count, and each new node claims a full alias block the moment it appears.
- Autopilot is not a way out. It pins max pods per node at 32 and a /26 per node, which is efficient per node, but the Pod range still bounds the cluster and you no longer control the lever.
- Check overlaps against everything you route to, not just what's in this VPC — Shared VPC hosts, peered VPCs, and on-premises ranges all count, and a collision discovered after the cluster is live usually means rebuilding it.
The ceilings that aren't about addressing
Sizing the Pod range generously doesn't buy an unbounded cluster. Three separate limits apply on top of the address plan, and the calculator above accounts for the first two:
- 65,000 nodes per Standard cluster. Past a few thousand nodes there are extra infrastructure requirements and you may need to contact Cloud Customer Care — see Google's cluster size limits and requirements.
- 15,000 VMs per VPC network. Nodes are VMs, so this is shared across every cluster in the network — usually the lower of the two, and easy to miss when several clusters share a Shared VPC.
- Your load balancer. This one isn't an input above, because which load balancer fronts a Service is a separate design decision — but it strands more clusters than either limit above.
| Load balancer | Node limit per cluster |
|---|---|
| Internal passthrough Network Load Balancer | 250 without backend subsetting; 2,000 with subsetting enabled |
| Regional external passthrough Network Load Balancer | 1,000 per zone |
| External Application Load Balancer | 1,000 per zone — no limit with container-native load balancing |
| Internal Application Load Balancer | No node limit |
That first row is the one worth internalising: an internal passthrough Network Load Balancer without backend subsetting caps the cluster at 250 nodes, whatever your Pod range says. Figures from Google's best practices for GKE scalability.
GKE Max Pods FAQ
How does GKE calculate the maximum pods per node?
It doesn't — you choose it. On EKS, max-pods is derived from the instance type's ENI and IP limits, but on GKE --max-pods-per-node is an input, and GKE derives the per-node alias IP range from it. GKE always allocates the smallest range holding at least twice the maximum pods, so pod IPs aren't immediately recycled as pods churn on a node. The Standard default of 110 pods therefore reserves a /24 (256 addresses) per node, and Autopilot's fixed 32 pods reserves a /26 (64 addresses).
What is the max pods per node to node CIDR mapping?
8 pods gets a /28 (16 IPs), 16 gets a /27 (32 IPs), 32 gets a /26 (64 IPs), 64 gets a /25 (128 IPs), 110 and 128 both get a /24 (256 IPs), and 256 gets a /23 (512 IPs). GKE Standard accepts values from 8 to 256; Autopilot is fixed at 32. Lowering the value is the single most effective way to stretch a Pod range, because the per-node block shrinks geometrically.
How many nodes will my Pod secondary range support?
Max nodes = 2^(node CIDR prefix − Pod range prefix). With the default 110 pods per node (a /24 per node) and a /14 Pod range, that's 2^(24−14) = 1,024 nodes. Narrow the Pod range to a /21 and the same cluster tops out at 8 nodes. The node subnet's primary range is a second, independent ceiling — it holds one address per node plus internal load balancer VIPs, minus the four addresses Google Cloud reserves in every subnet — and it is frequently what actually runs out first.
Which GKE ranges can I change after the cluster is created?
Effectively none of the important ones. The Services secondary range is immutable once the cluster exists. The Pod range can be extended with additional Pod IPv4 ranges on newer clusters, but the original range cannot be resized in place, and the private control plane's /28 is fixed at creation. This is why the plan is worth getting right up front: the usual failure mode is an IP_SPACE_EXHAUSTED error surfacing months later when a node pool can't scale up.
Why does a private GKE control plane need a /28?
The control plane runs in a Google-managed VPC that is peered into yours, and GKE requires exactly a /28 for it — not a /29 and not a /27. Because that range is reachable over the peering, it must not overlap your node subnet, either secondary range, or anything else you route to, including on-premises ranges reaching you over Cloud VPN or Interconnect. The overlap check on this page includes it whenever the private cluster toggle is on.
More Network Tools
Free tools for network engineers — no signup, no rate-limit walls.