IP address planning for Google Kubernetes Engine clusters involves selecting appropriate IP address ranges for nodes, Pods, and Services while ensuring no overlap with existing networks and sufficient space for cluster scaling. GKE supports multiple IP addressing options including RFC 1918 private addresses, non-RFC 1918 private addresses, and privately used public IP (PUPI) addresses, each with distinct characteristics that make them suitable for different scenarios.
RFC 1918 private IP address ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) are the recommended and most common choice for GKE clusters. These addresses are not routable on the public internet, making them inherently secure for internal cluster communication. VPC-native clusters allocate node IP addresses from the primary subnet range, while Pods and Services receive addresses from secondary ranges within the same subnet. RFC 1918 addresses work seamlessly with VPC Network Peering, Cloud VPN, Cloud Interconnect, and Private Service Connect without requiring special configuration. The primary advantage of RFC 1918 addresses is their universal acceptance by on-premises networking equipment and cloud providers, reducing the likelihood of compatibility issues during hybrid cloud deployments.
When organizations exhaust RFC 1918 address space, non-RFC 1918 private addresses provide additional flexibility. The RFC 6598 address space (100.64.0.0/10) is commonly used for this purpose and is recommended over Class E (240.0.0.0/4) addresses due to interoperability concerns with certain on-premises hardware and Windows hosts. Non-RFC 1918 addresses require the same VPC-native alias IP configuration as RFC 1918 addresses but demand careful planning to avoid conflicts with other private address spaces in hybrid environments. For Standard clusters using non-RFC 1918 addresses, administrators must either explicitly disable default SNAT or configure the IP masquerade agent to exclude cluster Pod IP addresses from SNAT processing.
Privately used public IP (PUPI) addresses are public IP address ranges that organizations use privately within their VPC networks without owning the addresses. PUPI addresses serve as an effective solution when RFC 1918 space is exhausted and non-RFC 1918 space is unavailable or already in use. PUPI addresses can only be applied to Pod IP address ranges, not to node or Service IP addresses. When using PUPI addresses, the IP masquerade agent must be configured to perform Source Network Address Translation (SNAT) on outbound traffic from Pods; otherwise, return traffic routes over the public internet and fails. For Autopilot clusters, SNAT for PUPI traffic requires no additional configuration, while Standard clusters require explicit SNAT enablement.
PUPI addresses introduce complexity when used with VPC Network Peering because PUPIs are not automatically advertised between peered VPCs by default. In a producer-consumer service model where a service provider runs GKE clusters in their own VPC, the producer must explicitly enable export of PUPI routes and the consumer must enable import of those routes through the peering connection. If PUPI ranges overlap between VPCs, direct Pod-to-Pod communication is impossible, requiring IP address masquerading where Pod IP addresses are translated behind node IP addresses. Organizations must also ensure that node IP addresses and primary IP address ranges do not overlap across VPCs involved in the peering relationship.
GKE clusters use specific Google-managed IP address ranges for cluster operations. The control plane in Private Service Connect clusters requires a /28 subnet within the RFC 1918 private ranges that does not overlap with any other CIDR in the VPC network. For Services, GKE Autopilot clusters running version 1.27 and later and Standard clusters running version 1.29 and later use the 34.118.224.0/20 IPv4 address range by default, which Google manages internally without publishing routes on the public internet. These Google-managed ranges cannot be used for external IP addresses of resources and are allocated automatically based on cluster configuration.
Private Service Connect (PSC) enables private connectivity between VPC networks and Google Cloud services without exposing traffic to the public internet. When using PSC with GKE, the primary subnet range provisions the internal IP address assigned to the control plane endpoint, though this can be overridden using the private-endpoint-subnetwork flag. PSC also allows organizations to reduce IP address consumption by providing connectivity between VPCs with overlapping IP addresses, making it valuable for multi-tenant architectures or scenarios where IP address space is severely constrained. However, PSC endpoints can only be reached from the same region as the service and cannot be accessed from peered VPCs or networks connected through Cloud VPN or Cloud Interconnect.
Shared VPC architectures centralize IP address management by allowing a network administrator in a host project to create subnets and share them with service projects where GKE clusters operate. This model works well for organizations with centralized network teams because the IP address component remains in the host project while cluster components live in the service project. Shared VPC networks help avoid IP address conflicts across the organization and provide governance for operational functions by separating network administration from cluster operations. In Shared VPC environments, secondary IP address ranges cannot be managed by GKE directly; a Network Admin in the host project must create the subnet and secondary ranges before cluster creation.
The choice between RFC 1918, non-RFC 1918, and PUPI addresses depends on several factors: available address space, hybrid connectivity requirements, VPC peering relationships, and operational complexity tolerance. RFC 1918 addresses should be the default choice for most organizations due to their universal compatibility and straightforward configuration. Non-RFC 1918 addresses suit organizations that have exhausted RFC 1918 space but want to avoid the complexity of PUPI configuration. PUPI addresses serve organizations with large public IP allocations that need additional internal address space, though they require careful planning for VPC peering scenarios and mandatory IP masquerade agent configuration. All three options can coexist within an organization's Google Cloud environment, with RFC 1918 typically used for nodes and Services while non-RFC 1918 or PUPI addresses handle Pod IP ranges.
Google-managed IP ranges and shared IP architectures allow organizations to optimize address allocation, simplify cluster provisioning, and isolate network control boundaries in Google Kubernetes Engine (GKE). By offloading internal Service IP management to reserved Google-managed ranges and centralizing subnet allocations across multi-cluster environments, network administrators prevent address exhaustion across their Virtual Private Cloud (VPC) networks.
Google-managed IP ranges provide automated address assignments for Kubernetes Service objects and dedicated management endpoints for private cluster control planes. In GKE Autopilot clusters (version 1.27 and later) and GKE Standard clusters (version 1.29 and later), GKE automatically assigns IPv4 ClusterIP addresses from the Google-managed 34.118.224.0/20 range by default, while IPv6 dual-stack Services utilize the 2600:2D00:0:4::0:0/64 range. Google Cloud treats these ranges as private, non-routable spaces on the public internet, which eliminates the requirement for administrators to allocate custom secondary subnet ranges for internal Service discovery.
For private cluster architectures, the control plane resides within a Google-managed tenant project that communicates with nodes in the customer VPC network across a Private Service Connect (PSC) endpoint or VPC Network Peering. The control plane requires a dedicated /28 subnet from the private RFC 1918 space that must not overlap with any existing CIDR block in the VPC or connected on-premises routes. When using PSC, GKE provisions the internal endpoint from the cluster subnet's primary IP range by default, but administrators can override this placement to a specific subnet using the --private-endpoint-subnetwork parameter during creation.
Shared IP range strategies consolidate address consumption by reusing secondary ranges or sharing single virtual IP addresses among multiple network services. In large environments, network teams can configure multiple GKE clusters to share the same secondary subnet ranges for Pods and Services to minimize overall address consumption. While sharing secondary Pod ranges across clusters reduces subnet proliferation, traffic management requires strict planning because a single expanding cluster can consume the entire available allocation. Furthermore, sharing secondary Service ranges is incompatible with VPC-scope Cloud DNS for GKE, which requires unique cluster namespaces across the shared VPC network.
To optimize internal load balancing resources, GKE allows internal TCP/UDP load balancers to share a single virtual IP address across up to 50 distinct backend services using different port configurations. Without a dedicated load balancer subnet, internal load balancers allocate internal IP addresses directly from the node subnet's primary range, accelerating primary subnet exhaustion and capping node scalability. Establishing dedicated load balancer subnets isolates front-end ingestion from node compute resources and enables targeted security filtering between clients and GKE nodes.
Shared VPC networks separate network administration from cluster lifecycle operations across multi-tenant Google Cloud projects. Under the Shared VPC model, a central network administrator creates and manages subnets and secondary IP ranges within a centralized host project, while platform administrators deploy GKE clusters within individual service projects. Secondary IP ranges in a Shared VPC cannot be managed or dynamically expanded by GKE, meaning host project administrators must pre-allocate all primary and secondary ranges prior to cluster deployment.
This separation of duties requires service project administrators to hold subnet-level Identity and Access Management (IAM) permissions on the shared subnets in the host project. If cluster growth exhausts the primary address space, an administrator can expand the primary subnet range without rebuilding existing node pools or load balancers. However, whenever a subnet's primary range is expanded, administrators must manually update the cluster's authorized networks list with the new CIDR block to prevent ingress-allow firewall discrepancies that could break node registration with the control plane.
Private Service Connect (PSC) for GKE is a networking model that enables private, secure access to services hosted on GKE clusters from external networks, including other VPCs, on-premises environments, or the internet, without exposing the cluster's internal Pod IP address space. This design focuses on architecting PSC endpoints for GKE services and planning the underlying IP address allocation strategies for nodes, Pods, and load balancers (both internal and external) using a variety of address types.
Architecting Private Service Connect (PSC) endpoints for GKE involves publishing internal services for private consumption by clients in other VPC networks. A service producer creates a Service Attachment resource in their GKE cluster's VPC. This resource defines the backend service (typically an internal passthrough Network Load Balancer) and connection policies. Consumers in a different VPC network then create a Private Service Connect endpoint, which is a forwarding rule with an internal IP address from their own subnet. This endpoint privately connects to the producer's Service Attachment.
This model creates a clear network boundary and hides the producer cluster's Pod and node IP addresses. Traffic flows from the consumer's VPC to the PSC endpoint's IP address, then through the Google Cloud backbone directly to the producer's internal load balancer, without traversing the consumer's or producer's general VPC routing tables. Choose this PSC-based architecture when you need to share services across VPCs with overlapping IP addresses, require strict access control, or want to centralize service access without managing complex peering or VPN configurations.
Designing IP allocation for GKE clusters requires planning separate, non-overlapping ranges for nodes, Pods, Services, and the control plane. For internal addressing, you typically start with RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Nodes receive IPs from the subnet's primary range, while Pods and Services use designated secondary ranges. If RFC 1918 space is exhausted or conflicts with connected networks (like on-premises), you can use non-RFC 1918 private addresses, such as the 100.64.0.0/10 range (RFC 6598).
Using non-RFC 1918 ranges requires careful configuration of the IP Masquerade Agent on Standard clusters to exclude these Pod IPs from Source Network Address Translation (SNAT); otherwise, Kubernetes assumes they are public IPs and applies SNAT, which can break return traffic routing. For Autopilot clusters, this configuration is handled automatically. Choose non-RFC 1918 ranges when you need additional private address space but must avoid conflicts with existing RFC 1918 deployments in interconnected environments.
Privately Used Public IP Addresses (PUPI) are public IP address ranges (not owned by Google) that you can use privately within your VPC network for GKE Pod CIDR blocks. This strategy helps mitigate RFC 1918 address exhaustion. A PUPI range, like 45.45.0.0/16, is assigned as a secondary IP address range for Pods, while nodes and services continue to use standard private ranges.
When using PUPIs, especially in multi-cluster or service provider scenarios with VPC Network Peering, you must manage route advertisements carefully. By default, PUPI ranges are not automatically advertised over VPC peering connections. You must explicitly configure the peering to export these routes if Pods in different VPCs need to communicate directly. More commonly, services are exposed via internal load balancers using private IPs, and PSC is used for cross-VPC access, avoiding the need to advertise PUPI ranges. Choose PUPIs when your organization has large, unused public IP address blocks and you face severe private address constraints, but be cautious of potential future conflicts if those addresses are ever used publicly.
GKE uses Google-managed services ranges for specific components to simplify IP management. For example, in clusters using Private Service Connect for the control plane, the control plane's internal IP address comes from a Google-managed tenant project. Additionally, for Services (ClusterIP), GKE Standard clusters (version 1.29+) and Autopilot clusters (version 1.27+) can automatically use the Google-managed 34.118.224.0/20 range, eliminating the need to provision a secondary Service range.
Shared IP ranges refer to strategies for conserving IP addresses across multiple clusters or services. You can share a single secondary IP address range for Pods or Services across multiple GKE clusters, especially within a Shared VPC model. However, sharing a Pod range is not recommended because one cluster could exhaust all addresses. Sharing a Service range can work but may conflict with VPC-scoped Cloud DNS. A more controlled approach is to share IP addresses for internal LoadBalancer Services, where a single internal IP address (VIP) can be shared by up to 50 backend services using different ports, reducing the number of IPs consumed from the primary subnet.
Creating a dedicated load balancer subnet is a critical advanced IP configuration. This separate subnet, with its own primary IP address range, is used specifically for the internal IP addresses of internal passthrough Network Load Balancers exposing GKE Services. Without it, internal load balancers consume IPs from the node subnet's primary range, which can prematurely exhaust addresses needed for node scaling and hinder cluster growth.
Advanced planning must also account for cluster autoscaler and maximum Pod density. You must reserve enough IP space in both the node primary range and the Pod secondary range to support the autoscaler's maximum number of nodes, with each node requiring one node IP and a block of Pod IPs (e.g., a /24 for up to 110 Pods). You can adjust the maximum Pods per node on Standard clusters (up to 256) to optimize IP usage. Furthermore, using discontiguous multi-Pod CIDR allows you to add additional Pod IP address ranges to an existing cluster if the initial range is exhausted, providing flexibility for scaling.
Use PUPI addresses when your organization has exhausted RFC 1918 address space and non-RFC 1918 space is unavailable or already in use. PUPI addresses can only be applied to Pod IP ranges, not to nodes or Services, and require the IP masquerade agent to be configured for SNAT on Standard clusters.
VPC Network Peering automatically exchanges routes between VPCs, while Private Service Connect creates explicit point-to-point connections that hide the producer cluster's IP addresses. PSC allows connectivity between VPCs with overlapping IP addresses, but PSC endpoints can only be reached from the same region, unlike peering which works across regions.
Without a dedicated load balancer subnet, internal load balancers consume IP addresses from the node subnet's primary range, which accelerates primary subnet exhaustion and limits node scalability. A dedicated load balancer subnet isolates front-end IP consumption from node compute resources.
Sharing a Pod secondary range across clusters is not recommended because one expanding cluster can consume the entire available allocation, leaving no space for other clusters. Sharing Service ranges is possible but may conflict with VPC-scoped Cloud DNS for GKE.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts