change process GVK for TLSRoute/BackendTLSPolicy

[zirain]

fixes: #7522

related to: #7090

For TLSRoute, use v1alpha2.
For BackendTLSPolicy, use v1alpha3.

The goal is make EG v1.6+ work with Gateway API v1.3 this's important during the upgrade.

Fixes: #7709

[codecov]

Codecov Report

❌ Patch coverage is 61.72840% with 31 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.77%. Comparing base (fba4f46) to head (1e08257).
⚠️ Report is 115 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/provider/kubernetes/status.go	0.00%	10 Missing ⚠️
internal/provider/kubernetes/status_updater.go	18.18%	8 Missing and 1 partial ⚠️
internal/provider/kubernetes/indexers.go	30.00%	2 Missing and 5 partials ⚠️
internal/cmd/egctl/status.go	0.00%	2 Missing ⚠️
internal/provider/kubernetes/controller.go	88.23%	0 Missing and 2 partials ⚠️
internal/provider/kubernetes/predicates.go	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7523      +/-   ##
==========================================
- Coverage   72.82%   72.77%   -0.06%     
==========================================
  Files         235      235              
  Lines       35176    35185       +9     
==========================================
- Hits        25618    25605      -13     
- Misses       7744     7762      +18     
- Partials     1814     1818       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zhaohuabing]

Thanks @zirain for fixing this. Could this happen again next time when we upgrade Gateway API? Is there anything that we can do to prevent it in the future-and upgrade test?

[zirain]

wait kubernetes-sigs/gateway-api#4242

[zirain]

Thanks @zirain for fixing this. Could this happen again next time when we upgrade Gateway API? Is there anything that we can do to prevent it in the future-and upgrade test?

we should be careful with the verions that EG supported.

[zirain]

we didn't need this ATM.

[zhaohuabing]

Hi @zirain, this is needed for #7709. Hope you don’t mind—I reopened this PR and pushed a few commits to sync with main and fix the tests. Really appreciate all the work you’ve done on this PR. Thanks!

[arkodg]

so this issue is because the user didnt update CRDs ? and this section is missing ?

spec:
  versions:
  - name: v1alpha1
    served: true
    storage: false
  - name: v1
    served: true
    storage: true

and should we enforce that v1.6 CRDs be applied before v1.7 upgrade ?

[zhaohuabing]

so this issue is because the user didnt update CRDs ? and this section is missing ?

The reason is that the user didn't update CRDs - BackendTLSPolicy in the cluster is v1alpha3, and EG v1.6 only watches v1. So the BackendTLSPolicies are not reconciled by EG.

we enforce that v1.6 CRDs be applied before v1.7 upgrade ?

I think it’s reasonable for EG to stay compatible with the previous Gateway API version to ensure a smooth upgrade, but we don’t necessarily need to keep compatibility with versions before that. We can make this explicit in the compatibility matrix and upgrade sections in the docs.

[lboynton]

Could this be added in to 1.6.x soon? Currently we are unable to upgrade from 1.5.x to 1.6.x because we use BackendTLSPolicy resources, which stop working (see #7709) when upgrading. EGW 1.5.x is not forward compatible with GW API CRDs v1.4 and 1.6.x is not backward compatible with GW API CRDs v1.3, so there's no way to upgrade without some downtime.

[zhaohuabing]

Hi @lboynton will upgrading CRD first solve your case?

For the v1.3.0 experimental to v1.4.1 standard channel upgrade path, I don't think this PR will help, as it will only watch the old v1alpha3.

If we want EG to work with v1.4.1 standard channel, this PR shouldn't be merged.

  - deprecated: true
    deprecationWarning: The v1alpha3 version of BackendTLSPolicy has been deprecated
      and will be removed in a future release of the API. Please upgrade to v1.
    name: v1alpha3
    served: false
    storage: false
    subresources:
      status: {}

[lboynton]

OK sorry, I don't think this is needed (at least for my case). I misunderstood the problem, it was actually a fix in envoy gateway v1.5.x I needed to make that version compatible with GW API CRDs v1.4.x before completing the upgrade to envoy gateway v1.6.x. See my comment on #7709.

[zhaohuabing]

Discussed in today’s community meeting: the decision is to continue watching the v1 version of BackendTLSPolicy, so Envoy Gateway v1.6 can work with the Gateway API v1.4.1 standard channel.

For users upgrading from v1.5.x to v1.6.x, the recommended upgrade order is:
1. Upgrade the Gateway API CRDs first.
2. Then upgrade Envoy Gateway.

We should also add e2e tests for rollback scenarios—for example, verifying that EG v1.5.x works correctly with Gateway API v1.4.1.