A VPC-native cluster is an Anthos GKE on GCP cluster that uses alias IP address ranges. Its Pod addresses are real VPC IP addresses, drawn from a subnet secondary range; Services also use a secondary range. This is the default and recommended GCP implementation, rather than a routes-based cluster. section 10.2.1
Plan three address pools:
- Node IPs come from the primary subnet range. Allow one address per node, accounting for the number of clusters and maximum nodes per cluster in a region. section 10.2.2
- Pod IPs come from a cluster Pod CIDR. The control plane divides it into equal-sized ranges assigned to nodes; size it for both node count and Pods per node. section 10.2.2
- Service IPs come from a Service CIDR. Each ClusterIP Service needs one address. section 10.2.2
Pod address allocation
With a 10.0.0.0/16 Pod CIDR and /24 ranges per node, the first node receives 10.0.0.0/24 and the second receives 10.0.1.0/24. This illustrates why the cluster-wide range must accommodate the planned node count as well as each node’s Pods. section 10.2.2
Because these addresses exist in the VPC, plan nonoverlapping allocations for clusters rather than reusing an island-mode IP scheme. Pod IPs are reserved before Pods are created, helping prevent conflicts. Automatically generated subnet routes handle Pod routing without consuming custom static-route quota. Pod ranges can have their own firewall rules and are routable to VPC resources and across connected VPC networks. section 10.2.1 section 10.2.2
For a multicluster platform, VPC-native addressing enables direct Pod-to-Pod connectivity between clusters in the same VPC. A shared-VPC deployment can place clusters across regions for redundancy; a multicluster service mesh can then discover Services and endpoints and configure sidecar routing. Address planning is therefore a deployment prerequisite, not an afterthought. section 10.3.1
