Designing and allocating IP subnets for a private Google Kubernetes Engine (GKE) cluster involves planning distinct, non-overlapping IP address ranges for the cluster's worker nodes, Pods, Services, and the control plane. In a VPC-native cluster, these addresses come from the Virtual Private Cloud (VPC) network's subnets, ensuring all components can communicate directly without conflicting with other connected networks like on-premises systems.
VPC-native networking directly assigns IP addresses from VPC subnet ranges to GKE components using an alias IP architecture. The primary IP address range of a chosen VPC subnet supplies addresses for the cluster's worker nodes and internal load balancers. Pods receive their IP addresses from a secondary subnet range configured as alias IPs on their node's network interface. Kubernetes Services, like ClusterIPs, get virtual IP addresses from a separate secondary subnet range. This design makes Pod IPs directly routable within the VPC, allowing seamless communication with other Google Cloud resources without needing extra routing rules, which conserves VPC route limits and scales efficiently.
A private GKE cluster's control plane runs in a Google-managed project and requires a dedicated /28 master IPv4 CIDR block. This small subnet provides 16 IP addresses reserved exclusively for the control plane's internal instances. You must select an unused private IP range (like RFC 1918 space) that does not overlap with any existing subnets in your VPC or any networks connected via peering or VPN. Although GKE checks for overlaps in a standalone VPC, in a Shared VPC you must manually coordinate with network administrators to ensure this /28 range is unique across all interconnected environments.
Pod CIDR planning determines how many Pods each node can host and impacts the cluster's overall scaling capacity. By default, GKE assigns a /24 range (256 addresses) per node, supporting up to 110 Pods. You can configure a larger /23 range per node for high-density workloads needing up to 256 Pods, or a smaller /26 range per node for Autopilot clusters or to conserve IP space. When sizing your subnets, you must account for future growth from the cluster autoscaler and node upgrades. If you expand a subnet after cluster creation, you must update the master authorized networks list to include the new range so new nodes can register with the control plane.
The IP masquerade agent on GKE nodes manages Source Network Address Translation (SNAT) for Pod traffic leaving the cluster. By default, it only masquerades (hides) a Pod's source IP for traffic destined to public internet addresses, changing it to the node's primary IP. Traffic to internal RFC 1918 destinations keeps the original Pod IP. If you use privately used public IP (PUPI) addresses for your Pod CIDR blocks to conserve private IP space, you must add these PUPI ranges to the agent's nonMasqueradeCIDRs configuration. This prevents SNAT on internal traffic, preserving end-to-end Pod IP visibility and preventing routing failures.
Preventing routing collisions requires ensuring the IP ranges used for GKE nodes, Pods, Services, and the control plane do not overlap with any ranges in peered VPCs, Cloud VPN/Interconnect links, or on-premises networks. Since VPC-native Pod and node IPs are natively routable, overlapping CIDRs advertised over BGP will corrupt routing tables and drop packets. To minimize conflicts, use dedicated subnets for internal load balancers instead of consuming addresses from the node subnet. When integrating across hybrid links, use Cloud Router custom route advertisements to selectively advertise only necessary subnets (like node ranges and load balancer VIPs) to on-premises networks.
Resolving transitive and hybrid routing involves designing paths so clients in peered VPCs or on-premises networks can reach a private GKE cluster's control plane, despite the non-transitive nature of VPC Network Peering. This typically requires deploying proxy solutions or configuring custom route advertisements to bridge the network boundaries.
VPC Network Peering is non-transitive, meaning traffic cannot flow "through" one peered connection to reach another. For example, if a GKE cluster's control plane is peered to a hub VPC, a spoke VPC also peered to that hub cannot automatically route traffic to the control plane. The peering relationship between the hub and the control plane does not extend transitively to the spoke, creating a broken path that requires a workaround.
To enable access from a peered VPC or on-premises network, you can deploy a network proxy, like a bastion host or an internal TCP/UDP load balancer, within an authorized network subnet in the same VPC as the GKE cluster. Clients send their traffic to the proxy's IP address, which is routable from their network. The proxy then forwards the traffic to the cluster's private control plane endpoint. This two-hop path circumvents the peering non-transitivity limitation.
For hybrid access from on-premises networks connected via Cloud VPN or Cloud Interconnect, you can use Cloud Router custom route advertisements. You manually configure the Cloud Router to advertise the specific IP range of the GKE cluster's private control plane endpoint to your on-premises routers over BGP. This makes the control plane's IP address directly routable from on-premises, allowing traffic to flow over the hybrid connection without needing a proxy, assuming firewall rules permit it.
Choose a proxy solution when the source network is another peered VPC where direct routing is impossible due to non-transitive peering. Choose custom route advertisements when the source is an on-premises network connected via VPN or Interconnect, as this provides a direct and simpler routing path. In complex architectures with both peered VPCs and hybrid connections, you may need to implement both methods.
Configuring master endpoint access modes determines how the Kubernetes API server is reachable and from which networks. You can choose to disable the public external endpoint entirely for maximum isolation, or enable it while restricting access to specific IP ranges via authorized networks. This balances security with operational needs for cluster management.
Private Service Connect (PSC) provides private connectivity to the GKE control plane without using the public internet. When enabled, Google Cloud assigns an internal IP address in your VPC that forwards requests to the cluster's management API. A service attachment resource creates a secure connection between your VPC and Google's producer network. PSC supports scaling to many more clusters (up to 1000) compared to using VPC Network Peering (75 per zone/region).
You have three primary configuration options for endpoint access: DNS-based only, IP-based only, or both combined. With DNS-based access, you control authorization using IAM policies. With IP-based access, you can enable both external and internal endpoints, or disable the external endpoint to allow access only from Google's management IPs and internal cluster IPs. Google recommends using authorized networks with IP-based access to restrict which external CIDR ranges can reach the control plane.
Authorized networks let you whitelist specific CIDR ranges (like corporate network IPs or VPN endpoints) that are permitted to access the control plane's API server, adding a network-layer security filter. Note that if you use Cloud Shell for management, its external IP can change, requiring updates to your authorized networks list. VPC firewall rules provide additional Layer 4 control, allowing you to restrict traffic to and from your GKE nodes based on service accounts or network tags attached to node pools.
GKE supports mixed-mode clusters where different node pools can have different accessibility settings. You can create private node pools (nodes with only internal IPs) or public node pools (nodes with external IPs). In Standard clusters, you configure this at the node pool level. In Autopilot clusters, you control it at the workload level by using a nodeSelector in your Pod specification (e.g., cloud.google.com/private-node=true to schedule Pods on private nodes). Node pool or workload-level network settings can override the cluster-level configuration.
In VPC-native networking, Pod IP addresses are allocated from secondary alias IP ranges on the VPC subnet and are directly routable within the VPC. In the older routes-based networking, GKE creates a custom static route in the VPC for each node's Pod CIDR, which consumes route table quotas and doesn't scale as well.
Use a proxy (like a bastion or internal load balancer) when the client is in a VPC peered to your cluster's VPC, because VPC peering is non-transitive and direct routing is impossible. Use custom route advertisements on Cloud Router when the client is in an on-premises network connected via Cloud VPN or Interconnect, as this creates a direct, efficient routing path.
If you assign a Privately Used Public IP (PUPI) range to your Pods, you must add that CIDR block to the nonMasqueradeCIDRs list in the IP masquerade agent's configuration. This tells the agent not to perform Source NAT on traffic destined for those IPs, preserving the original Pod source IP for correct routing within your internal network.
Yes, GKE supports mixed-mode clusters. In Standard clusters, you configure this at the node pool level by checking or unchecking "Enable private nodes." In Autopilot clusters, you control it at the workload level by using a nodeSelector in your Pod specification to target nodes with the desired accessibility (cloud.google.com/private-node=true or false).
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts