Professional Cloud Network Engineer
Managing Service address ranges in Google Kubernetes Engine (GKE) involves configuring how cluster-internal Services receive IP addresses from the VPC network, while IP Masquerade policies control how traffic leaving the cluster gets network address translation (NAT) applied for external connectivity.
For GKE Autopilot clusters running version 1.27 and later, and GKE Standard clusters running versions 1.29 and later, GKE automatically assigns IP addresses for Services from a managed range of 34.118.224.0/20. This default behavior means administrators do not need to specify their own IP address range. If a custom range is needed, you can specify one using the --services-ipv4-cidr flag during cluster creation. When using this managed approach, GKE does not create a separate secondary IP address range for Services, which simplifies setup but offers less customization.
For full control, you can manually manage your VPC-native cluster's subnets by creating secondary IP address ranges for Pods and Services. When you manually create these ranges, you become responsible for all create, read, update, and delete (CRUD) operations. User-managed ranges allow the use of smaller subnet ranges than GKE-managed ranges permit, but you must be cautious not to exhaust Pod IP addresses as the cluster grows. The smallest IP address range you can create without using a special feature is /28, which would only support one node with a maximum of eight Pods.
To configure two or more clusters to share a common subnet secondary IPv4 address range for Services, you use the same range when creating each cluster. Each cluster uses the entire range internally, but Service IP addresses are only usable by client Pods within the same cluster. When a Pod sends a packet to a Service IP address, the node performs destination Network Address Translation (NAT), changing the destination IP address from the Service IP to a serving Pod IP address. Sharing the range reduces the number of unique secondary ranges created but is not supported with VPC scope Cloud DNS for GKE.
When creating a VPC-native cluster in a Shared VPC environment, an administrator in the host project must manually create the cluster's subnet and secondary IP address ranges. A service project administrator needs at least subnet-level permissions. In this environment, secondary IP address ranges cannot be managed by GKE, so all Service and Pod ranges must be explicitly created and managed by the administrator. You cannot use a shared secondary range for Services when creating clusters through the Google Cloud console; you must use the command line.
The maximum number of Pods and Services for a GKE cluster is limited by the size of the cluster's secondary ranges. The maximum number of nodes is limited by the size of the subnet's primary IP address range and the cluster's Pod address range. If either range is exhausted, node creation fails. To add more IP addresses for nodes, you can expand the primary subnet. To add more for Pods, you can use a feature called discontiguous multi-Pod CIDR or create a new cluster with a larger range.
Google Kubernetes Engine (GKE) VPC-native clusters use Virtual Private Cloud (VPC) alias IP ranges to assign natively routable IP addresses to Pods and Services from secondary subnet ranges. Sizing these ranges properly requires calculating the total number of projected nodes, evaluating the configured maximum Pod density per node, and accounting for extra addresses needed for Pod creation and deletion cycles. Precise planning prevents IP address exhaustion.
Pod secondary IP ranges must be sized to provide each cluster node with a dedicated CIDR block large enough to support its maximum assigned Pod capacity. In GKE Standard clusters, the default allows up to 110 Pods per node and allocates a /24 alias IP range (256 addresses) per node, providing extra addresses to accommodate rapid Pod churn. If a cluster needs to scale to 256 Pods per node, GKE assigns a /23 range (512 addresses) per node. Reducing the node limit to 64 or fewer Pods enables smaller node allocations like /25 or /26. Calculating total capacity involves formulas that consider the Pods-per-node limit and the size of the overall Pod subnet.
Service secondary ranges provide static internal virtual IP addresses (ClusterIP) for Kubernetes Service discovery. A cluster's secondary Service CIDR can range from a minimum size of /27 (32 addresses) to a maximum of /16 (65,536 addresses), with /20 (4,096 addresses) as a traditional default. In newer GKE versions, GKE assigns Service IP addresses from a managed 34.118.224.0/20 range by default, freeing up customer VPC address space. If you configure a user-managed range instead, its size is fixed after creation. Running out of Service addresses prevents the creation of new Services or internal load balancer endpoints.
GKE Autopilot and Standard clusters enforce distinct trade-offs between automated management and customizable address conservation. Autopilot clusters enforce a fixed limit of 32 Pods per node, assigning a /26 CIDR range (64 IP addresses) to every node. This reduces address consumption but cannot be tuned. Standard clusters grant full control over Pod CIDR allocation per node pool, enabling targeted address conservation based on workload profiles. However, Standard clusters require continuous administrative tracking of IP address consumption to prevent provisioning failures.
When private RFC 1918 address space is limited, network architects can use alternative ranges like RFC 6598 shared address space (100.64.0.0/10) or privately used public IP (PUPI) addresses for Pod ranges. When using PUPI or non-RFC 1918 space with Standard clusters, administrators must configure the IP masquerade agent to ensure intra-cluster Pod traffic is not unintentionally translated to node IP addresses. Clusters that exhaust their initial Pod allocation can use discontiguous multi-Pod CIDR to add supplementary secondary IPv4 ranges without recreating the cluster, allowing for dynamic scaling.
Configuring and expanding multi-Pod CIDR ranges is the practice of adding additional, non-overlapping secondary IPv4 address ranges to a Google Kubernetes Engine (GKE) cluster to provide more IP addresses for Pods. This remediates IPv4 address exhaustion in existing VPC-native clusters without disrupting active workloads, and is a core strategy for scalable IP address management.
The primary purpose of multi-Pod CIDR ranges is to add capacity for new Pods when the cluster's initial Pod IP address range becomes exhausted. This exhaustion can occur due to cluster scaling, high Pod density, or the use of the cluster autoscaler. By adding discontiguous secondary ranges, you can continue scaling workloads without being blocked by IP address limits, which is critical in large-scale or rapidly growing deployments.
In a VPC-native cluster, Pod IP addresses are drawn from a subnet's secondary IP address range. The multi-Pod CIDR feature lets you attach additional secondary ranges to the same cluster subnet. GKE then uses these new ranges to allocate IP addresses for Pods on nodes created in future node pools. The process does not affect existing node pools or their Pods; it only provides new IP address space for expansion. An administrator adds a new secondary range to the cluster's subnet configuration, and GKE's control plane integrates this range into its IP address management pool.
To implement multi-Pod CIDR, you must first create a new subnet secondary IPv4 address range within the cluster's VPC network, which requires the Compute Network Admin IAM role. You then assign this range to the cluster using the gcloud container clusters update command with the --add-pod-ipv4-range flag. After assignment, GKE automatically updates the cluster's firewall rules. Key decision points involve subnet binding and routing. When creating a new node pool, you can bind it to a specific Pod CIDR range for workload isolation. All Pod IP addresses from all secondary ranges are natively routable within the VPC, so you must ensure the new ranges do not overlap with any existing IP address space.
For Standard clusters, you can create node pools with a user-managed custom Pod IPv4 address range. This means you pre-create a secondary range and explicitly assign it to the node pool at creation. The lifecycle of these IP addresses is tied to the node pool; if the pool is deleted, its IP addresses become available. In contrast, cluster-wide additional ranges are managed by GKE and are available for any new node pool that does not specify a custom range.
IP address exhaustion is a primary condition this feature addresses. You can diagnose exhaustion using GKE's IP utilization insights in the Google Cloud console. If utilization approaches 100%, adding a multi-Pod CIDR range is a direct remediation path. The error IP_SPACE_EXHAUSTED in logs indicates Pod IP address range exhaustion and triggers the need for this configuration.
StudyCerts
StudyCerts34.118.224.0/20 range by default, simplifying setup./24 range (256 addresses) per node to support up to 110 Pods.A GKE-managed Service range is automatically provisioned by GKE from a Google-owned IP block (34.118.224.0/20), requiring no administrator configuration. A user-managed Service range is a secondary IP address range that you manually create in your VPC subnet and specify during cluster creation, giving you full control but also full responsibility for its management.
You should use the multi-Pod CIDR feature when your existing GKE cluster's initial Pod IP address range is nearing exhaustion, and you need to scale the cluster by adding more Pods without disrupting current workloads or recreating the entire cluster.
GKE Standard clusters allow administrators to configure the maximum Pods per node, which directly influences the size of the IP range allocated to each node (e.g., /24 for 110 Pods). GKE Autopilot clusters enforce a fixed limit of 32 Pods per node and automatically allocate a /26 range per node, offering less customization but simpler operations.
All Pod IP addresses from all secondary ranges attached to a cluster are natively routable within the VPC. You must ensure the new CIDR range does not overlap with any IP address space already used in the VPC, in on-premises networks connected via Cloud VPN or Interconnect, or in other peered cloud environments.
Prepare and test your skills
Prepare and test your skills