VPC Network Peering connects separate VPCs so services can communicate across an administrative boundary without an IPsec VPN. It offers the data-plane and performance characteristics of a single VPC while each VPC retains its own security configuration. In a single-cloud deployment, it can connect services on Anthos GKE to resources hosted in another VPC. section 10.1.1
Plan the connection with both VPC administrators:
- Assign nonoverlapping IP address space. Peering does not permit overlapping addresses. section 10.1.1
- Maintain firewall rules on both sides that allow the required traffic between the VPCs' subnets. section 10.1.1
- Check which routes are exported and imported. RFC1918 addresses are exported by default in the described consumer–producer arrangement, but privately used public IP (PUPI) Pod addresses are not automatically advertised to peers. section 10.2.2
Peering GKE consumer and producer VPCs
Suppose a consumer GKE cluster uses 5.0.0.0/8 for Pod addresses and a producer cluster uses 45.0.0.0/8. For consumer Pods to reach the producer VPC, configure the consumer to export its PUPI routes and the producer to import them. Coordinate nonoverlapping Pod, node, and internal load balancer (ILB) addresses. Resources commonly reach producer services through producer ILB addresses. If producer Pods must initiate direct communication back, export producer PUPI routes and import them on the consumer side; if the consumer already uses those addresses, use IP masquerade to hide producer Pod addresses behind producer node addresses instead. section 10.2.2
Choose the connectivity method to match the deployment. IPsec VPN carries encrypted traffic over the public internet but may degrade performance. When only a few services need cross-VPC access and network-level peering or VPN is unsuitable, public ingress with TLS or mTLS is another option, at the cost of per-service configuration. section 10.1.1
