v1.1.0

v1.1.0

On behalf of Kubernetes SIG Network, we are pleased to announce the v1.1 release!
This release includes the graduation of several features to GA, including both
GRPCRoute and Service Mesh. We are also introducing several new experimental
features, including Session Persistence and Gateway Client Cert Verification.

The following represents the changes since v1.0.0:

Standard Channel

GRPCRoute has Graduated to GA 🎉

GRPCRoute has graduated to GA (v1) and is now part of the Standard Channel. If
you are already using the experimental version GRPCRoute, we recommend holding
off on upgrading to the standard channel version of GRPCRoute until the
controllers you're using have been updated to support GRPCRoute v1. Until then,
it is safe to upgrade to the experimental channel version of GRPCRoute in v1.1
that includes both v1alpha2 and v1 API versions.

Leading Contributor: @gnossen

Service Mesh Support has Graduated to GA 🎉

The standard for using Gateway API for Mesh has formally graduated to GA (v1)
and is now part of the Standard Channel.

Service mesh support in Gateway API allows service mesh users to use the same
API to manage ingress traffic and mesh traffic, reusing the same policy and
routing interfaces. In Gateway API v1.1, routes (such as HTTPRoute) can now have
a Service as a parentRef, to control how traffic to specific services
behave. For more information, read the service
mesh documentation or see the list of
implementations.

Leading Contributors: @howardjohn, @keithmattix, @kflynn, @mikemorris

Conformance Profiles and Reports

The Conformance Reports API and the corresponding test suite have been graduated
to GA. The Conformance report API has been expanded with the mode field
(intended to specify the working mode of the implementation), and the
gatewayAPIChannel (standard or experimental). The gatewayAPIVersion and
gatewayAPIChannel are now filled in automatically by the suite machinery,
along with a brief description of the testing outcome. The Reports have been
reorganized in a more structured way, and the implementations can now add
information on how the tests have been run and provide reproduction steps.

Leading Contributors: @mlavacca, @shaneutt

ParentRef Port field Graduated to GA

The port field in ParentRefs has graduated to GA (v1) and is now part of the
Standard Channel. You can use the port field to attach resources to Gateways,
Services, or other parent resources. For example, you can attach an HTTPRoute to
one or more specific Listeners of a Gateway based on the Listener port,
instead of name field.

Leading Contributor: @frankbu

Experimental Channel

Session Persistence + BackendLBPolicy

Session Persistence is being introduced to Gateway API via a new policy
(BackendLBPolicy) for Service-level configuration and as fields within HTTPRoute
and GRPCRoute for Route-level configuration. The BackendLBPolicy and Route-level
APIs provide the same session persistence configuration, including session
timeouts, session name, session type, and cookie lifetime type.

Leading Contributors: @gcs278, @ginayeh

Gateway Client Cert Verification

Gateways can now configure client cert verification for each Gateway Listener by
introducing a new field frontendValidation field within tls. This field
supports configuring a list of CA Certificates that can be used as a trust
anchor to validate the certificates presented by the client.

Leading Contributors: @arkodg

BackendTLSPolicy

As part of a broader goal of making our TLS terminology more consistent
throughout the API, we've introduced some breaking changes to BackendTLSPolicy.
This has resulted in a new API version (v1alpha3) and will require any existing
users of this policy to uninstall the v1alpha2 version before installing this
newer version.

Any references to v1alpha2 BackendTLSPolicy fields will need to be updated.
Specific changes include:

• the targetRef field is now a targetRefs list and these references no
  longer include a namespace field.
• the tls field has been renamed to validation
• the caCertRefs field has been renamed to caCertificateRefs
• the wellKnownCACerts field has been renamed to wellKnownCACertificates

Leading Contributors: @candita

Gateway Params

Gateways now feature a new field that allows references to
implementation-specific parameters, similar to GatewayClass.

Leading Contributors: @howardjohn

Everything Else

gwctl

