Professional Cloud Network Engineer

Native Routing and Hybrid Network Interconnectivity

Core Architecture of VPC-Native Clusters and Alias IPs

A VPC-native Google Kubernetes Engine (GKE) cluster assigns internal IP addresses directly to Pods and Services from a subnet range in a Virtual Private Cloud (VPC) network. By using alias IP ranges, each Compute Engine node hosts an alias IP block from which its local Pods receive individual addresses. This design allows traffic to flow directly between Pods, across VPC Network Peering connections, and through Cloud VPN or Cloud Interconnect without requiring custom static routes or network address translation (NAT). Direct routing removes the packet latency associated with extra routing hops and eliminates the consumption of VPC static route quotas that limit routes-based clusters.

IP Address Space Allocation and Limitations

A VPC-native cluster requires four separate IP address ranges across its lifecycle. The node subnet provides the primary IP range for worker nodes and internal load balancers, while secondary IP ranges on that same subnet provide dedicated address space for Pods and Services. The GKE control plane runs in a Google-managed tenant project and requires a dedicated /28 RFC 1918 address range that must not overlap with any subnet in the VPC network peering group. While administrators can expand a subnet's primary IP range and attach additional secondary Pod ranges to an existing cluster, the secondary range assigned to Services cannot be modified or expanded after creation.

+-----------------------------------------------------------------------+
| Subnet (Host / VPC Network)                                           |
|  - Primary Range: Node IPs, Internal Load Balancers                   |
|  - Secondary Range A: Pod IPs (Node Alias IP Slices)                  |
|  - Secondary Range B: Service ClusterIPs                              |
+-----------------------------------------------------------------------+
                                  |
                                  v Peered
+-----------------------------------------------------------------------+
| Google-Managed Tenant Project: Control Plane (/28 RFC 1918 Range)     |
+-----------------------------------------------------------------------+

Non-RFC 1918 and Privately Used Public IP Ranges

Organizations facing internal address exhaustion can deploy VPC-native clusters using non-RFC 1918 private ranges or privately used public IP (PUPI) ranges. Non-RFC 1918 allocations typically use RFC 6598 shared address space (100.64.0.0/10) or Class E address space (240.0.0.0/4) for secondary Pod allocations. When a cluster uses a PUPI range, workloads can no longer route traffic to external internet hosts that use those identical public IP addresses, because the VPC network treats those addresses as local destinations. Additionally, an internal passthrough Network Load Balancer must draw its IP address from the subnet's primary range, meaning that the primary range itself must use the non-RFC 1918 block if the load balancer requires one.

Traffic Destination
   |
   +---> In-VPC / Peered Subnet (RFC 1918 / PUPI) ---> Direct VPC Route
   |
   +---> Internet Public Host (Overlapping PUPI) ---> Blocked / Trapped in VPC

---

Shared VPC Integration and Traffic Isolation

Cross-Project Deployment in Shared VPC

Shared VPC architecture allows a central host project to own network subnets while individual service projects run GKE clusters attached to those shared resources. To deploy a VPC-native cluster in a service project, the host project administrator grants the Compute Network User role to the service project's GKE service accounts. The cluster in the service project then consumes pre-defined primary and secondary IP ranges managed within the host project's subnet. This separation allows central network teams to control IP allocation and firewall rules while application teams manage cluster workloads independently.

[ Host Project ]
  └─ Shared VPC Subnet (Primary Node CIDR, Secondary Pod CIDR, Secondary Service CIDR)
        │
        ▼ (Compute Network User Role Delegated)
[ Service Project ]
  └─ VPC-Native GKE Cluster (Worker Nodes & Workloads)

Private Cluster Endpoints and Egress Management

A Private GKE cluster isolates cluster nodes by assigning them internal-only IP addresses, blocking direct inbound and outbound internet exposure. Administrators can expose the control plane through a public endpoint, a private endpoint, or both. When using private endpoints exclusively, management tools such as Cloud Build private worker pools must be peered directly into the VPC network or routed through an internal network proxy. Outbound traffic from Pods is controlled by the IP masquerade agent (IMA), which decides whether a packet keeps its native Pod IP address or undergoes Source Network Address Translation (SNAT) to appear as the node's primary IP address.

Pod Egress Packet
   │
   ├── Destination: VPC / Peered Subnet ──> Native Pod IP (Direct Routing)
   │
   └── Destination: External / Non-CIDR ──> IP Masquerade Agent (SNAT to Node IP)

Network Security and Private Access Policies

Securing a VPC-native cluster requires coordinating network perimeters, service access rules, and automated worker constraints. Private Google Access (PGA) must be enabled on the cluster's subnet in the host project so private nodes can reach Google APIs (such as Artifact Registry) without traversing public IP routes. Security administrators can place the Shared VPC and private build pools inside a VPC Service Controls perimeter to prevent data exfiltration across organizational boundaries. Furthermore, organizations can enforce the constraints/cloudbuild.allowedWorkerPools policy constraint to block builds on shared default infrastructure and mandate dedicated private worker pools.

