RFE: dual-stack on GCP — support converting an existing IPv4 cluster to dual-stack (day-2) and installing dual-stack; IPv6 east-west is a sufficient first scope #3188

Is your feature request related to a problem? Please describe.

Self-managed OpenShift/OKD on GCP cannot use IPv6 pod and Service networks, while GKE on the same cloud provides them natively. For an estate that standardizes on IPv6 service addresses, the self-managed GCP cluster is permanently the odd one out.

We specifically need to bring an existing, running IPv4 cluster to dual-stack without reinstalling it.

Two blockers, both source-verified on release-4.22 (and the day-2 one observed live):

1. Install-time — the installer's networking validation rejects dual-stack clusterNetwork/serviceNetwork entries for GCP (validateNetworkingIPVersion falls into the default: arm: "dual-stack IPv4/IPv6 is not supported for this platform"). We hit this during a 5.0.0-okd-scos.1 reinstall attempt — the dual-stack install-config was abandoned for a v4-only config at that point (the settled decision is recorded in the session notes; the verbatim error line was not retained, but the source behavior is verified at the pinned release-4.22 commit below).

2. Day-2 conversion — verified live on 4.22.0-okd-scos.6: patching network.config/cluster to add fd01::/48 (pods) + fd02::/112 (services) is accepted by the API, then:

   $ oc get co network
     Degraded: True — "The cluster configuration is invalid (GCP is not one of the supported platforms for dual stack)"
   

   Reverting the patch restores Available/Degraded=False. CNO's isSupportedDualStackPlatform allows BareMetal/None/vSphere/OpenStack/Kubevirt unconditionally, AWS and Azure behind their feature gates; GCP has no gate. isConversionToDualStackSupported (day-2) is narrower still (BareMetal/None/vSphere only).

Describe the solution you'd like

A supported path to convert an existing GCP IPv4 cluster to dual-stack, mirroring the AWS/Azure feature-gate mechanism for both install and day-2 conversion.

If full platform dual-stack (v6 load balancers, v6 node addresses in platform controllers) is the expensive part, a scoped first step is already valuable:

• Overlay/east-west dual-stack — dual-stack pod/service families with working IPv6 east-west traffic over the existing IPv4 underlay, with IPv4-only north-south and ingress retained.

We can satisfy host-side prerequisites: our GCP subnets are already stackType: IPV4_IPV6, GCP supports enabling IPv6 on existing VM NICs in place, and we are prepared to configure dual-stack host networking on the nodes.

Related limitation (verified, filed separately against the machine provider)

machine-api-provider-gcp cannot express dual-stack NICs: the provider spec's network interface schema has no stack-type/IPv6 fields, and instance creation sets only AccessConfigs/Network/Subnetwork. Newly provisioned machines always come up IPv4-only, so dual-stack hosts would not survive scale-out, repair, or control-plane replacement without provider support. See the linked provider issue.

Questions for maintainers

• Is in-place conversion of an existing GCP cluster an intended or feasible future path? If not, what should GCP users do now to avoid a forced reinstall later?
• Beyond CNO's eligibility checks, which components are known to need work for GCP dual-stack (OVN gateway on GCP, cloud controller, kube-apiserver service-CIDR propagation)?
• Is an overlay-only (east-west) scope acceptable as a first increment, deferring v6 load balancers?

Additional context

• Day-2 rejection observed on OKD 4.22.0-okd-scos.6; CNO source at the shipped revision contains the two platform checks quoted above.
• GKE on the same project provides dual-stack natively, so the GCP-side primitives exist.