The GKE control plane exposes two types of endpoints for cluster access: a DNS-based endpoint that resolves based on network reachability to Google Cloud APIs, and IP-based endpoints that can be public or private. The DNS-based endpoint provides simplified configuration and a flexible, policy-based security layer, accessible from any network reachable by Google Cloud APIs including on-premises or other cloud networks. To enable the DNS-based endpoint, use the --enable-dns-access flag when creating a cluster. The IP-based endpoints can be configured as private using the --enable-private-endpoint flag, which places the control plane on a private IP address within your VPC network.
Authorized networks allow you to restrict access to the GKE control plane by specifying which IP address subnets can connect. After enabling authorized networks, you can define specific source IP address ranges that are permitted to access the control plane. If the public endpoint is disabled, these source IP ranges should be private; if the public endpoint is enabled, you can allow both public and internal IP address ranges. You can make the private GKE API endpoint globally reachable across regions by using the --enable-master-global-access option when creating a cluster. Note that even if you disable access to the public endpoint, Google still uses the control plane's public endpoint for cluster management purposes such as scheduled maintenance and automatic upgrades.
Private clusters minimize node exposure by creating nodes without external IP addresses, isolating Pods from inbound and outbound communication at the cluster perimeter. You control these directional flows by exposing services through load balancing and Cloud NAT. In private clusters, the control plane resides within a Google-managed tenant project and uses its own internal IP address range, connecting to your VPC network through Private Service Connect. When using Private Service Connect for cluster creation, the primary subnet range provisions the internal IP address assigned to the control plane endpoint, though you can override this using the --private-endpoint-subnetwork flag.
Firewall rules control traffic between the control plane and worker nodes. Certain system Pods on every worker node must reach services such as the Kubernetes API server, Google APIs, or the metadata server, and the API server must communicate with system Pods like event-exporter. GKE creates required firewall rules by default, but if you deploy custom VPC firewall rules, you must ensure those Pods can continue communicating with the API server and Google APIs. If you expand the primary IP range of a subnet used by a cluster with authorized networks, you must add the expanded IP address range to the control plane authorized networks list; otherwise, new nodes created in the expanded IP address space cannot register with the control plane, leading to outages during node pool upgrades or liveness probe failures.
VPC Network Peering limitations require special consideration: if your cluster uses VPC Network Peering, you cannot directly access the cluster's control plane from another peered network. To enable direct access from another peered network or from on-premises in a hub-and-spoke architecture, you must deploy proxies for control plane traffic. This is because VPC Network Peering does not allow cross-network communication to the control plane endpoint.
A VPC-native cluster—the default and recommended networking mode for GKE—uses three distinct IP address ranges from its subnet. Nodes receive internal IP addresses from the subnet's primary IP address range. Pods receive unique IP addresses from one or more subnet secondary IP address ranges dedicated to Pods. Services (like ClusterIP) receive virtual IP addresses from a separate subnet secondary range or, in newer clusters, from a Google-managed range (34.118.224.0/20 for IPv4). The size of each range directly limits the potential scale of the corresponding cluster component.
The maximum number of nodes is constrained by the primary IP address range of the subnet. GKE uses this range to assign one IP address per node. The formula to calculate the maximum usable nodes (N) from a primary range with a netmask size of /S is N = 2^(32 - S) - 4. The subtraction of 4 accounts for IP addresses Google Cloud reserves in every subnet. For example, a /22 primary range provides 2^(10) = 1024 total addresses. After reserving 4, 1020 addresses remain, supporting a maximum of 1020 nodes. If the cluster uses Private Service Connect (PSC) for the control plane and does not override the endpoint subnet, one additional IP from this range is consumed, reducing the maximum nodes by one.
The maximum number of Pods is constrained by the secondary IP address range allocated for Pods and the configured maximum Pods per node (Q). GKE allocates a fixed-size alias IP range to each node from the Pod secondary range. By default, a /24 range (256 addresses) is allocated per node, supporting up to 110 Pods. The total Pod secondary range must be large enough to provide one of these node ranges for every node.
The calculation involves several steps:
StudyCerts
StudyCertsHD), where HD = 32 - DS and DS is the CIDR block size (e.g., /17).HM), where HM = 32 - M and M is the netmask size calculated as 31 - ⌈log₂(Q)⌉.MN) the Pod range can support: MN = 2^(HD - HM).MP): MP = MN * Q.For example, an Autopilot cluster (fixed Q = 32) with a Pod secondary range of /17 (DS = 17) can be calculated. Here, HD = 15. With Q = 32, M = 31 - ⌈log₂(32)⌉ = 31 - 5 = 26, so HM = 6. Then MN = 2^(15 - 6) = 512 nodes, and MP = 512 * 32 = 16,384 Pods. The final maximum is the lower of the results from the primary node range calculation and this Pod range calculation.
To scale beyond the limits of initially allocated ranges, you can expand the primary IP address range of a subnet or add more Pod IP address ranges using discontiguous multi-Pod CIDR. Reducing the maximum Pods per node (Q) allows a fixed Pod secondary range to support more nodes, conserving IP address space for horizontal scaling. Conversely, increasing Q up to 256 allows more vertical density but consumes the Pod range faster, limiting the total node count. Choosing between these options involves a tradeoff between node count and Pod density based on workload characteristics. Over-provisioning ranges can waste scarce IP address space, while under-provisioning blocks cluster growth, making accurate initial calculation and planning essential.
A VPC-native cluster uses alias IP address ranges to assign natively routable VPC IP addresses directly to Pods. This architecture eliminates the need for static route entries for each node, which prevents the cluster from exhausting Google Cloud VPC routing quotas. VPC-native networking is mandatory for clusters deployed in a Shared VPC, clusters using VPC Network Peering, and all clusters created in Autopilot mode. In a Shared VPC model, a network administrator defines and manages the host project subnets and secondary ranges, while platform operators provision GKE clusters within service projects using those shared subnets.
The primary IPv4 address range of a subnet provides IP addresses for GKE worker nodes and internal load balancers. Google Cloud reserves four IP addresses in every primary subnet range, specifically the first two and the last two addresses. For a cluster using the default subnet, the maximum number of supportable nodes ($N$) based on the subnet mask prefix ($S$) is calculated using the formula $N = 2^{(32 - S)} - 4$. For example, a /24 primary range yields 256 total addresses, providing 252 usable addresses for nodes.
When using Private Service Connect (PSC) without the --private-endpoint-subnetwork flag, the control plane endpoint consumes an additional address from the primary subnet, reducing available node capacity by one ($N = 2^{(32 - S)} - 5$). A primary subnet range can range in size from a minimum of /29 (supporting up to 4 nodes) to a maximum of /8. While administrators cannot shrink a primary subnet range after creation, they can expand the primary IPv4 range dynamically. If an administrator expands a primary subnet associated with a cluster that uses control plane authorized networks, they must update the authorized networks configuration with the expanded range to prevent node registration failures.
Pod IP addresses originate from a dedicated secondary IPv4 subnet range and are assigned to nodes in CIDR blocks to accommodate multi-Pod density. In standard GKE clusters, the system assigns a /24 CIDR block (256 addresses) to each node by default, which supports up to 110 Pods per node. Autopilot clusters assign a fixed /26 CIDR block (64 addresses) per node, which supports a non-configurable limit of 32 Pods per node. To optimize address allocation when nodes run fewer workloads, administrators can configure a smaller maximum Pod density per node (such as 64, 32, or 16 Pods) during node pool creation.
Calculating the maximum number of supportable nodes and Pods within a secondary range relies on the selected Pod subnet mask and the configured Pod density:
A default /14 secondary Pod range contains 262,144 addresses ($2^{18}$), which divides into 1,024 /24 chunks to support 1,024 nodes and up to 112,640 Pods at default density. If a cluster approaches exhaustion in its secondary Pod range, administrators can add new, non-overlapping secondary ranges using discontiguous multi-Pod CIDR to allocate to new node pools without rebuilding the cluster.
Kubernetes Services of type ClusterIP receive stable virtual IP addresses allocated from a dedicated secondary IPv4 range. In GKE Autopilot clusters (version 1.27 and later) and GKE Standard clusters (version 1.29 and later), GKE automatically assigns Service IP addresses from a Google-managed private range, 34.118.224.0/20, which provides 4,096 Service addresses without consuming custom VPC subnet space. For clusters where administrators supply a custom secondary range, the default size is /20, and this range cannot be modified, expanded, or shrunk after cluster creation.
To conserve internal IPv4 address space, administrators can share secondary Service ranges across multiple clusters, provided that VPC-scope Cloud DNS for GKE is not enabled. In addition, internal passthrough Network Load Balancers support IP address sharing, allowing up to 50 backend Services on distinct ports to utilize a single internal virtual IP (VIP). When provisioning internal load balancers, deploying a dedicated proxy-only or internal load balancer subnet prevents Service endpoints from consuming primary IP addresses allocated for cluster worker nodes.
When RFC 1918 private address space is exhausted, GKE clusters can allocate Pod and Service ranges from non-RFC 1918 ranges or privately used public IP (PUPI) addresses. Non-RFC 1918 options include the RFC 6598 shared address space (100.64.0.0/10) and Class E / RFC 5735 space (240.0.0.0/4), though Class E addresses can face interoperability issues on certain physical network hardware or Windows hosts. When public IPv4 ranges are used internally as PUPI, the addresses must be assigned exclusively to secondary Pod ranges rather than primary node subnets.
Because Kubernetes treats non-RFC 1918 addresses as public IPs, worker nodes apply source network address translation (SNAT) to outbound traffic by default. To maintain direct Pod-to-Pod and Pod-to-Service connectivity without translation across internal destinations, administrators must disable default SNAT or deploy an IP masquerade agent (ip-masq-agent) configured with the cluster Pod CIDRs in the nonMasqueradeCIDRs list. When connecting VPC networks via VPC Network Peering, PUPI subnet routes are not exported by default, requiring the peering configuration to explicitly manage route exchange to maintain connectivity across peered boundaries.
In private GKE clusters, the Kubernetes control plane runs inside a Google-managed tenant project and requires a /28 RFC 1918 CIDR block. This /28 range provides 16 IP addresses for control plane instances and internal load balancers, and it must not overlap with any subnet CIDR in the cluster VPC or connected on-premises networks. The tenant VPC connects to the customer VPC through Private Service Connect or VPC Network Peering, allowing bidirectional communication between worker nodes and the kube-apiserver.
Network access to the control plane is secured using control plane authorized networks, which permit administrative API requests exclusively from designated public or private CIDR blocks. When clusters use VPC Network Peering to connect to the control plane, transitive routing restrictions prevent workloads in peered networks from accessing the private control plane endpoint directly without proxy instances or Private Service Connect. Administrators can also deploy DNS-based control plane endpoints to enforce dynamic identity and access policies through Identity and Access Management (IAM) without relying strictly on static source IP whitelisting.
A DNS-based endpoint resolves based on network reachability to Google Cloud APIs and provides a flexible, policy-based security layer without requiring static IP whitelisting. An IP-based endpoint can be public or private; a private endpoint places the control plane on a private IP address within your VPC and is often used with authorized networks to restrict access.
The maximum usable nodes (N) from a primary range with netmask size /S is N = 2^(32 - S) - 4, because Google Cloud reserves four IP addresses in every subnet. If the cluster uses Private Service Connect for the control plane without overriding the endpoint subnet, subtract one more address from the total.
Use discontiguous multi-Pod CIDR when a cluster is approaching exhaustion of its secondary Pod IP range. It allows you to add new, non-overlapping secondary ranges to allocate to new node pools without rebuilding the cluster, extending the cluster's Pod capacity.
Yes, you can share a secondary Service range across multiple clusters, but only if VPC-scope Cloud DNS for GKE is not enabled. Sharing helps conserve internal IPv4 address space.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills