gateway: three charts render TLSRoute at the deprecated v1alpha2 #3873

Three first-party charts render their TLSRoute objects at gateway.networking.k8s.io/v1alpha2, a version the shipped CRD bundle marks deprecated. v1 has been the storage version for TLSRoute since Gateway API v1.5.0, which is the bundle this repository already vendors.

Sites

• packages/system/cozystack-api/templates/api-tlsroute.yaml:6
• packages/system/kubevirt/templates/vm-exportproxy-tlsroute.yaml:6
• packages/system/kubevirt-cdi/templates/cdi-uploadproxy-tlsroute.yaml:6

A fourth match, packages/system/openbao/charts/openbao/templates/server-tlsroute.yaml, is inside a vendored subchart and is upstream's to change, not this repository's.

Mechanism

The bundle in packages/system/gateway-api-crds serves tlsroutes at v1 (storage), v1alpha2 and v1alpha3, with both alpha versions carrying deprecated: true and a deprecation warning naming v1 as the upgrade target. That is true of the v1.5.1 bundle vendored today and of v1.6.1, so this is not something a bundle bump introduces or changes.

Writing a deprecated version is not an error: the apiserver converts, stores at the storage version, and the object behaves identically. What it costs is a deprecation warning on every apply and a dependency on a version that upstream has said it will remove.

Impact

Nothing is broken and nothing degrades while v1alpha2 is served. The failure is deferred and sharp when it arrives: on the bundle release that stops serving v1alpha2, every one of these templates fails to apply, and the failure lands during an upgrade rather than during a change to these charts. By then the connection between the upgrade and three unrelated-looking charts is not obvious.

The same class already bit the hostname policy, which named only v1alpha2 for tlsroutes — see #3789.

Fix shape

Change the three apiVersion lines to gateway.networking.k8s.io/v1 and confirm each chart still renders and its unit tests pass. The object schema for TLSRoute is the same across the served versions here, so this is a version bump rather than a migration.

Worth pairing with a check that keeps it from recurring: hack/route-hostname-policy-version-coverage.bats already reads served versions out of the vendored bundle to verify a policy covers them. The same reading could assert that no first-party template writes a version the bundle marks deprecated, which turns the next deprecation into a red test instead of a future upgrade failure.