GKE IP Address & CIDR Calculator

GKE Networking Explained for Beginners: How Nodes, Pods, and Subnets Fit Together

If you are new to Kubernetes or Google Cloud networking, seeing a single cluster ask for thousands of IP addresses—and three separate CIDR blocks—can feel overwhelming. The easiest way to picture GKE networking is to think of your cluster as an apartment complex inside a gated corporate campus:

• The VPC (Virtual Private Cloud) is your private campus road network: It owns a large block of private IPv4 addresses (typically from RFC 1918 space like 10.0.0.0/16, which holds 65,536 total addresses).
• Nodes are the apartment buildings (Virtual Machines): Each Node is a Compute Engine VM that needs its own street address on the main road. That street address comes from your subnet's Primary IP Range.
• Pods are the individual apartments inside each building: A Pod is the smallest deployable unit in Kubernetes—usually one running application container. In GKE's VPC-native (Alias IP) networking mode, every single Pod gets its own routable internal IP address from a Secondary Pod IP Range. Because these Pod IPs are natively understood by Google Cloud's Andromeda software-defined network, Pods on different VMs (or other GCP services like Cloud SQL and Memorystore) can talk directly to each other without slow Network Address Translation (NAT) overlays.
• Services are the building's front-desk switchboard: Because Pods are ephemeral—constantly scaling up, crashing, or being replaced with brand-new Pod IPs during deployments—other microservices shouldn't hardcode a Pod's IP. A Kubernetes Service (ClusterIP) creates a permanent virtual IP address that automatically forwards traffic to whichever healthy Pods match that service right now.

Quick CIDR Refresher: Why Does /17 Have More IPs Than /24?

In IPv4 networking, CIDR notation (like 10.0.0.0/20) tells you how many of the 32 bits in an IP address are locked for the network prefix versus left free for individual hosts. The total number of IP addresses in any CIDR block is 2(32 - prefix):

• Smaller slash numbers = Bigger networks: A /16 leaves 16 bits free (216 = 65,536 IPs). A /17 cuts that in half (215 = 32,768 IPs).
• Larger slash numbers = Smaller networks: A /24 leaves 8 bits free (28 = 256 IPs). A /26 leaves 6 bits free (26 = 64 IPs). Every time you increase the slash number by +1, you halve the number of IP addresses.

The #1 Beginner Trap: Why GKE Reserves 2x Your Max Pods per Node

The most common mistake in GKE capacity planning is assuming that if your cluster runs 200 Pods, you only need 200 Pod IP addresses. GKE does not hand out Pod IPs one by one from a shared pool. Instead, the moment a new Node VM boots up, GKE slices a fixed CIDR block out of your Pod Secondary Range and assigns that entire block exclusively to that Node.

Even more importantly, GKE reserves a CIDR block with at least twice as many IP addresses as your configured Max Pods per Node. Google Cloud enforces this 2x buffer so that when Kubernetes performs a rolling update or terminates old Pods while starting replacement Pods on the same node, the Linux kernel and CNI plugin never run out of free addresses mid-transition.

For example, in a GKE Standard cluster using the default of 110 Pods per node:

1. Double the target Pod count: 110 × 2 = 220 IPs.
2. Round up to the next power of two: 256 IPs, which is a /24 subnet slice.
3. Result: Every single node locks 256 Pod IPs the instant it starts—even if that node is currently running only 2 Pods! If your Pod secondary range is a /21 (2,048 IPs), your cluster hits a hard ceiling of 2,048 ÷ 256 = 8 nodes, even if your Node subnet has room for 1,000 VMs.

Why Modern GKE Clusters Save Massive Amounts of IP Space

If you have used older GKE calculators (including Google's original 2019 IPAM web app), you might notice they force you to allocate a Service subnet and a /28 master subnet out of your precious RFC 1918 VPC space. Our calculator incorporates three major modern GKE networking improvements:

• GKE-Managed Service Ranges (34.118.224.0/20): ClusterIP Services only need to be reachable inside the cluster itself. When you choose GKE-Managed Service Range, GKE uses Google's privately routed 34.118.224.0/20 range (4,096 Services). It uses 0 IPs from your VPC, and every cluster in your estate can reuse the exact same range without conflict.
• Private Service Connect (PSC) Control Planes: Previously, creating a Private GKE Cluster required VPC Network Peering between your VPC and Google's tenant project, consuming a unique /28 subnet (16 IPs) per cluster. Modern GKE clusters use Private Service Connect (PSC) to expose the Kubernetes API endpoint inside your VPC with 0 extra peering subnets.
• Regional Zone Balancing: A Regional GKE cluster spreads nodes evenly across 3 availability zones (for example, australia-southeast1-a, -b, and -c) for high availability. That is why our calculator rounds the safe node ceiling to a multiple of your active zones and shows your per-zone node capacity.

Where Our Calculations Come From: Official Google Cloud Documentation & Formulas

Every number in the Aviato GKE IP Calculator is derived directly from Google Cloud's official Kubernetes Engine networking formulas and Google's open-source IP Address Management (IPAM) reference implementation. Specifically, the calculator evaluates:

1. Usable Node IPs from Primary Subnet: Max_Nodes_From_Subnet = 2(32 - node_netmask) - 4 (accounting for the 4 reserved IPv4 addresses in every Google Cloud subnet: network address, default gateway, second-to-last reserved IP, and broadcast address).
2. Per-Node Pod Prefix Length: Node_Pod_Netmask = clamp(31 - ceil(log2(Max_Pods_Per_Node)), 23, 28).
3. Max Nodes Supported by Pod Secondary Range: Max_Nodes_From_Pods = floor(2(32 - pod_netmask) / 2(32 - Node_Pod_Netmask)).
4. Effective Cluster Node Ceiling: Raw_Max_Nodes = min(Max_Nodes_From_Subnet, Max_Nodes_From_Pods), rounded down to an even multiple of active cluster zones (Raw_Max_Nodes - (Raw_Max_Nodes mod Zones)).
5. Multi-Cluster Subnet Bin-Packing: To calculate how many identically sized GKE clusters fit inside your available supernet (e.g., 10.0.0.0/16), we sort all requested primary, secondary, and control plane CIDRs from largest block (smallest prefix number) to smallest block to ensure natural CIDR boundary alignment with zero fragmentation, then compute the exact remaining unallocated CIDR blocks.

You can verify all underlying formulas and platform limits in the official Google Cloud documentation:

• Google Cloud Docs: Plan IP address ranges for GKE clusters — Official reference for GKE Autopilot and Standard default CIDR ranges, node subnet sizing, and Pod/Service range limits.
• Google Cloud Docs: Optimize IP address allocation with flexible Pod CIDR ranges — Authoritative lookup table mapping --max-pods-per-node (8 to 256) to per-node subnet masks (/28 to /23) and the 2x Pod IP reservation rule.
• Google Cloud Docs: VPC-native clusters (Alias IP ranges) — How GKE assigns primary node IPs, secondary Pod alias ranges, and GKE-managed Service ranges (34.118.224.0/20).
• Google Cloud VPC Docs: Reserved IP addresses in every subnet — Details on the 4 unusable IPv4 addresses reserved by Google Cloud in every primary VPC subnet.
• Google Cloud Docs: About control plane network isolation & Private Service Connect — Why Private Service Connect (PSC) replaces legacy /28 VPC network peering for GKE control planes.
• GitHub: GoogleCloudPlatform/gke-ip-address-management — Google Cloud's open-source IPAM calculator repository that inspired our multi-cluster subnet bin-packing algorithm.