GKE Networking - Subnet Allocation Q&A

A: This is the recommended best practice.

Result: Both clusters operate independently within the same network.
Profits: * Native Routing: Pods in Cluster 1 can reach Pods in Cluster 2 using internal IPs without any extra configuration.
Security: You can apply VPC Firewall Rules to one subnet without affecting the other.
Scalability: Each cluster has its own dedicated “pool” of IPs for Nodes, Pods, and Services.
Issues: Requires more total IP address space from your VPC.

A: This is possible but requires careful configuration of secondary ranges.

Result: Both clusters share the same Primary Range (for Nodes), but they must use different Secondary Ranges for Pods and Services.
Profits: Simplified management of shared infrastructure (e.g., a single NAT gateway or one set of common firewall rules).
Issues: * Complexity: You must manually ensure that the secondary ranges for Cluster 2 do not overlap with Cluster 1.
IP Exhaustion: If the primary subnet runs out of IPs, neither cluster can add new nodes.
Blast Radius: A networking issue or misconfiguration in that one subnet could impact both clusters simultaneously.

A: This is not possible in Google Cloud.

Result: The Google Cloud API will return an error and block the creation of the subnet.
Profits: None, as the configuration is invalid.
Issues: * Overlapping CIDRs: VPCs require all subnet ranges to be unique and non-overlapping.
Routing Logic: Cloud Router cannot determine whether traffic intended for an IP should go to the “parent” subnet or the “child” subnet, creating a routing conflict.

Scenario	Status	Recommendation	Key Benefit
Separate Subnets	✅ Supported	Best Practice	High isolation & easy routing.
Shared Subnet	⚠️ Supported	Use for small clusters	Consolidates node management.
Nested Subnet	❌ Forbidden	Do not attempt	N/A

Constellates