• We've extended the get command to support gateways, gatewayclasses, and
  namespaces. (#2865, #2782, #2847, @jongwooo)
• The get command now provides more detailed information for httproutes,
  policies, and policycrds. (#2805, #2808, #2811, @jongwooo)
• describe command now supports descriptions of policycrds and namespaces.
  (#2872, #2836, @Devaansh-Kumar)
• We've added the ability to filter resources using labels (through the -l
  flag) with both the get and describe commands. (#2892, #2915, #2934,
  @yeedove)
• Bug fix: Prevent panic when describing gatewayclasses with no description
  (#2894, @pmalek)
• Properly handle different API versions (#3001, @gauravkghildiyal)
• Provide more detail in describe output (#2999, @gauravkghildiyal)
• Support JSON and YAML output format in get commands (#2940,
  @yashvardhan-kukreja)

Validation Changes

• TLS Configuration is no longer required on Gateway Listeners to enable more
  flexible TLS configuration. (#2721, @robscott)

Conformance Tests

• Conformance Profiles have been renamed and a new Mesh-GRPC profile has been
  added (#3019, @mlavacca):
  • HTTP -> Gateway-HTTP
  • GRPC -> Gateway-GRPC
  • TLS -> Gateway-TLS
  • Mesh -> Mesh-HTTP
• Fixed GatewayWithAttachedRoutes conformance test to not check that the
  HTTPRoute status includes an "Accepted: False" condition because this is not
  required by the specification. (#2548, @frankbu)
• A new comparison view has been added to our documentation that shows the
  extended features supported by every implementation that has submitted a
  conformance report (#2874, @xtineskim)
• Added SupportMeshConsumerRoute and SupportMeshClusterIPMatching supported
  features to more clearly communicate the purpose of existing Mesh conformance
  tests (#3035, @howardjohn)
• Add conformance test for HTTP listener isolation (#3047, @arkodg, @pleshakov)

Dependencies

• Gateway API has upgraded to Go v1.22 and Kubernetes v1.30 (#2988, @robscott)

Cleanup

• The validating webhook has been removed. CEL validation is now built-in to
  CRDs and replaces the webhook. (#2595, @robscott)
• BackendTLSPolicy WellKnownCACerts field has been updated to
  implementation-specific support (#2741, @sunjayBhatia)
• Clarify policy attachment by two of the same policy types when using section
  names. (#2442, @maleck13)
• Remove v1alpha2 directory from docs: (#2965, @robscott)

v1.1.0-rc2

We expect that this release candidate is quite close to the final v1.1.0
release. However, subsequent breaking API changes are still possible.

This release candidate is suitable for implementors, but we do not recommend
shipping products based on a release candidate API due to the possibility of
incompatible changes prior to the final release. The following represents the
changes since v1.1.0-rc1:

Conformance Profiles

• Add SupportMeshConsumerRoute and SupportMeshClusterIPMatching supported
  features to more clearly communicate the purpose of existing Mesh conformance
  tests (#3035, @howardjohn)
• Add conformance test for HTTP listener isolation (#3047, @arkodg, @pleshakov)

gwctl

• Properly handle different API versions (#3001, @gauravkghildiyal)
• Provide more detail in describe output (#2999, @gauravkghildiyal)
• Support JSON and YAML output format in get commands (#2940,
  @yashvardhan-kukreja)

Cleanup

• Revert accidental removal of experimental kustomize configuration (#3022,
  @howardjohn)

Dependencies

• sigs.k8s.io/controller-tools from 0.14.0 to 0.15.0 (#3031)
• sigs.k8s.io/controller-runtime from 0.17.0 to 0.18.0 (#3023, @tao12345666333)

v1.1.0-rc1

We expect that this release candidate is quite close to the final v1.1.0
release. However, subsequent breaking API changes are still possible.

This release candidate is suitable for implementors, but we do not recommend
shipping products based on a release candidate API due to the possibility of
incompatible changes prior to the final release. The following represents the
changes since v1.0.0:

Standard Channel

GRPCRoute has Graduated to GA 🎉

GRPCRoute has graduated to GA (v1) and is now part of the Standard Channel. If
you are already using the experimental version GRPCRoute, we recommend holding
off on upgrading to the standard channel version of GRPCRoute until the
controllers you're using have been updated to support GRPCRoute v1. Until then,
it is safe to upgrade to the experimental channel version of GRPCRoute in v1.1
that includes both v1alpha2 and v1 API versions.

Leading Contributor: @gnossen

Service Mesh Support has Graduated to GA 🎉

The standard for using Gateway API for Mesh has formally graduated to GA (v1)
and is now part of the Standard Channel.

Service mesh support in Gateway API allows service mesh users to use the same
API to manage ingress traffic and mesh traffic, reusing the same policy and
routing interfaces. In Gateway API v1.1, routes (such as HTTPRoute) can now have
a Service as a parentRef, to control how traffic to specific services
behave. For more information, read the service
mesh documentation or see the list of
implementations.

Leading Contributors: @howardjohn, @keithmattix, @kflynn, @mikemorris

Conformance Profiles and Reports

The Conformance Reports API and the corresponding test suite have been graduated
to GA. The Conformance report API has been expanded with the mode field
(intended to specify the working mode of the implementation), and the
gatewayAPIChannel (standard or experimental). The gatewayAPIVersion and
gatewayAPIChannel are now filled in automatically by the suite machinery,
along with a brief description of the testing outcome. The Reports have been
reorganized in a more structured way, and the implementations can now add
information on how the tests have been run and provide reproduction steps.

Leading Contributors: @mlavacca, @shaneutt

ParentRef Port field Graduated to GA

The port field in ParentRefs has graduated to GA (v1) and is now part of the
Standard Channel. You can use the port field to attach resources to Gateways,
Services, or other parent resources. For example, you can attach an HTTPRoute to
one or more specific Listeners of a Gateway based on the Listener port,
instead of name field.

Leading Contributor: @frankbu

Experimental Channel

Session Persistence + BackendLBPolicy

Session Persistence is being introduced to Gateway API via a new policy
(BackendLBPolicy) for Service-level configuration and as fields within HTTPRoute
and GRPCRoute for Route-level configuration. The BackendLBPolicy and Route-level
APIs provide the same session persistence configuration, including session
timeouts, session name, session type, and cookie lifetime type.

Leading Contributors: @gcs278, @ginayeh

Gateway Client Cert Verification

Gateways can now configure client cert verification for each Gateway Listener by
introducing a new field frontendValidation field within tls. This field
supports configuring a list of CA Certificates that can be used as a trust
anchor to validate the certificates presented by the client.

Leading Contributors: @arkodg

BackendTLSPolicy

As part of a broader goal of making our TLS terminology more consistent
throughout the API, we've introduced some breaking changes to BackendTLSPolicy.
This has resulted in a new API version (v1alpha3) and will require any existing
users of this policy to uninstall the v1alpha2 version before installing this
newer version.

Any references to v1alpha2 BackendTLSPolicy fields will need to be updated.
Specific changes include:

• the targetRef field is now a targetRefs list and these references no
  longer include a namespace field.
• the tls field has been renamed to validation
• the caCertRefs field has been renamed to caCertificateRefs
• the wellKnownCACerts field has been renamed to wellKnownCACertificates

Leading Contributors: @candita

Gateway Params

Gateways now feature a new field that allows references to
implementation-specific parameters, similar to GatewayClass.

Leading Contributors: @howardjohn

Everything Else

gwctl

• We've extended the get command to support gateways, gatewayclasses, and
  namespaces. (#2865, #2782, #2847, @jongwooo)
• The get command now provides more detailed information for httproutes,
  policies, and policycrds. (#2805, #2808, #2811, @jongwooo)
• describe command now supports descriptions of policycrds and namespaces.
  (#2872, #2836, @Devaansh-Kumar)
• We've added the ability to filter resources using labels (through the -l
  flag) with both the get and describe commands. (#2892, #2915, #2934,
  @yeedove)
• Bug fix: Prevent panic when describing gatewayclasses with no description
  (#2894, @pmalek)

Validation Changes

• TLS Configuration is no longer required on Gateway Listeners to enable more
  flexible TLS configuration. (#2721, @robscott)

Conformance Tests

• Conformance Profiles have been renamed and a new Mesh-GRPC profile has been
  added (#3019, @mlavacca):
  • HTTP -> Gateway-HTTP
  • GRPC -> Gateway-GRPC
  • TLS -> Gateway-TLS
  • Mesh -> Mesh-HTTP
• Fixed GatewayWithAttachedRoutes conformance test to not check that the
  HTTPRoute status includes an "Accepted: False" condition because this is not
  required by the specification. (#2548, @frankbu)

Dependencies

• Gateway API has upgraded to Go v1.22 and Kubernetes v1.30 (#2988, @robscott)

Cleanup

• The validating webhook has been removed. CEL validation is now built-in to
  CRDs and replaces the webhook. (#2595, @robscott)
• BackendTLSPolicy WellKnownCACerts field has been updated to
  implementation-specific support (#2741, @sunjayBhatia)
• Clarify policy attachment by two of the same policy types when using section
  names. (#2442, @maleck13)
• Remove v1alpha2 directory from docs: (#2965, @robscott)

v1.0.0

On behalf of Kubernetes SIG Network, we are pleased to announce the v1.0 release!
This release marks a huge milestone for this project. Several key APIs are
graduating to GA (generally available), while other significant features have
been added to the Experimental channel.

It's been four years since this project began, and we would never have gotten
here without the support of a dedicated and active community. The maintainers
would like to thanks everyone who's contributed to Gateway API, whether in the
form of commits to the repo, discussion, ideas, or general support. We literally
couldn't have gotten this far without you.

This project is nowhere near finished, as you can see from the large amount of
features being added into the Experimental Channel. With such a big set of
things still to do, contributors and contributions are more vital than ever.
Please feel welcome to join our community!!

Gateway, GatewayClass, and HTTPRoute are GA 🎉

Gateway, GatewayClass, and HTTPRoute have all graduated to GA with a v1 API
version. Although these APIs will continue to grow with future additions, the
versions of these resources available via the Standard Channel are stable and
recommended for use in production. Many implementations are fully passing
conformance tests that cover the functionality of each of these resources. These
APIs are graduating to GA with only minor spec clarifications since the v0.8.0
release.

CEL Migration

Starting in v0.8.0, Gateway API CRDs now include CEL validation. In this release
the validating webhook is no longer bundled with CRD installation. Instead we
include a separate webhook-install.yaml file as part of the release artifacts.

If you're running Kubernetes 1.25+, we do not recommend installing the webhook
and additionally suggest that you uninstall any previously installed versions of
the webhook.

If you're still running Kubernetes 1.23 or 1.24, we recommend installing the
webhook until you can upgrade to Kubernetes 1.25 or newer.

New Experimental Features

There are several exciting new experimental features in this release:

BackendTLSPolicy

A new BackendTLSPolicy resource has been introduced for configuring TLS
connections from Gateways to Backends. This allows you to configure the Gateway
to validate the certificates served by Backends. For more information, refer to
GEP 1897.

Primary Author: @candita

HTTPRoute Timeouts

HTTPRoute has a new Timeouts field on Route Rules. This allows you to
configure overall Request Timeouts as well as Backend Request Timeouts. For more
information, refer to GEP 1742.

Primary Authors: @frankbu, @SRodi

Gateway Infrastructure Labels

Gateway has a new Infrastructure field that allows you to specify Labels or
Annotations that you'd like to be propagated to each resource generated for a
Gateway. For example, these labels and annotations may be copied to Services and
Deployments provisioned for in-cluster Gateways, or to other
implementation-specific resources, such as Cloud Load Balancers. For more
information, refer to GEP 1762.

Primary Author: @howardjohn

WebSockets, HTTP/2, and More

Some coordinated work across both Gateway API and upstream Kubernetes has
defined 3 new values for the AppProtocol field on Service Ports:

• kubernetes.io/h2c - HTTP/2 over cleartext as described in
  RFC7540
• kubernetes.io/ws - WebSocket over cleartext as described in
  RFC6445
• kubernetes.io/wss - WebSocket over TLS as described in
  RFC6455

These can now be used with Gateway API to describe the protocol to use for
connections to Kubernetes Services. For more information, refer to GEP 1911.

A new CLI tool: gwctl

An experimental new CLI tool and kubectl plugin, gwctl aims to improve the UX
when interacting with Gateway API. Initially it is focused on Policy Attachment,
making it easier to understand which policies are available in a cluster, and
which have been applied. In future releases, we hope to expand the scope of this
tool to provide more detailed responses when getting and describing Gateway API
resources. Note that this tool is still in very early stages and it's very
likely that future releases will include breaking changes for gwctl. For more
information, refer to the gwctl Readme.

Primary Author: @gauravkghildiyal

Everything Else

Of course there's a lot more in this release:

Spec Clarifications

• Clarify that the Gateway Listener status AttachedRoutes field is a count of
  the number of Routes associated with a Listener regardless of Gateway or Route
  status. (#2396, @sunjayBhatia)
• Gateway: A new concept called "Listener Isolation" has been introduced to
  describe the recommendation that at most one Listener matches a request, and
  only Routes attached to that Listener are used for routing. (#2465, @robscott)
• Experimental Channel: For ParentRefs to be considered distinct, they either
  both need to specify a distinct SectionName, both need to specify a distinct
  Port, or both. (#2433, @robscott)
• Updated rules about Listener uniqueness to use the term distinct (#2436,
  @youngnick)

Status

• GatewayClass Status: A new experimental supportedFeatures field has been
  added. Implementations should populate this with the features they support.
  (#2461, @LiorLieberman, @robscott)
• GatewayClass Status: A new SupportedVersion condition has been added that MUST
  be set when a GatewayClass is accepted. (#2384, @robscott)
• Route Status: A new "PartiallyInvalid" condition has been added for all Route
  types. This condition also includes guidance for how partially invalid states
  should be handled with Gateway API. (#2429, @robscott)
• The condition reason GatewayReasonUnsupportedAddress for Accepted now ONLY
  applies when an address type is provided for a Gateway which it does not
  support.
  (#2412 @shaneutt)
• The condition reason GatewayReasonAddressNotAssigned for Programmed now
  ONLY applies to problems with dynamic address allocation.
  (#2412 @shaneutt)
• The condition reason GatewayReasonAddressNotUsable for Programmed has been
  added to deal with situations where a static address has been provided for a
  Gateway which is of a supported type, and is syntactically valid, but for some
  reason it can not be used for this Gateway (e.g. the address is already in use
  on the network).
  (#2412 @shaneutt)

Documentation

• A guide for Gateway API implementers is now included in the specification.
  (#2454, @youngnick)
• Gateway API versioning will continue to rely on two release channels -
  Standard and Experimental. New resources will start in the Experimental
  Channel with an alpha API Version and then graduate to the Standard Channel
  with a GA API version. Resources that already have Beta API versions will
  continue to have them, but no additional Gateway API resources will get a Beta
  API version. (#2446, @robscott)

Cleanup

• Validating Webhook logs now use Errorf instead of Fatalf. (#2361, @yylt)

Bug Fixes

• CEL validation for BackendTLSPolicy was fixed with corresponding tests added
  (#2491, @Ygnas)
• Fixes the API version for ReferenceGrant from v1 to v1beta1 in the
  GatewaySecretInvalidReferenceGrant conformance test YAML (#2494, @arkodg)
• Gateway infrastructure field is now a pointer (#2508, @danehans)

Conformance Tests

• h2c Backend Protocol conformance tests were added (#2456, @dprotaso)
• WebSocket Backend Protocol conformance tests were added (#2495, @dprotaso)
• New conformance test for Gateway Status AttachedRoutes (#2477, @danehans)
• Implemented the ExemptFeatures field for Experimental Conformance Profiles
  (#2515, @arkodg)

Other (Cleanup or Flake)

• Resources related to the validating webhook such as the gateway-system
  namespace and the gateway-api-admission-server deployment have been removed
  from the installation manifests, in favor of CEL based Validations that are
  built into the CRD definition. These are still available in
  webhook-install.yaml in case you would like to optionally install them.
  (#2401, @arkodg)

v1.0.0-rc2

The working group expects that this release candidate is quite close to the
final v0.8.0 release. However, breaking API changes are still possible.

This release candidate is suitable for implementors, but the working group does
not recommend shipping products based on a release candidate API due to the
possibility of incompatible changes prior to the final release. The following
represents the changes since v1.0.0-rc1:

Bug Fixes

• CEL validation for BackendTLSPolicy was fixed with corresponding tests added
  (#2491, @Ygnas)
• Fixes the API version for ReferenceGrant from v1 to v1beta1 in the
  GatewaySecretInvalidReferenceGrant conformance test YAML (#2494, @arkodg)
• Gateway infrastructure field is now a pointer (#2508, @danehans)

Conformance Tests

• h2c Backend Protocol conformance tests were added (#2456, @dprotaso)
• WebSocket Backend Protocol conformance tests were added (#2495, @dprotaso)
• New conformance test for Gateway Status AttachedRoutes (#2477, @danehans)
• Implemented the ExemptFeatures field for Experimental Conformance Profiles
  (#2515, @arkodg)

v1.0.0-rc1

The working group expects that this release candidate is quite close to the
final v0.8.0 release. However, breaking API changes are still possible.

This release candidate is suitable for implementors, but the working group does
not recommend shipping products based on a release candidate API due to the
possibility of incompatible changes prior to the final release. The following
represents the changes since v0.8.0-rc1:

Gateway, GatewayClass, and HTTPRoute are GA 🎉

Gateway, GatewayClass, and HTTPRoute have all graduated to GA with a v1 API
version. Although these APIs will continue to grow with future additions, the
versions of these resources available via the Standard Channel are stable and
recommended for use in production. Many implementations are fully passing
conformance tests that cover the functionality of each of these resources. These
APIs are graduating to GA with only minor spec clarifications since the v0.8.0
release.

CEL Migration

Starting in v0.8.0, Gateway API CRDs now include CEL validation. In this release
the validating webhook is no longer bundled with CRD installation. Instead we
include a separate webhook-install.yaml file as part of the release artifacts.

If you're running Kubernetes 1.25+, we do not recommend installing the webhook
and additionally suggest that you uninstall any previously installed versions of
the webhook.

If you're still running Kubernetes 1.23 or 1.24, we recommend installing the
webhook until you can upgrade to Kubernetes 1.25 or newer.

New Experimental Features

There are several exciting new experimental features in this release:

BackendTLSPolicy

A new BackendTLSPolicy resource has been introduced for configuring TLS
connections from Gateways to Backends. This allows you to configure the Gateway
to validate the certificates served by Backends. For more information, refer to
GEP 1897.

Primary Author: @candita

HTTPRoute Timeouts

HTTPRoute has a new Timeouts field on Route Rules. This allows you to
configure overall Request Timeouts as well as Backend Request Timeouts. For more
information, refer to GEP 1742.

Primary Authors: @frankbu, @SRodi

Gateway Infrastructure Labels

Gateway has a new Infrastructure field that allows you to specify Labels or
Annotations that you'd like to be propagated to each resource generated for a
Gateway. For example, these labels and annotations may be copied to Services and
Deployments provisioned for in-cluster Gateways, or to other
implementation-specific resources, such as Cloud Load Balancers. For more
information, refer to GEP 1762.

Primary Author: @howardjohn

WebSockets, HTTP/2, and More

Some coordinated work across both Gateway API and upstream Kubernetes has
defined 3 new values for the AppProtocol field on Service Ports:

• kubernetes.io/h2c - HTTP/2 over cleartext as described in
  RFC7540
• kubernetes.io/ws - WebSocket over cleartext as described in
  RFC6445
• kubernetes.io/wss - WebSocket over TLS as described in
  RFC6455

These can now be used with Gateway API to describe the protocol to use for
connections to Kubernetes Services. For more information, refer to GEP
1911.

A new CLI tool: gwctl

An experimental new CLI tool and kubectl plugin, gwctl aims to improve the UX
when interacting with Gateway API. Initially it is focused on Policy Attachment,
making it easier to understand which policies are available in a cluster, and
which have been applied. In future releases, we hope to expand the scope of this
tool to provide more detailed responses when getting and describing Gateway API
resources. Note that this tool is still in very early stages and it's very
likely that future releases will include breaking changes for gwctl. For more
information, refer to the gwctl Readme.

Primary Author: @gauravkghildiyal

Everything Else

Of course there's a lot more in this release:

Spec Clarifications

• Clarify that the Gateway Listener status AttachedRoutes field is a count of
  the number of Routes associated with a Listener regardless of Gateway or Route
  status. (#2396, @sunjayBhatia)
• Gateway: A new concept called "Listener Isolation" has been introduced to
  describe the recommendation that at most one Listener matches a request, and
  only Routes attached to that Listener are used for routing. (#2465, @robscott)
• Experimental Channel: For ParentRefs to be considered distinct, they either
  both need to specify a distinct SectionName, both need to specify a distinct
  Port, or both. (#2433, @robscott)
• Updated rules about Listener uniqueness to use the term distinct (#2436,
  @youngnick)

Status

• GatewayClass Status: A new experimental supportedFeatures field has been
  added. Implementations should populate this with the features they support.
  (#2461, @LiorLieberman, @robscott)
• GatewayClass Status: A new SupportedVersion condition has been added that MUST
  be set when a GatewayClass is accepted. (#2384, @robscott)
• Route Status: A new "PartiallyInvalid" condition has been added for all Route
  types. This condition also includes guidance for how partially invalid states
  should be handled with Gateway API. (#2429, @robscott)
• The condition reason GatewayReasonUnsupportedAddress for Accepted now ONLY
  applies when an address type is provided for a Gateway which it does not
  support.
  (#2412 @shaneutt)
• The condition reason GatewayReasonAddressNotAssigned for Programmed now
  ONLY applies to problems with dynamic address allocation.
  (#2412 @shaneutt)
• The condition reason GatewayReasonAddressNotUsable for Programmed has been
  added to deal with situations where a static address has been provided for a
  Gateway which is of a supported type, and is syntatically valid, but for some
  reason it can not be used for this Gateway (e.g. the address is already in use
  on the network).
  (#2412 @shaneutt)

Documentation

• A guide for Gateway API implementers is now included in the specification.
  (#2454, @youngnick)
• Gateway API versioning will continue to rely on two release channels -
  Standard and Experimental. New resources will start in the Experimental
  Channel with an alpha API Version and then graduate to the Standard Channel
  with a GA API version. Resources that already have Beta API versions will
  continue to have them, but no additional Gateway API resources will get a Beta
  API version. (#2446, @robscott)

Cleanup

• Validating Webhook logs now use Errorf instead of Fatalf. (#2361, @yylt)

Other (Cleanup or Flake)

• Resources related to the validating webhook such as the gateway-system
  namespace and the gateway-api-admission-server deployment have been removed
  from the installation manifests, in favor of CEL based Validations that are
  built into the CRD definition. These are still available in
  webhook-install.yaml in case you would like to optionally install them.
  (#2401, @arkodg)

v0.8.1

v0.8.1

This is a patch release that includes small bug fixes and a new conformance test
as a follow up to the v0.8.0 release.

Changes by Kind

Bug Fixes

• Fix CEL validation not handling missing listener hostname correctly. (#2370, @frankbu)
• Fix IPv6 parsing in conformance tests (#2375, @keithmattix)

Conformance Tests

• Add conformance test for multiple mirror filters. (#2359, @levikobi)

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.
Gateway API v0.8.0 CRDs include CEL validation and cannot be installed on these
versions of Kubernetes. Note that Gateway API only commits to providing support
for the 5 most recent versions of Kubernetes,
and thus these versions are no longer supported by Gateway API.

API Version Changes

As we prepare for a v1.0 release that will graduate Gateway, GatewayClass, and
HTTPRoute to the v1 API Version from v1beta1, we are continuing the process
of moving away from v1alpha2 for resources that have graduated to v1beta1.
The following changes are included in this release:

• v1alpha2 of Gateway, GatewayClass, and HTTPRoute is no longer served
• v1alpha2 of ReferenceGrant is deprecated
• v1beta1 is now the storage version for ReferenceGrant

Those changes mean that:

• Users and implementations that were reading or writing from v1alpha2 of
  Gateway, GatewayClass, or HTTPRoute MUST upgrade to use v1beta1.
• Users and implementations that were reading or writing from v1alpha2 of
  ReferenceGrant SHOULD upgrade to use v1beta1.

For more information, refer to
#2069.

Supported Features and Conformance Levels

Gateway API conformance tests have a concept of "Supported Features".
Implementations state which features they support, and then all the tests
covering that set of features are run.

Prior to v0.8.0, we had a concept of "StandardCoreFeatures" that represented the
set of features we expected every implementation to implement. Support for the
Gateway and HTTPRoute resources was included in that list.

Alongside that, Gateway API also has a concept of "Support Levels" such as
"Core", "Extended", and "Implementation-Specific". The API had labeled 2
resources as having support levels, but these didn't really make sense with
the modular API model of Gateway API.

In this release, we've simplified the concepts here. Individual resources no
longer have assigned support levels, instead these are represented as "Supported
Features." Implementations can separately claim to support Gateway,
ReferenceGrant, or any other resource. This change helps accommodate incoming
Mesh implementations, many of which do not support one or both of these
resources.

For more information refer to
#2323.

Other Changes

Status

• Add IncompatibleFilters reason for implementations to specify when a route is
  invalid due to an invalid combination of route filters. (#2150, @sunjayBhatia)

Validation

• Add CEL validation for GRPCRoute. (#2305, @gnossen)
• HTTPRoute and GRPCRoute CRDs now provide built-in validation that ensures the
  uniqueness of names in Header Modifier "Remove" lists. (#2306, @robscott)

Spec Clarifications

• RequestMirrorFilter: Enhanced the doc string to be explicit about sending the
  mirrored request to a single destination endpoint within the backendRef
  specified. (#2317, @arkodg)
• HTTPRoute Method matching precedence has been clarified (#2054,
  @gauravkghildiyal)
• Clarify that implementations must not modify HTTP Host header. Adds
  specificity alongside spec that port in Host header must be ignored when
  matching on host. (#2092, @sunjayBhatia)
• Fix typo: rename GatewaReasonUnsupportedAddress ->
  GatewayReasonUnsupportedAddress (#2149, @panslava)
• HTTPRoute: Clarified that exact path matches are truly exact, both trailing
  slashes and capitalization are meaningful. (#2055, @robscott)
• Implementations MUST ignore any port value specified in the HTTP Host header
  while performing a match against HTTPRoute.Hostnames (#1980,
  @gauravkghildiyal)

Conformance

• Add conformance tests against accepting invalid ReferenceGrants in HTTPRoute
  and TLSRoute (#2076, @meyskens)
• Fixed an issues causing conformance tests to fail when using IPv6 addresses
  (#2024, @howardjohn)
• HTTPRoute connectivity is in now enforced in conformance tests if a relevant
  ReferenceGrant gets deleted. (#1853, @pmalek)
• The --skip-tests flag has been added to the conformance CLI to enable tests
  opt-out when using it. (#2170, @mlavacca)
• The experimental conformance profile suite can now be added as a stand-alone
  cli and by means of go test. (#2066, @mlavacca)
• GEPs now must have a Conformance Details section that specifies the feature's
  name for conformance purposes. (#2115, @youngnick)
• Better support mesh-only conformance testing (#2312, @kflynn)
• SupportedFeatures have been restructured to be per-resource (#2323, @robscott)
• Add SupportedFeature for port 8080 on Gateway (#2184, @xtineskim)
• Fixes for IPv6 in Mesh (#2340, @keithmattix)
• Fix leaking TCP connections which can lead to conformance test failures
  (#2358, @gauravkghildiyal)

Webhook

• Changed default imagePullPolicy for gateway-api-admission-server to
  IfNotPresent. (#2215, @networkhermit)
• Webhook config works with PodAdmission restricted (#2016, @jcpunk)

Documentation

• Adds support for ParentRef targeting a Kubernetes Service resource for mesh
  implementations. (#2146, @mikemorris)
• Clarify wording on website around Gateway API vs API Gateway (#2191,
  @david-martin)
• GEP-1282, Backend Properties, has been declined. (#2132, @youngnick)
• Added missing GEPs. (#2114, @levikobi)

Bug Fixes

• Added the missing ReferenceGrant resource the kustomization.yaml for the
  standard channel (#2084, @howardjohn)
• Webhook validation now ensures that BackendRefs can not be specified in the
  same HTTPRoute rule as a Redirect filter (#2161, @slayer321)
• GRPCRoute: The default match has been removed as it was invalid (it only
  specified a type of "Exact" without a corresponding Service or Method). Note
  that the match type still defaults to "Exact". (#2311, @gauravkghildiyal)

New Contributors

• @jcpunk made their first contribution in #2016
• @evankanderson made their first contribution in #2100
• @spacewander made their first contribution in #2130
• @levikobi made their first contribution in #2114
• @mmorel-35 made their first contribution in #2138
• @Treenhan made their first contribution in #2101
• @meyskens made their first contribution in #2076
• @kflynn made their first contribution in #2182
• @AmaliMatharaarachchi made their first contribution in #2168
• @xtineskim made their first contribution in #2184
• @saltbo made their first contribution in #2185
• @slayer321 made their first contribution in #2161
• @adleong made their first contribution in #2164
• @david-martin made their first contribution in https://github.com/kuber...

v0.8.0-rc2

The working group expects that this release candidate is quite close to the final
v0.8.0 release. However, breaking API changes are still possible.

This release candidate is suitable for implementors, but the working group does
not recommend shipping products based on a release candidate API due to the
possibility of incompatible changes prior to the final release. The following
represents the changes since v0.8.0-rc1:

Changes by Kind

Validation

• Add CEL validation for GRPCRoute. (#2305, @gnossen)
• HTTPRoute and GRPCRoute CRDs now provide built-in validation that ensures the
  uniqueness of names in Header Modifier "Remove" lists. (#2306, @robscott)

Bug Fixes

• GRPCRoute: The default match has been removed as it was invalid (it only
  specified a type of "Exact" without a corresponding Service or Method). Note
  that the match type still defaults to "Exact". (#2311, @gauravkghildiyal)

Spec Clarifications

• RequestMirrorFilter: Enhanced the doc string to be explicit about sending the
  mirrored request to a single destination endpoint within the backendRef
  specified. (#2317, @arkodg)
• Resources no longer have support levels, implementations can choose to support
  whichever set of resources they want (#2323, @robscott)

Conformance

• Better support mesh-only conformance testing (#2312, @kflynn)
• SupportedFeatures have been restructured to be per-resource (#2323, @robscott)

New Contributors

• @whitneygriffith made their first contribution in #2301
• @uucloud made their first contribution in #2308
• @caroltyk made their first contribution in #2291

Full Changelog: v0.8.0-rc1...v0.8.0-rc2

v0.8.0-rc1

The working group expects that this release candidate is quite close to the final
v0.8.0 release. However, breaking API changes are still possible.

This release candidate is suitable for implementors, but the working group does
not recommend shipping products based on a release candidate API due to the
possibility of incompatible changes prior to the final release.

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.

Standard Channel: 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.

Experimental Channel: TCPRoute, TLSRoute, and UDPRoute are fully covered by
CEL validation. GRPCRoute still has some significant gaps in CEL validation that
will be covered in a future release.

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.
Gateway API v0.8.0 CRDs include CEL validation and cannot be installed on these
versions of Kubernetes. Note that Gateway API only commits to providing support
for the 5 most recent versions of
Kubernetes,
and thus these versions are no longer supported by Gateway API.

API Version Changes

As we prepare for a v1.0 release that will graduate Gateway, GatewayClass, and
HTTPRoute to the v1 API Version from v1beta1, we are continuing the process
of moving away from v1alpha2 for resources that have graduated to v1beta1.
The following changes are included in this release:

• v1alpha2 of Gateway, GatewayClass, and HTTPRoute is no longer served
• v1alpha2 of ReferenceGrant is deprecrated
• v1beta1 is now the storage version for ReferenceGrant

Those changes mean that:

• Users and implementations that were reading or writing from v1alpha2 of
  Gateway, GatewayClass, or HTTPRoute MUST upgrade to use v1beta1.
• Users and implementations that were reading or writing from v1alpha2 of
  ReferenceGrant SHOULD upgrade to use v1beta1.

For more information, refer to
#2069.

Other Changes

Status

• Add IncompatibleFilters reason for implementations to specify when a route is
  invalid due to an invalid combination of route filters. (#2150, @sunjayBhatia)

Spec Clarifications

• HTTPRoute Method matching precedence has been clarified (#2054,
  @gauravkghildiyal)
• Clarify that implementations must not modify HTTP Host header. Adds
  specificity alongside spec that port in Host header must be ignored when
  matching on host. (#2092, @sunjayBhatia)
• Fix typo: rename GatewaReasonUnsupportedAddress ->
  GatewayReasonUnsupportedAddress (#2149, @panslava)
• HTTPRoute: Clarified that exact path matches are truly exact, both trailing
  slashes and capitalization are meaningful. (#2055, @robscott)
• Implementations MUST ignore any port value specified in the HTTP Host header
  while performing a match against HTTPRoute.Hostnames (#1980,
  @gauravkghildiyal)

Conformance

• Add conformance tests against accepting invalid ReferenceGrants in HTTPRoute
  and TLSRoute (#2076, @meyskens)
• Fixed an issues causing conformance tests to fail when using IPv6 addresses
  (#2024, @howardjohn)
• HTTPRoute connectivity is in now enforced in conformance tests if a relevant
  ReferenceGrant gets deleted. (#1853, @pmalek)
• The --skip-tests flag has been added to the conformance CLI to enable tests
  opt-out when using it. (#2170, @mlavacca)
• The experimental conformance profile suite can now be added as a stand-alone
  cli and by means of go test. (#2066, @mlavacca)
• GEPs now must have a Conformance Details section that specifies the feature's
  name for conformance purposes. (#2115, @youngnick)

Webhook

• Changed default imagePullPolicy for gateway-api-admission-server to
  IfNotPresent. (#2215, @networkhermit)
• Webhook config works with PodAdmission restricted (#2016, @jcpunk)

Documentation

• Adds support for ParentRef targeting a Kubernetes Service resource for mesh
  implementations. (#2146, @mikemorris)
• Clarify wording on website around Gateway API vs API Gateway (#2191,
  @david-martin)
• GEP-1282, Backend Properties, has been declined. (#2132, @youngnick)
• Added missing GEPs. (#2114, @levikobi)

Bug Fixes

• Added the missing ReferenceGrant resource the kustomization.yaml for the
  standard channel (#2084, @howardjohn)
• Webhook validation now ensures that BackendRefs can not be specified in the
  same HTTPRoute rule as a Redirect filter (#2161, @slayer321)