/kind feature
/kind api-change
Describe the solution you'd like
When provisioning VPC-native GKE clusters (useIPAliases: true), it is common to pre-allocate named secondary IP ranges on a subnet and share that subnet across multiple clusters. The GCP API exposes clusterSecondaryRangeName and servicesSecondaryRangeName on IPAllocationPolicy for exactly this purpose, but GCPManagedControlPlane currently only supports specifying pod and service ranges by CIDR block (cidrBlock), not by range name.
The proposed addition is two optional fields on the existing ClusterNetworkPod and ClusterNetworkService structs:
spec:
clusterNetwork:
useIPAliases: true
pod:
secondaryRangeName: pods-range
service:
secondaryRangeName: services-range
Both fields would be immutable after cluster creation (matching GCP API behaviour) and require useIPAliases: true.
Anything else you would like to add:
I've had a go at a PR to support this, but appreciate it's my first time contributing. I'll link it when I raise the PR!
/kind feature
/kind api-change
Describe the solution you'd like
When provisioning VPC-native GKE clusters (
useIPAliases: true), it is common to pre-allocate named secondary IP ranges on a subnet and share that subnet across multiple clusters. The GCP API exposesclusterSecondaryRangeNameandservicesSecondaryRangeNameon IPAllocationPolicyfor exactly this purpose, butGCPManagedControlPlanecurrently only supports specifying pod and service ranges by CIDR block (cidrBlock), not by range name.The proposed addition is two optional fields on the existing ClusterNetworkPod and ClusterNetworkService structs:
Both fields would be immutable after cluster creation (matching GCP API behaviour) and require useIPAliases: true.
Anything else you would like to add:
I've had a go at a PR to support this, but appreciate it's my first time contributing. I'll link it when I raise the PR!