Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/kubernetes-sigs/gateway-api/releases below:

Website Navigation

• Releases
• Tags

Releases · kubernetes-sigs/gateway-api · GitHub

• Fixed typo in Retry Budget configuration (#3762,@zirain)

This section is intended to be a guide for API changes that might inspire or require implementation changes.
None of these API changes represent breaking changes.

A new OverlappingTLSConfig condition has been added to Gateway Listeners to indicate situations where
Connection Coalescing could be problematic. The Gateway specification for handling Hostname and SNI matching for HTTPS
requests has been clarified and now recommends that implementations return 421 HTTP code responses in certain cases.

• Implementation of GEP-3567 - TLS Updates for Connection Coalescing. (#3630,@robscott)
• Add GEP-3567: Gateway TLS Updates for HTTP/2 Connection Coalescing. (#3572,@robscott)

• The SubjectAltNames field of BackendTLSPolicy changed from Core to Extended feature. (#3591,@mlavacca)

• A new conformance test was added to ensure backendRef filters don't affect weighted routing. (#3604,@dprotaso)

• Set proper reason for Gateway parametersRef Accepted condition when parametersRef is invalid. (#3579,@mlavacca)
• Improve GatewayClass GatewayClassReasonInvalidParameters reason description. (#3553,@mlavacca)

• CEL validation for target references in BackendTLSPolicy. (#3496,@snorwin)

• Increase the GRPCRoute match limit from 8 -> 64 (#3601,@EyalPazz)

A new type GatewaySpecAddress replaces GatewayAddress. In GatewayAddress the Value field was required. In
GatewaySpecAddress the Value field is optional. When the Value is unspecified, if an implementation supports that,
it SHOULD automatically assign an address. If an implementation does not support an empty Value, it MUST set the
Programmed condition in status to false with a reason of "AddressNotAssigned". The Addresses field in
Gateway.Spec has changed from type []GatewayAddress to []GatewaySpecAddress.

• Make the value field in Gateway.Spec.Addresses array optional (#3616,@EyalPazz)

The Standard channel is Gateway API's set of maximally-stable install files.
Only features with the best testing and support are added to the standard
channel. This channel should be considered GA or stable, and future changes will
be fully backwards compatible.

This feature enhances the existing request mirroring feature
by allowing users to specify a percentage of requests to be mirrored in both HTTPRoute
and GRPCRoute objects.

This feature has graduated to Standard and is now considered GA or Stable.

This feature's name for conformance tests (and GatewayClass status reporting) is
HTTPRouteRequestPercentageMirror.

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Promote percentage-based-request-mirroring GEP-3171 to standard (#3638,@LiorLieberman)
• Add conformance tests for percentage-based request mirroring (#3508,@LiorLieberman)

The Experimental Channel is Gateway API's channel for testing out changes and
gaining confidence with them before allowing them to go to Standard.

This channel may include features that are changed or removed later!

This release introduces 2 new experimental resources:

• XBackendTrafficPolicy
• XListenerSet

Both of these resources are described in more detail below. As you may notice,
these resource names start with X and are part of an effort to distinguish
experimental channel resources from standard channel resources.

In addition to the separate names, these resources are also part of the
x-k8s.io API group instead of k8s.io, as a further effort to signal the
experimental nature of these resources.

In practice this means two things:

1. These resources can coexist with standard channel resources
2. Migrating to standard channel will require recreating these resources with
   the standard channel names and API Group (both lacking the "x" prefix)

For more context on this change, refer to the related discussion.

GEP-1767 describes how to add
configuration of CORS filters on HTTPRoute objects, and in this release, this change
has moved to Experimental.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental and should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance testing available for this feature
yet, please check your implementation's documentation to see if it is supported.

Relevant PRs:

• Implementing CORS Filter for HTTPRoute (#3637,@robscott)
• Change HTTPRouteFilter.CORS.AllowCredentials to expect a boolean and not a string (#3656,@EyalPazz)
• Add CORS to HTTPRouteFilterType (#3668,@EyalPazz)

GEP-1713 defines a new mechanism to merge listeners into a single
Gateway, and in this release, this change has moved to Experimental. Following a new naming convention, an
experimental object name is prefaced with an X, thus ListenerSet has changed to XListenerSet.
The object group name has changed from gateway.networking.k8s.io to gateway.networking.x-k8s.io.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental and should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance testing available for this feature
yet, please check your implementation's documentation to see if it is supported.

Relevant PRs:

• Clarified what it means for Gateway Listeners to be distinct (#3477,@youngnick)
• GEP-1713: Standard Mechanism to Merge Multiple Gateways (#3213),@dprotaso)
• Update GEP-1713 - Support attaching ListenerSets across namespaces (#3632,@dprotaso)
• GEP-1713: Standard Mechanism to Merge Multiple Gateways - move GEP Link to Experimental (#3664),@gcs278)
• Refactor codegen scripts to make it easier to generate two clients (#3589,@dprotaso)
• Add ListenerSet GEP-1713 to the website (#3587,@dprotaso)
• Introduces ListenerSet API & Generate Clients (in the group gateway.networking.k8s-x.io) (#3588,@dprotaso)
• The resource ListenerSet has been renamed to XListenerSet. The Resource BackendTrafficPolicy has been renamed to
  XBackendTrafficPolicy. (#3682,[@mlavacca](https://github.com/...

• start-sha: b316db57e63e9a58058880982750dc035a347d6
• end-sha: 7030481

We expect that this release candidate is quite close to the final v1.3.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.3.0-rc.1:

• None has been removed as option for Route Namespaces (was added in rc.1 as
  accidental part of ListenerSet additions). (#3748,@robscott)
• XListenerSet Port is required. (It was already effectively required due to 0
  being an invalid value, but had been marked optional).
  (#3753,@robscott)

• Fixes flake in ExpectMirroredRequest test (#3708,@mhofstetter)
• Revert change to mirror threshold (back to v1.2 state) (#3727,@howardjohn)
• GatewayInfrastructure feature has been marked as "Standard" (#3710,@mlavacca)
• GatewayEmptyAddress feature has been marked as "Standard" (#3711,@mlavacca)

• Small clarification to HTTPRouteMatch rules (#3741,@vehagn)

We expect that this release candidate is quite close to the final v1.3.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.2.0:

This section is intended to be a guide for API changes that might inspire or require implementation changes.
None of these API changes represent breaking changes.

A new OverlappingTLSConfig condition has been added to Gateway Listeners to indicate situations where
Connection Coalescing could be problematic. The Gateway specification for handling Hostname and SNI matching for HTTPS
requests has been clarified and now recommends that implementations return 421 HTTP code responses in certain cases.

• Implementation of GEP-3567 - TLS Updates for Connection Coalescing. (#3630,@robscott)
• Add GEP-3567: Gateway TLS Updates for HTTP/2 Connection Coalescing. (#3572,@robscott)

• The SubjectAltNames field of BackendTLSPolicy changed from Core to Extended feature. (#3591,@mlavacca)

• A new conformance test was added to ensure backendRef filters don't affect weighted routing. (#3604,@dprotaso)

• Set proper reason for Gateway parametersRef Accepted condition when parametersRef is invalid. (#3579,@mlavacca)
• Improve GatewayClass GatewayClassReasonInvalidParameters reason description. (#3553,@mlavacca)

• CEL validation for target references in BackendTLSPolicy. (#3496,@snorwin)

• Increase the GRPCRoute match limit from 8 -> 64 (#3601,@EyalPazz)

A new type GatewaySpecAddress replaces GatewayAddress. In GatewayAddress the Value field was required. In
GatewaySpecAddress the Value field is optional. When the Value is unspecified, if an implementation supports that,
it SHOULD automatically assign an address. If an implementation does not support an empty Value, it MUST set the
Programmed condition in status to false with a reason of "AddressNotAssigned". The Addresses field in
Gateway.Spec has changed from type []GatewayAddress to []GatewaySpecAddress.

• Make the value field in Gateway.Spec.Addresses array optional (#3616,@EyalPazz)

The Standard channel is Gateway API's set of maximally-stable install files.
Only features with the best testing and support are added to the standard
channel. This channel should be considered GA or stable, and future changes will
be fully backwards compatible.

This feature enhances the existing request mirroring feature
by allowing users to specify a percentage of requests to be mirrored in both HTTPRoute
and GRPCRoute objects.

This feature has graduated to Standard and is now considered GA or Stable.

This feature's name for conformance tests (and GatewayClass status reporting) is
HTTPRouteRequestPercentageMirror.

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Promote percentage-based-request-mirroring GEP-3171 to standard (#3638,@LiorLieberman)
• Add conformance tests for percentage-based request mirroring (#3508,@LiorLieberman)

The Experimental Channel is Gateway API's channel for testing out changes and
gaining confidence with them before allowing them to go to Standard.

This channel may include features that are changed or removed later!

GEP-1767 describes how to add
configuration of CORS filters on HTTPRoute objects, and in this release, this change
has moved to Experimental.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental and should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance testing available for this feature
yet, please check your implementation's documentation to see if it is supported.

Relevant PRs:

• Implementing CORS Filter for HTTPRoute (#3637,@robscott)
• Change HTTPRouteFilter.CORS.AllowCredentials to expect a boolean and not a string (#3656,@EyalPazz)
• Add CORS to HTTPRouteFilterType (#3668,@EyalPazz)

GEP-1713 defines a new mechanism to merge listeners into a single
Gateway, and in this release, this change has moved to Experimental. Following a new naming convention, an
experimental object name is prefaced with an X, thus ListenerSet has changed to XListenerSet.
The object group name has changed from gateway.networking.k8s.io to gateway.networking.x-k8s.io.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental and should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance testing available for this feature
yet, please check your implementation's documentation to see if it is supported.

Relevant PRs:

• Clarified what it means for Gateway Listeners to be distinct (#3477,@youngnick)
• GEP-1713: Standard Mechanism to Merge Multiple Gateways (#3213),@dprotaso)
• Update GEP-1713 - Support attaching ListenerSets across namespaces (#3632,@dprotaso)
• GEP-1713: Standard Mechanism to Merge Multiple Gateways - move GEP Link to Experimental (#3664),@gcs278)
• Refactor codegen scripts to make it easier to generate two clients (#3589,@dprotaso)
• Add ListenerSet GEP-1713 to the website (#3587,@dprotaso)
• Introduces ListenerSet API & Generate Clients (in the group gateway.networking.k8s-x.io) (#3588,@dprotaso)
• The resource ListenerSet has been renamed to XListenerSet. The Resource BackendTrafficPolicy has been renamed to
  XBackendTrafficPolicy. (#3682,@mlavacca)

GEP-3388
specifies the configuration of a "retry budget" across all endpoints of a destination service in order to prevent
additional client-side retries after reaching a configured threshold. The budget can be configured using a maximum
percentage of active requests, or an interval during which requests will be considered. In this release, this change has
moved to Experimental. Following a new naming convention, an experimental object name is prefaced with an X, thus
BackendTrafficPolicy has changed to XBackendTrafficPolicy. The object group name has changed from
gateway.networking.k8s.io to `gateway.networking.x...

This is a patch release that fixes the backward incompatibility with the SupportedFeatures feature breaking change introduced in v1.2.0.

• v1.2.0 introduced a breaking change in the SupportedFeatures field of the GatewayClass API. That broke already existing GatewayClasses using the previous version of the feature. The fix to introduce backward compatibility is in (#3454, @LiorLieberman).

This is a patch release that fixes some issues with GRPCRoute v1alpha2 and session
persistence, and backports some improvements on CI and the conformance suite. Details
follow.

• Make GRPCRoute v1alpha2's status a subresource, and restore the previous additional
  printer columns (#3412, @kflynn)
• Allow the header based session persistence not to have AbsoluteTimeout, by relaxing
  CEL validation (#3215, @sanposhiho)

• Perform CEL validation tests for multiple Kubernetes versions (#3417, @mlavacca,
  @robscott)

• Expose the gRPC client interface as a conformance suite option (#3095, @snehachhabria)

On behalf of Kubernetes SIG Network, we are excited to announce the release of v1.2!
This release includes the graduation of 3 features to the standard channel and the introduction of 4 new features to the experimental channel, along with several improvements in many project areas.

As per a previous deprecation notice, in this version, both Experimental
and Standard channel CRDs will no longer serve the v1alpha2 versions
of GRPCRoute and ReferenceGrant.

• Disable v1alpha2 versions for GRPCRoute and ReferenceGrant by @youngnick in
  #3361

Before upgrading to Gateway API v1.2, you'll want to confirm that any
implementations of Gateway API have been upgraded to support the v1 API
version of these resources instead of the v1alpha2 API version. Note that
even if you've been using v1 in your YAML manifests, a controller may still be
using v1alpha2 which would cause it to fail during this upgrade.

Once you've confirmed that the implementations you're relying on have upgraded
to v1, it's time to install the v1.2 CRDs. In most cases, this will work without
any additional effort.

If you ran into issues installing these CRDs, it likely means that you have
v1alpha2 in the storedVersions of one or both of these CRDs. This field is
used to indicate which API versions have ever been used to persist one of these
resources. Unfortunately, this field is not automatically pruned. To check these
values, you can run the following commands:

kubectl get crd grpcroutes.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"
kubectl get crd referencegrants.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"

If either of these return a list that includes "v1alpha2", it means that we need
to manually remove that version from storedVersions.

Before doing that, it would be good to ensure that all your ReferenceGrants and
GRPCRoutes have been updated to the latest storage version:

crds=("GRPCRoutes" "ReferenceGrants")

for crd in "${crds[@]}"; do
  output=$(kubectl get "${crd}" -A -o json)

  echo "$output" | jq -c '.items[]' | while IFS= read -r resource; do
    namespace=$(echo "$resource" | jq -r '.metadata.namespace')
    name=$(echo "$resource" | jq -r '.metadata.name')
    kubectl patch "${crd}" "${name}" -n "${namespace}" --type='json' -p='[{"op": "replace", "path": "/metadata/annotations/migration-time", "value": "'"$(date +%Y-%m-%dT%H:%M:%S)"'" }]'
  done
done

Now that all your ReferenceGrant and GRPCRoute resources have been updated to
use the latest storage version, you can patch the ReferenceGrant and GRPCRoute
CRDs:

kubectl patch customresourcedefinitions referencegrants.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1beta1"]}}'
kubectl patch customresourcedefinitions grpcroutes.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1"]}}'

With these steps complete, upgrading to the latest GRPCRoute and ReferenceGrant
should work well now.

The Experimental supportedFeatures field in GatewayClass status has changed
from being a list of strings to being a list of objects/structs with a name
field.

This is to allow adding in extra information to each entry at a later date.

Relevant PRs:

• SupportedFeatures field in Gateway Class status are now presented as a list of
  objects by @LiorLieberman in
  #3200

There was one small change since RC2 - the Gateway Infrastructure conformance
test has been marked as provisional as we're not sure that the same-namespace
requirement imposed by this test is necessary. #3373

This was our first release using a new release
cycle that is
meant to make Gateway API releases more frequent and predictable.

There are now four phases:

• Scoping: 4-6 weeks, where the maintainers and community determine the set
  of features we want to include in the release. A key deliverable here is
  ensuring that the Experimental channel does not get any bigger than it already
  is; we want to ensure that features make their way to Standard or are removed.
• GEP Iteration and Review: 5-7 weeks, where we work to update GEPs, and
  solidify and meet graduation criteria for in-scope GEPs.
• API Refinement and Documentation: 3-5 weeks, where we translate proposed
  changes from GEPs into changes to both the API specification and
  documentation.
• SIG-Network Review and Release Candidates: 2-4 weeks, where we perform our
  required upstream reviews, get any further required changes in, and release
  our release candidates so that implementations can get started with work on
  the new features asap.

For all the detail about this, please see the Release Cycle
docs.

Relevant PRs:

• Adding Release Cycle Documentation by @robscott in
  #3063

The Standard channel is Gateway API's set of maximally-stable install files.
Only features with the best testing and support are added to the standard
channel. This channel should be considered GA or stable, and future changes will
be fully backwards compatible.

GEP-1867 added an
infrastructure stanza to Gateway objects that is intended to carry
infrastructure configuration specific to that Gateway object.

GEP-1762 adds a section for
labels and annotations to this stanza that specifies labels and annotations
to be annotated to all resources created to fulfill that Gateway request.

This feature can be used to affect the labels and annotations created on
LoadBalancer Services by in-cluster implementations to fulfill the Gateway
contract or by Cloud Load Balancing resources created by Cloud Providers.

This feature has graduated to Standard and is now considered GA or Stable.

This feature's name for conformance tests and GatewayClass status reporting is
GatewayInfrastructurePropagation.

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Remove experimental from gateway infrastructure by @keithmattix in
  #3272
• Validation for label keys and values according to Kubernetes specification by
  @snorwin in #3284

The HTTPRoute Timeouts field on Route Rules has graduated to Standard and is
now considered GA or Stable.

This field allows you to configure overall Request Timeouts as well as Backend
Request Timeouts. For more information, refer to GEP
1742.

The relevant feature names this for conformance tests and GatewayClass status
reporting are:

• HTTPRouteRequestTimeout for httproute.spec.rules[].timeouts.request
• HTTPRouteBackendTimeout for httproute.spec.rules[].timeouts.backendRequest

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Graduate GEP-2257 and GEP-1742 to standard by @kflynn in
  #3210
• GEP2257 Duration parsing by @xtineskim in
  #3271

The previous coordinated work across both Gateway API and upstream Kubernetes
which defined 3 new values for the AppProtocol field on Service Ports has
graduated to Standard and is now considered GA or Stable.

The values are:

• 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.

The relevant feature names this for conformance tests and GatewayClass status
reporting are:

• HTTPRouteBackendProtocolH2C for H2C support, when
  service.spec.ports[].appProtocol is kubernetes.io/h2c.
• HTTPRouteBackendProtocolWebSocket for Websocket support, when
  service.spec.ports[].appProtocol is kubernetes.io/ws or
  kubernetes.io/wss.

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Backend Protocol Selection is no longer experimental and is now part of
  HTTPRoute Extended Conformance by @dprotaso in
  #3108...

This release candidate should be the same as the final v1.2.0 release.

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.2.0-rc1:

As per a previous deprecation notice, in this version, both Experimental
and Standard channel YAMLs will no longer serve the v1alpha2 versions
of GRPCRoute and ReferenceGrant.

For the final release, we will provide pre-upgrade migration instructions
to cover folks who have been using the v1alpha2 versions of these objects.

• Disable v1alpha2 versions for GRPCRoute and ReferenceGrant by @youngnick in
  #3361

• Fix a number of GEP stage errors by @youngnick in
  #3359

• Add conformance suite client options by @BobyMCbobs in
  #3343
• Fix conformance test race condition by @caboteria in
  #3350

We expect that this release candidate is quite close to the final v1.2.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:

This was our first release using a new release cycle that is meant to make Gateway API releases more frequent and predictable.

There are now four phases:

• Scoping: 4-6 weeks, where the maintainers and community determine the set of features we want to include in the release. A key deliverable here is ensuring that the Experimental channel does not get any bigger than it already is; we want to ensure that features make their way to Standard or are removed.
• GEP Iteration and Review: 5-7 weeks, where we work to update GEPs, and solidify and meet graduation criteria for in-scope GEPs.
• API Refinement and Documentation: 3-5 weeks, where we translate proposed changes from GEPs into changes to both the API specification and documentation.
• SIG-Network Review and Release Candidates: 2-4 weeks, where we perform our required upstream reviews, get any further required changes in, and release our release candidates so that implementations can get started with work on the new features asap.

For all the detail about this, please see the Release Cycle docs.

Relevant PRs:

• Adding Release Cycle Documentation by @robscott in #3063

The Standard channel is Gateway API's set of maximally-stable install files. Only features with the best testing and support are added to the standard channel. This channel should be considered GA or stable, and future changes will be fully backwards compatible.

GEP-1867 added an infrastructure stanza to Gateway objects that is intended to carry infrastructure configuration specific to that Gateway object.

GEP-1762 adds a section for labels and annotations to this stanza that specifies labels and annotations to be annotated to all resources created to fulfill that Gateway request.

This feature can be used to affect the labels and annotations created on LoadBalancer Services by in-cluster implementations to fulfill the Gateway contract or by Cloud Load Balancing resources created by Cloud Providers.

This feature has graduated to Standard and is now considered GA or Stable.

This feature's name for conformance tests and GatewayClass status reporting is GatewayInfrastructurePropagation.

This feature's status is Extended, meaning that it is optional for implementations to support. If you're using Experimental Channel, you can refer to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Remove experimental from gateway infrastructure by @keithmattix in #3272
• Validation for label keys and values according to Kubernetes specification by @snorwin in #3284

The HTTPRoute Timeouts field on Route Rules has graduated to Standard and is now considered GA or Stable.

This field allows you to configure overall Request Timeouts as well as Backend Request Timeouts. For more information, refer to GEP 1742.

The relevant feature names this for conformance tests and GatewayClass status reporting are:

• HTTPRouteRequestTimeout for httproute.spec.rules[].timeouts.request
• HTTPRouteBackendTimeout for httproute.spec.rules[].timeouts.backendRequest

This feature's status is Extended, meaning that it is optional for implementations to support. If you're using Experimental Channel, you can refer to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Graduate GEP-2257 and GEP-1742 to standard by @kflynn in #3210
• GEP2257 Duration parsing by @xtineskim in #3271

The previous coordinated work across both Gateway API and upstream Kubernetes which defined 3 new values for the AppProtocol field on Service Ports has graduated to Standard and is now considered GA or Stable.

The values are:

• 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.

The relevant feature names this for conformance tests and GatewayClass status reporting are:

• HTTPRouteBackendProtocolH2C for H2C support, when service.spec.ports[].appProtocol is kubernetes.io/h2c.
• HTTPRouteBackendProtocolWebSocket for Websocket support, when service.spec.ports[].appProtocol is kubernetes.io/ws or
  kubernetes.io/wss.

This feature's status is Extended, meaning that it is optional for implementations to support. If you're using Experimental Channel, you can refer to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

• Backend Protocol Selection is no longer experimental and is now part of HTTPRoute Extended Conformance by @dprotaso in
  #3108

• Increased the limit on HTTPRoute matches from 8 to 64 by @howardjohn in #3205
• Adds the GatewayClassConditionReason "Unsupported" and clarifies when GatewayClassConditionReason "InvalidParameters" should be preferred by @mikemorris in #3048
• HTTPRoute - 503 Status Code MAY be returned for Kubernetes Services who don't have any healthy endpoints by @dprotaso in #3121
• Document the route kinds compatible for each protocolType by @abs007 in #2263
• Move GEP-995 to Implementable by @guicassolato in #3166
• Add policy label to BackendLBPolicy to make it recognizable in gwctl by @gauravkghildiyal in #3195
• remove unnecessary S in ProtocolType validation by @spacewander in #3185

The Experimental Channel is Gateway API's channel for testing out changes and gaining confidence with them before allowing them to go to Standard.

This channel may include features that are changed or removed later!

The Experimental supportedFeatures field in GatewayClass status has changed from being a list of strings to being a list of objects/structs with a name field.

This is to allow addding in extra information to each entry at a later date.

Relevant PRs:

• SupportedFeatures field in Gateway Class status are now presented as a list of objects by @LiorLieberman in #3200

GEP-1731 described how to add configuration of retries on HTTPRoute objects, and in this release, this change has moved to Experimental.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental amd should now be used for testing and verification purposes only. Experimental features may be changed or removed in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for implementations to support.

As there is no feature name or conformance tests available for this feature as yet, please see your implementation's documentation to see if it is supported.

Relevant PRs:

• Adds support for configuring retries in HTTPRoute by @mikemorris in #3301
• Adds retry stanza within HTTPRouteRule to configure retrying unsuccessful requests to backends before sending a response to a client by @mikemorris in #3199

The existing Request Mirroring feature has been enhanced by allowing users to specify a percentage of requests they'd like mirrored. These changes are described in GEP-3171.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental amd should now be used for testing and verification purposes only. Experimental features may be changed or removed in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional f...

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:

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

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

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

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

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

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

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

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

Leading Contributors: @howardjohn

• 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)

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

• 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)

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

• 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)

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:

• 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)

• 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)

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

• 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)

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4