---

Subnet Sizing and Secondary CIDR Allocation

Primary Subnet Calculation for Cluster Nodes

The primary IPv4 range of a subnet provides IP addresses for Compute Engine worker nodes, internal load balancers, and control plane endpoints. Google Cloud reserves four addresses in every primary subnet range (the first two and last two addresses), which makes them unusable for nodes. When sizing a primary subnet for a target node count $N$, the required subnet mask size $S$ is calculated with the formula:

$$S = 32 - \lceil\log_2(N + 4)\rceil$$

For example, a cluster requiring 900 nodes needs at least a /22 primary subnet range, which yields $2^{10} - 4 = 1{,}020$ usable addresses. Primary ranges support sizes from /29 (supporting up to 4 nodes) to /8, and while an administrator can expand an existing primary range, a primary range cannot be shrunk once created.

Primary Subnet Mask Calculation:
Target: 900 Nodes
Formula: S = 32 - ⌈log2(900 + 4)⌉ = 32 - 10 = /22 (1,020 Usable IPs)

Pod CIDR Sizing and Node Density Optimization

A secondary IPv4 address range supplies the IP blocks assigned to each node for its running Pods. In GKE Standard clusters, each node receives a /24 CIDR block by default (256 addresses) to support up to 110 Pods per node, providing a 2-to-1 address buffer that handles address churn during Pod lifecycle updates. GKE Autopilot clusters fix this limit at 32 Pods per node, automatically provisioning a /26 CIDR block (64 addresses) per node. Network administrators can optimize IP consumption in GKE Standard by adjusting maximum Pod limits during node pool creation:

• High-density workloads: Setting the limit up to 256 Pods per node allocates a /23 block (512 addresses) per node, which is best for large compute instances.
• Low-density workloads: Setting the limit to 64 or 32 Pods per node allocates a smaller /25 or /26 block, conserving IP space across large clusters.
• Standard cluster sizing: Sizing a secondary Pod range at /14 yields 262,144 addresses, which supports 1,024 nodes when using the default /24 allocation per node.

Service Ranges and Multi-Pod Expansion Strategies

The secondary IPv4 range for Services assigns internal, virtual cluster addresses (ClusterIP) to expose internal workloads. Modern GKE Standard and Autopilot clusters automatically default to a Google-managed Service range (34.118.224.0/20), which avoids consuming the organization's private VPC IP addresses. If a cluster exhausts its initial Pod address space, administrators can attach additional secondary ranges using discontiguous multi-Pod CIDR without destroying the cluster. New node pools can then be targeted to these new secondary ranges, allowing the cluster to scale beyond its original network footprint.

Cluster Scale-Up with Discontiguous Multi-Pod CIDR:
[ Existing Secondary Range A ] ---> [ Node Pool 1 (Pods) ]
[ Attached Secondary Range B ] ---> [ Node Pool 2 (New Pods) ]

---

Key Facts

• A VPC-native cluster allocates IP addresses for nodes from a subnet's primary range, while Pods and Services consume secondary alias IP ranges from the same subnet.
• The GKE control plane requires a dedicated /28 RFC 1918 range within a peered tenant project that must not overlap with any subnet in the VPC network.
• Google Cloud reserves four IP addresses in every primary subnet range, leaving $2^{(32 - S)} - 4$ usable addresses for cluster nodes and internal load balancers.
• A cluster's secondary range for Services cannot be modified or expanded after creation, whereas Pod address space can be expanded using discontiguous multi-Pod CIDR.
• In Shared VPC environments, the host project administrator must grant the Compute Network User role to the service project's GKE service account to allow range allocation.

---

Frequently Asked Questions

What is the main routing benefit of a VPC-native cluster over a routes-based cluster?

A VPC-native cluster uses alias IPs so that Pod addresses are native to the VPC network, allowing Pod traffic to route directly across VPC peering and hybrid interconnects without consuming VPC route quotas or introducing extra routing hops.

How does the IP masquerade agent handle traffic leaving a VPC-native cluster?

The IP masquerade agent leaves packets destined for internal VPC subnets unchanged so they keep their native Pod IP addresses, while it applies source network address translation (SNAT) to packets destined for external or non-RFC 1918 ranges so they appear with the node's primary IP address.

What happens if an organization uses privately used public IP (PUPI) ranges for a cluster?

The cluster successfully uses the public address space for internal Pod routing, but workloads inside the VPC network can no longer reach external internet systems that own those identical public IP addresses because the VPC treats them as local destinations.

How can administrators conserve IP address space when deploying nodes with low Pod counts?

Administrators can reduce the maximum Pods per node setting on a node pool from the default of 110 to 64 or 32, which reduces the per-node alias IP allocation from a /24 block down to a /25 or /26 block.