-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Gateway API: Migrate Gateway and HTTPRoute from v1beta1 to v1 #6290
Description
Summary
ExternalDNS still uses v1beta1 for Gateway and HTTPRoute Kubernetes API interactions (see source/gateway.go), despite these resources having been GA (v1) since Gateway API v1.0.0, released in October 2023 — nearly two and a half years ago.
This is a follow-up to the discussion in #4366 and PR #4610, where Gateway and HTTPRoute were reverted from v1 back to v1beta1 in July 2024. At the time, the revert was justified because GKE clusters were still shipping CRDs that only served v1beta1, and a significant portion of the user base was affected.
The situation has changed
Two years later, the landscape has fundamentally shifted:
- GKE now serves
v1Gateway API CRDs. The original blocker — GKE pinning CRDs tov1beta1— no longer applies. - Modern clusters are dropping
v1beta1. Gateway API v1.5.0 (March 2026) introduced a ValidatingAdmissionPolicy that prevents downgrades below v1.5. Clusters running current Gateway API CRDs may no longer servev1beta1at all. - ExternalDNS is now broken on modern clusters. Users report fatal crashes:
failed to sync *v1beta1.Gateway: context deadline exceeded(see Not working configuration Gateway API #4768 comments from Nov 2024 onward). This is the mirror image of the original 0.14.1 causing crash loopback related to v1.Gateway #4366 — except now it'sv1beta1that's missing rather thanv1.
In PR #4610, the de facto Gateway API maintainer for ExternalDNS noted:
"Dropping v1beta1 support and moving fully to v1 in external-dns will probably happen at some point, but it'll be at least a year from now."
That was July 2024. It has now been nearly two years, and the continued use of v1beta1 is actively breaking ExternalDNS for users on current Kubernetes clusters and Gateway API releases.
Proposed change
Migrate the Gateway and HTTPRoute API interactions in source/gateway.go (and related files) from v1beta1 to v1, consistent with what was already done for GRPCRoute (which already uses v1). Specifically:
- Change
informers_v1beta1.GatewayInformer→informers_v1.GatewayInformer - Change
informerFactory.Gateway().V1beta1().Gateways()→informerFactory.Gateway().V1().Gateways() - Update
*v1beta1.Gatewayreferences to*v1.Gateway
Since v1 Gateway and HTTPRoute have been available since Gateway API v1.0.0, this change is safe for any cluster running Gateway API 1.0 or later.
Scope and future work
This issue intentionally covers only Gateway and HTTPRoute. TLSRoute has a separate migration path (v1alpha2 → v1) that depends on Gateway API v1.5.0+, where TLSRoute was first promoted to v1. That migration is tracked in #6247 and should be addressed as a follow-up once the ecosystem has had time to adopt v1.5.x.
Related issues
- 0.14.1 causing crash loopback related to v1.Gateway #4366 — Original v1.Gateway crash (2024), caused by GKE not yet serving v1
- Gateway API: Revert Gateway and HTTPRoute objects from v1 to v1beta1 #4610 — PR that reverted Gateway/HTTPRoute from v1 to v1beta1
- TLSRoute v1 in v1.5.0 Gateway API #6247 — TLSRoute v1alpha2 → v1 migration (separate, future step)
- Not working configuration Gateway API #4768 — Users reporting v1beta1.Gateway sync failures on modern clusters