chore(deps): bump sigs.k8s.io/gateway-api from 0.8.0-rc1 to 0.8.0

[dependabot]

Bumps sigs.k8s.io/gateway-api from 0.8.0-rc1 to 0.8.0.

Release notes

Sourced from sigs.k8s.io/gateway-api's releases.

v0.8.0

Major Themes

GAMMA (Service Mesh)

Service mesh support per the GAMMA initiative has moved to experimental in v0.8.0. As an experimental API, it is still possible that this will change; the working group does not recommend shipping products based on any experimental API.

When using the Gateway API to configure a service mesh, the Gateway and GatewayClass resources are not used (as there will typically only be one mesh in the cluster) and, instead, individual route resources are associated directly with Service resources. This permits configuring mesh routing while preserving the Gateway API's overall semantics.

We encourage service mesh implementers and users to try this new support and we welcome feedback! Once again, though, the working group does not recommend shipping products based on this or any other experimental API. due to the possibility of incompatible changes prior to the final release.

CEL Validation

This release marks the beginning of a transition from webhook validation to CEL validation that is built into the CRDs. That will mean different things depending on the version of Kubernetes you're using:

Kubernetes 1.25+

CEL validation is fully supported. Most validation is now covered by the validating webhook, but unfortunately not quite everything.

All but one validation has been translated from the webhook to CEL. Currently the CRDs only have a case-sensitive uniqueness check for header names in header modifier filters. The webhook validation is more thorough, ensuring that the uniqueness is case-insensitive. Unfortunately that is not possible to represent with CEL today. There is more information in #2277.

Installing the validating webhook is still recommended for this release to allow controllers to catch up to cover this gap in CEL validation. We expect this is the last release we will make this recommendation for, for more information, refer to #2319.

Kubernetes 1.23 and 1.24

CEL validation is not supported, but Gateway API v0.8.0 CRDs can still be installed. When you upgrade to Kubernetes 1.25+, the validation included in these CRDs will automatically take effect. We recommend continuing to install the validating webhook on these Kubernetes versions.

Kubernetes 1.22 and older

Unfortunately Gateway API v0.8.0 is not supported on these Kubernetes versions.

... (truncated)

Changelog

Sourced from sigs.k8s.io/gateway-api's changelog.

v0.8.0

Major Themes

GAMMA (Service Mesh)

Service mesh support per the GAMMA initiative has moved to experimental in v0.8.0. As an experimental API, it is still possible that this will change; the working group does not recommend shipping products based on any experimental API.

When using the Gateway API to configure a service mesh, the Gateway and GatewayClass resources are not used (as there will typically only be one mesh in the cluster) and, instead, individual route resources are associated directly with Service resources. This permits configuring mesh routing while preserving the Gateway API's overall semantics.

We encourage service mesh implementers and users to try this new support and we welcome feedback! Once again, though, the working group does not recommend shipping products based on this or any other experimental API. due to the possibility of incompatible changes prior to the final release.

CEL Validation

This release marks the beginning of a transition from webhook validation to CEL validation that is built into the CRDs. That will mean different things depending on the version of Kubernetes you're using:

Kubernetes 1.25+

CEL validation is fully supported. Most validation is now covered by the validating webhook, but unfortunately not quite everything.

All but one validation has been translated from the webhook to CEL. Currently the CRDs only have a case-sensitive uniqueness check for header names in header modifier filters. The webhook validation is more thorough, ensuring that the uniqueness is case-insensitive. Unfortunately that is not possible to represent with CEL today. There is more information in #2277.

Installing the validating webhook is still recommended for this release to allow controllers to catch up to cover this gap in CEL validation. We expect this is the last release we will make this recommendation for, for more information, refer to #2319.

Kubernetes 1.23 and 1.24

CEL validation is not supported, but Gateway API v0.8.0 CRDs can still be installed. When you upgrade to Kubernetes 1.25+, the validation included in these CRDs will automatically take effect. We recommend continuing to install the validating webhook on these Kubernetes versions.

Kubernetes 1.22 and older

Unfortunately Gateway API v0.8.0 is not supported on these Kubernetes versions.

... (truncated)

Commits

• 3d22aa5 Merge pull request #2360 from robscott/changelog-v0.8.0
• 645b165 Adding v0.8.0 changelog
• 5d4a870 Merge pull request #2315 from gcs278/fix-gep-link
• ad75c72 Fix broken links to GEPs
• 2ed9486 Merge pull request #2358 from gauravkghildiyal/tcp-leaks
• 4f8e572 Merge pull request #2327 from sayboras/tam/remove-experiment-tag
• ddd0fd2 fix leaking TCP connections in conformance tests
• 74562ef Merge pull request #2351 from kubernetes-sigs/dependabot/pip/mkdocs-material-...
• c376a9a Merge pull request #2352 from kubernetes-sigs/dependabot/go_modules/sigs.k8s....
• a5bc0dc build(deps): bump sigs.k8s.io/controller-runtime from 0.15.1 to 0.16.0
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[github-actions]

backporting to release-2.4 with action

backporting to release-2.0 with action
backporting to release-2.1 with action
backporting to release-2.2 with action