Professional Cloud Network Engineer
Configuring secondary IP ranges for Google Kubernetes Engine (GKE) is essential for VPC-native clusters that need IP addresses for Pods and Services. A VPC-native cluster requires a subnet with a primary IP address range for nodes and internal load balancers, plus at least two secondary IP address ranges: one for Pod IP addresses and a separate one for Kubernetes Service addresses. The primary IP address range supplies addresses for GKE nodes and internal load balancers, while the secondary ranges are dedicated to Pods and Services. For Pods, GKE allocates a block of alias IP addresses from the secondary range to each node, typically a /24 per node supporting up to 110 Pods. For Services, a separate secondary range provides stable virtual IP addresses called ClusterIPs. In GKE Standard clusters version 1.29+ and Autopilot clusters version 1.27+, Service addresses can alternatively be assigned from a Google-managed range, eliminating the need for a user-managed secondary range.
Effective IP address planning must account for the maximum number of nodes, the configured Pods per node, and the total number of Services. The size of the Pod secondary range determines the maximum number of nodes a cluster can support because each node reserves a contiguous block from that range. For example, a /14 Pod range with 262,144 addresses can support approximately 900 nodes with the default Pods-per-node setting. You should use a custom subnet mode rather than auto mode to explicitly define non-overlapping ranges. In a Shared VPC architecture, a network administrator in the host project must pre-create these subnet and secondary ranges before a service project administrator can deploy a cluster. These secondary ranges must not overlap with the primary range, other cloud services, or connected on-premises networks.
If RFC 1918 private address space is insufficient, you can use non-RFC 1918 private addresses like 100.64.0.0/10 or privately used public IP (PUPI) addresses for Pod secondary ranges. When using PUPIs or other non-RFC 1918 addresses, you must configure the cluster to handle Source Network Address Translation (SNAT) correctly. For Standard clusters, you typically need to either disable default SNAT at cluster creation or configure the IP masquerade agent to exclude the Pod and Service CIDRs from masquerading. This prevents traffic from these addresses from being incorrectly SNAT'd when exiting the node, which would break return routing. PUPI addresses require careful route management to prevent conflicts when connecting to other networks.
You can share secondary IP address ranges across multiple GKE clusters, particularly within a Shared VPC, to simplify IP address management. However, sharing the Pod range is not recommended because one cluster could exhaust the addresses needed by others. Sharing the Service range is possible but incompatible with VPC-scoped Cloud DNS. To scale a cluster that is exhausting its Pod IP space, you can add discontiguous secondary Pod CIDR ranges using the multi-Pod CIDR feature without recreating the cluster. For internal load balancer Services, you can conserve IP addresses by using a shared VIP, which allows a single IP address to serve up to 50 backends on different ports.
Secondary IP ranges enable integration with specialized services like Cloud Composer, which requires pre-allocated secondary ranges for its GKE pods and services, and Private Service Connect. When connecting VPCs via peering, you must manage route export settings to control the visibility of secondary ranges. In a service provider scenario using PUPIs for Pods, the producer VPC should be configured to import but not export subnet routes with public IPs to prevent route conflicts. Proper planning ensures that secondary ranges do not overlap with ranges used in peered VPCs, on-premises networks connected via Cloud VPN or Cloud Interconnect, or other specialized services to guarantee reliable, conflict-free communication.
Designing primary IP ranges for subnets involves selecting appropriate CIDR blocks that accommodate current resource requirements while allowing for future growth without requiring subnet reconfiguration. In Google Cloud, every subnet must have a primary IP address range, which is the range of internal IP addresses that define the subnet and from which each VM instance gets its primary internal IP address. The primary IP address range also determines the IP addresses available for internal load balancers and nodes within that subnet. When planning primary IP address ranges for GKE clusters, you must account for the number of nodes the cluster needs to support, plus additional addresses for internal load balancers. The first two and last two IP addresses of every primary IP address range are reserved by Google Cloud, reducing usable addresses by four. For example, a /24 subnet provides 252 usable node addresses, while a /20 subnet provides 4,092 usable addresses. The maximum size for a subnet's primary IP address range is /8, which can support over 16 million nodes, though such large ranges are rarely needed.
You can expand the primary IPv4 range of an existing subnet at any time, even when Google Cloud resources such as load balancers and network endpoint groups use the subnet, and traffic within the subnet is not interrupted during expansion. However, expanding the primary IPv4 range cannot be undone because you cannot shrink the primary IP address range of a subnet, so you should expand conservatively. For automatically created subnets in auto mode VPC networks, the broadest prefix you can use is /16 because any prefix broader than /16 would conflict with the primary IPv4 ranges of other automatically created subnets. If you expand a subnet used by a GKE cluster with authorized networks, you must add the expanded IP address range to the control plane authorized networks list. You cannot shrink or change a subnet's primary IP address range after the subnet has been created, but you can expand it by modifying the subnet mask to a smaller prefix number.
Custom mode VPC networks are recommended for enterprise environments because they allow you to choose IP address ranges that won't overlap with ranges in on-premises networks or other cloud environments, whereas auto mode networks all use the same set of internal IP ranges. Grouping applications into fewer subnets with larger address ranges simplifies management and provides flexibility for growth. When planning IP address allocations, preallocate and reserve ranges by creating internal ranges, and ensure that allocated address blocks can be aggregated to make later configuration and operations more straightforward. The primary address range of the subnet should accommodate anticipated growth and account for the four unusable IP addresses reserved in every primary IP address range.
Alias IP ranges allow multiple internal IP addresses from primary or secondary subnet ranges to be assigned to a single VM network interface. When deploying containers, a subnet is configured with a primary range for VM hosts and one or more secondary ranges dedicated to containers or Pods. For example, a VM receives its primary IP address from the primary subnet CIDR block such as 10.128.0.0/16, while container endpoints receive smaller allocations such as /24, /27, or /32 blocks drawn from the secondary range such as 172.16.0.0/20. When Cloud Router is deployed in the network, it automatically advertises these secondary ranges across hybrid interconnects and VPN tunnels to ensure full routing reachability. Auto mode VPC networks require specific considerations when planning alias IP ranges because their automatically generated subnets lack secondary ranges by default. To use alias IPs in an auto mode network, you must either allocate alias addresses directly from the auto-created primary range, add a secondary range to the existing subnet, or create a custom subnet containing secondary ranges. For containerized applications, assigning /32 alias IP ranges supports individual container migration between VM instances, whereas assigning larger contiguous blocks such as /27 suits non-migratable container groups bound to a specific host.
Internal load balancers that use Envoy proxy architectures, including cross-region internal Application Load Balancers and cross-region internal proxy Network Load Balancers, require a dedicated proxy-only subnet in every region where backends reside. The proxy-only subnet provides a pool of IP addresses that Google Cloud uses to run managed Envoy proxies, which terminate incoming client connections and establish new connections to backend VMs. Proxy-only subnets must be configured with an active role and a specific purpose such as REGIONAL_MANAGED_PROXY or GLOBAL_MANAGED_PROXY. Google Cloud enforces strict allocation rules between proxy-only subnets and backend workloads: a proxy-only subnet is reserved exclusively for Google-managed Envoy proxies and cannot be assigned to VM instances, backend network endpoint groups, or forwarding rules. Only one active proxy-only subnet can exist per purpose, per region, in a single VPC network. Proxy-only subnets should use a recommended prefix of /23 with 512 addresses to ensure sufficient proxy capacity during peak traffic and failover events. Load balancer frontend IP addresses and backend VM interfaces must be provisioned from standard backend subnets in the same region, entirely separate from the proxy-only range.
Preventing IP address exhaustion requires calculating the precise number of nodes, Pods, and Services needed across the lifecycle of an application cluster. Because a cluster's total capacity depends on its allocated secondary ranges, the secondary CIDR block for Pods must be significantly larger than the range for Services. For instance, a cluster might assign a /16 block with 65,536 addresses for Pods to support heavy scaling, but only require a /20 block with 4,096 addresses for internal Service ClusterIP addresses. All primary subnet ranges, secondary Pod ranges, and secondary Service ranges must be mutually exclusive and non-overlapping across the VPC and all peered or on-premises networks. If a Pod or Service CIDR range overlaps with an external IP address, traffic sent from a container to that external address is mistakenly treated as in-cluster traffic and fails to leave the cluster. Using RFC 1918 private address spaces for all primary and secondary allocations avoids conflicting with routable public endpoints. In a Shared VPC architecture, network administrators centralize these subnet allocations inside a single host project, supporting up to 1,000 attached service projects while maintaining strict boundaries across distinct workload environments.
Internal load balancer forwarding rules require specific virtual IP (VIP) configurations and corresponding VPC firewall rules to ensure proper traffic distribution. By default, each internal forwarding rule consumes a distinct internal IP address from the backend subnet. When multiple forwarding rules need to share a single internal IP address, such as when configuring HTTP-to-HTTPS redirect pairs, the static IP address must be reserved in advance with its purpose set to SHARED_LOADBALANCER_VIP. Backend VMs must have an ingress allow rule permitting TCP traffic from Google Cloud health check probes originating from 130.211.0.0/22 and 35.191.0.0/16. An ingress allow rule must permit traffic from the proxy-only subnet range to backend target instances on application ports such as TCP 80, 443, or 8080. Firewall rules should use target tags or service accounts to enforce least-privilege access and restrict ingress exclusively to designated backend instances.
StudyCerts
StudyCerts/23 prefix with 512 addresses.The primary IP address range provides IP addresses for VM instances, nodes, and internal load balancers. Secondary IP address ranges provide additional IP addresses for specialized purposes such as GKE Pods, Kubernetes Services, and alias IP addresses for containers. Primary ranges cannot be changed after subnet creation, while secondary ranges can be added or modified.
Use a proxy-only subnet whenever you deploy cross-region internal Application Load Balancers or cross-region internal proxy Network Load Balancers that use Envoy proxies. The proxy-only subnet must exist in every region where backend VMs reside, and it provides IP addresses exclusively for Google's managed Envoy proxies, not for your VM instances.
No, you cannot shrink a subnet's primary IP address range after creation. You can only expand it by using a smaller prefix number. This is why careful upfront planning is essential—you should allocate a primary range large enough for future growth while avoiding excessively large ranges that waste IP address space.
Prepare and test your skills
Prepare and test your skills