Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
APACHE-2.0 License
Bot releases are hidden (Show)
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 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.
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.
There are several exciting new experimental features in this release:
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 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 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
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 inkubernetes.io/ws
- WebSocket over cleartext as described inkubernetes.io/wss
- WebSocket over TLS as described inThese 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.
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
Of course there's a lot more in this release:
distinct
(#2436,supportedFeatures
field has beenGatewayReasonUnsupportedAddress
for Accepted
now ONLYGateway
which it does notGatewayReasonAddressNotAssigned
for Programmed
nowGatewayReasonAddressNotUsable
for Programmed
has beenErrorf
instead of Fatalf
. (#2361, @yylt)ReferenceGrant
from v1
to v1beta1
in theGatewaySecretInvalidReferenceGrant
conformance test YAML (#2494, @arkodg)ExemptFeatures
field for Experimental Conformance Profilesgateway-system
gateway-api-admission-server
deployment have been removedwebhook-install.yaml
in case you would like to optionally install them.Published by youngnick 12 months ago
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:
ReferenceGrant
from v1
to v1beta1
in theGatewaySecretInvalidReferenceGrant
conformance test YAML (#2494, @arkodg)ExemptFeatures
field for Experimental Conformance ProfilesPublished by robscott about 1 year ago
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 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.
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.
There are several exciting new experimental features in this release:
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 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 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
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 inkubernetes.io/ws
- WebSocket over cleartext as described inkubernetes.io/wss
- WebSocket over TLS as described inThese 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.
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
Of course there's a lot more in this release:
distinct
(#2436,supportedFeatures
field has beenGatewayReasonUnsupportedAddress
for Accepted
now ONLYGateway
which it does notGatewayReasonAddressNotAssigned
for Programmed
nowGatewayReasonAddressNotUsable
for Programmed
has beenErrorf
instead of Fatalf
. (#2361, @yylt)gateway-system
gateway-api-admission-server
deployment have been removedwebhook-install.yaml
in case you would like to optionally install them.Published by youngnick about 1 year ago
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.
Published by shaneutt about 1 year ago
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.
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:
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.
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.
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.
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 servedv1alpha2
of ReferenceGrant is deprecatedv1beta1
is now the storage version for ReferenceGrantThose changes mean that:
v1alpha2
ofv1beta1
.v1alpha2
ofv1beta1
.For more information, refer to
#2069.
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.
--skip-tests
flag has been added to the conformance CLI to enable testsgo test
. (#2066, @mlavacca)Full Changelog: https://github.com/kubernetes-sigs/gateway-api/compare/v0.7.0...v0.8.0
Published by shaneutt about 1 year ago
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:
Full Changelog: https://github.com/kubernetes-sigs/gateway-api/compare/v0.8.0-rc1...v0.8.0-rc2
Published by robscott about 1 year ago
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.
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.
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:
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.
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.
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.
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 servedv1alpha2
of ReferenceGrant is deprecratedv1beta1
is now the storage version for ReferenceGrantThose changes mean that:
v1alpha2
ofv1beta1
.v1alpha2
ofv1beta1
.For more information, refer to
#2069.
--skip-tests
flag has been added to the conformance CLI to enable testsgo test
. (#2066, @mlavacca)Published by robscott over 1 year ago
This is a patch release that includes small fixes, clarifications, and
conformance tests as a follow up to the v0.7.0 release.
Published by robscott over 1 year ago
The v0.7.0 release focuses on refining and stabilizing existing APIs. This
included a focus on both conformance tests and clarifying ambiguous parts of the
API spec.
In addition to those broad focuses, 2 features are graduating to the
standard channel:
There are a lot of interesting GEPs in the pipeline right now, but only some of
these GEPs have made it to experimental status in time for v0.7.0. The GEPs
highlighted below are both in an experimental state and are either entirely new
(GEP-1748) or had significant new concepts introduced (GEP-713):
This GEP received a major update, splitting policy attachment into two
categories "Direct" and "Inherited". The new "Direct" mode enables a simplified
form of policy attachment for targeting a single resource (#1565, @youngnick).
A new GEP was introduced to define how Gateway API interacts with Multi-Cluster
Services. At a high level, this states that ServiceImports have "Extended"
support and can be used anywhere Services can throughout the API. There's a lot
more nuance here, so for the full details, refer to the GEP. (#1843, @robscott)
gateway-exists-finalizer.gateway.networking.k8s.io
finalizer is noEnableAllSupportedFeatures
enables allall-features
flag to enable all supported feature conformance tests.Published by robscott over 1 year ago
We expect this to be our final release candidate before launching v0.7.0. This
release candidate includes a variety of clarifications and conformance updates.
The changelog below represents the changes since v0.7.0-rc1.
Published by robscott over 1 year ago
gateway-exists-finalizer.gateway.networking.k8s.io
finalizer is noEnableAllSupportedFeatures
enables allall-features
flag to enable all supported feature conformance tests.Published by shaneutt over 1 year ago
API versions: v1beta1
, v1alpha2
This is a patch release that predominantly includes updated conformance tests
for implementations to implement.
For all major changes since the v0.5.x
release series, please see the
v0.6.0 release notes.
HTTPRouteInvalidCrossNamespaceParentRef
conformance test now checks forNotAllowedByListeners
reason on the HTTPRoute
's Accepted: false
HTTPRoute
to cover the behavior of aSectionName
similar to what was already present forListenerPort
.ObservedGeneration
AttachedRoutes
testing to conformance tests.Published by shaneutt over 1 year ago
API versions: v1beta1
, v1alpha2
This is a patch release that predominantly includes updated conformance tests
for implementations to implement.
For all major changes since the v0.5.x
release series, please see the
v0.6.0 release notes.
net/http
default client in conformance test suiteFull Changelog: https://github.com/kubernetes-sigs/gateway-api/compare/v0.6.0...v0.6.1
Published by shaneutt almost 2 years ago
API versions: v1beta1
, v1alpha2
v1beta1
, ReferencePolicy removedWith more implementations now supporting ReferenceGrant (and more conformance coverage of the resource), we've moved ReferenceGrant to v1beta1
in this release. Note that moving to beta also moves the object to the Standard channel (it was Experimental previously).
We've also removed the already-deprecated ReferencePolicy resource, so please move over to the shiny new ReferenceGrant, which has all the same features.
The GRPCRoute
resource has been introduced in order to simplify the routing of GRPC requests.
Its design is described in GEP-1016.
As it is a new resource, it is introduced in the experimental channel.
Thanks to @gnossen for pushing this ahead.
As described in GEP-1364, status conditions have been updated within the Gateway resource to make it more consistent with the rest of the API. These changes, along with some other status changes, are detailed below.
Gateway:
Accepted
and Programmed
conditions introduced.Scheduled
condition deprecated.Accepted
and Programmed
.Ready
.Gateway Listener:
Accepted
and Programmed
conditions introduced.Detached
condition deprecated.Accepted
, Programmed
, ResolvedRefs
, and Conflicted
.Ready
.All Resources:
Accepted
Condition now has a Pending
reason, which is the default untilRoute resources:
Accepted
Condition now has a NoMatchingParent
reason, to be set on routesThe purpose of these changes is to make the status flows more consistent across objects, and to provide a clear pattern for new objects as we evolve the API.
Note: This change will require updates for implementations to be able to pass conformance tests. Implementations may choose to publish both new and old conditions, or only new conditions.
Accepted
and deprecates Detached
Listener conditions and reasons (#1446, @mikemorris)Accepted
and deprecates Scheduled
Gateway conditions and reasons (#1447, @mikemorris)Pending
reason for use with all Accepted
conditions throughout the API (#1453, @youngnick)Programmed
Gateway and Listener conditions, moves Ready
to extendedRouteReasonNoMatchingParent
reason for Accepted
condition. (#1516, @pmalek)responseHeaderModifier
is added to .spec.rules.filters
, whichRegularExpression
type selectors have been clarified to all beImplementationSpecific
conformance. (#1604, @youngnick)arm64
in addition to amd64
for ourv1alpha2
Go types are now aliases to their v1beta1
versionsFull Changelog: https://github.com/kubernetes-sigs/gateway-api/compare/v0.5.0...v0.6.0
Published by shaneutt almost 2 years ago
We expect this to be our final release candidate before launching v0.6.0. This
release candidate includes a variety of cleanup and documentation updates. The
changelog below represents the changes since v0.6.0-rc1.
kubectl get gateways
. (#1602, @skriss)RegularExpression
type selectors have been clarified to all beImplementationSpecific
conformance. (#1604, @youngnick)Full Changelog: https://github.com/kubernetes-sigs/gateway-api/compare/v0.6.0-rc1...v0.6.0-rc2
Published by youngnick almost 2 years ago
v1beta1
, ReferencePolicy removedWith more implementations now supporting ReferenceGrant (and more conformance coverage of the resource), we've moved ReferenceGrant to v1beta1
in this release. Note that moving to beta also moves the object to the Standard channel (it was Experimental previously).
We've also removed the already-deprecated ReferencePolicy resource, so please move over to the shiny new ReferenceGrant, which has all the same features.
The GRPCRoute
resource has been introduced in order to simplify the routing of GRPC requests.
Its design is described in GEP-1016.
As it is a new resource, it is introduced in the experimental channel.
Thanks to @gnossen for pushing this ahead.
As described in GEP-1364, status conditions have been updated within the Gateway resource to make it more consistent with the rest of the API. These changes, along with some other status changes, are detailed below.
Gateway:
Accepted
and Programmed
conditions introduced.Scheduled
condition deprecated.Accepted
and Programmed
.Ready
.Gateway Listener:
Accepted
and Programmed
conditions introduced.Detached
condition deprecated.Accepted
, Programmed
, ResolvedRefs
, and Conflicted
.Ready
.All Resources:
Accepted
Condition now has a Pending
reason, which is the default untilRoute resources:
Accepted
Condition now has a NoMatchingParent
reason, to be set on routesThe purpose of these changes is to make the status flows more consistent across objects, and to provide a clear pattern for new objects as we evolve the API.
Note: This change will require updates for implementations to be able to pass conformance tests. Implementations may choose to publish both new and old conditions, or only new conditions.
Accepted
and deprecates Detached
Listener conditions and reasons (#1446, @mikemorris)Accepted
and deprecates Scheduled
Gateway conditions and reasons (#1447, @mikemorris)Pending
reason for use with all Accepted
conditions throughout the API (#1453, @youngnick)Programmed
Gateway and Listener conditions, moves Ready
to extendedRouteReasonNoMatchingParent
reason for Accepted
condition. (#1516, @pmalek)responseHeaderModifier
is added to .spec.rules.filters
, whichv1alpha2
Go types are now aliases to their v1beta1
versionsutils
package to a new package namedtranslator
. (#1337, @carlisia)API versions: v1beta1, v1alpha2
This release includes a number of bug fixes and clarifications:
Published by robscott about 2 years ago
API versions: v1beta1, v1alpha2
This release includes a number of bug fixes and clarifications:
Published by shaneutt over 2 years ago
API versions: v1beta1, v1alpha2
This release is all about stability.
Changes in this release can largely be divided into the following categories:
Note: This release is largely identical to v0.5.0-rc2, this changelog tracks
the difference between v0.5.0 and v0.4.3.
In this release, we've made two release channels available, experimental
and
standard
.
The experimental
channel contains all resources and fields, while standard
contains only resources that mave moved to beta status.
We've also added a way to flag particular fields within a resource as
experimental, and any fields marked in this way are only present in the
experimental
channel. Please see the versioning docs for a more
detailed explanation.
One caveat for the standard channel - due to work on the new ReferenceGrant
resource: conformance tests may not pass with the standard
set of CRDs.
The following APIs have been promoted to a v1beta1
maturity:
GatewayClass
Gateway
HTTPRoute
Gateway
listeners by port numbergateway.networking.k8s.io/bundle-version
andgateway.networking.k8s.io/channel
annotations.Namespace
could be unspecified in ReferencePolicy
kubectl get gatewayclasses
conformance/
directory.GatewayClass
kubectl get
output.RouteConditionReason
types RouteReasonNotAllowedByListeners
andRouteReasonNoMatchingListenerHostname
were added.RouteConditionReason
type added with RouteReasonAccepted
,RouteReasonResolvedRefs
and RouteReasonRefNotPermitted
constants.HTTPPathModifier
.gateway-system
namespacegateway-api
.NamedAddress
value for Gateway
's spec.addresses[].type
field hasexample.com/NamedAddress
) has been added instead to better represent the500
instead of 503
responses whenThe following are breaking changes related to status updates and end-user
experience changes.
UnsupportedExtension
named ListenerConditionReason
has been removed.RouteConflict
named ListenerConditionReason
has been removed.These changes will only affect implementations. Implementors will need to adjust
for the type changes when updating the Gateway API dependency in their projects.
NOTE: These kinds of changes are not always present in the CHANGELOG so
please be aware that the CHANGELOG is not an exhaustive list of Go
type changes. In this case there were a significant number of changes
in a single release, so we included them for extra visibility for
implementors.
ReferencePolicy
has been renamed to ReferenceGrant
.GatewayTLSConfig
's CertificateRefs
field is now a slice of pointers toHTTPPathModifer
field Absolute
renamed to ReplaceFullPath
ParentRef
type was renamed to ParentReference
ConditionRouteAccepted
and ConditionRouteResolvedRefs
are nowRouteConditionAccepted
& RouteConditionResolvedRefs
Published by robscott over 2 years ago
API versions: v1beta1, v1alpha2
We expect this to be our final release candidate before launching v0.5.0. This
release candidate includes a variety of cleanup and documentation updates.
Published by robscott over 2 years ago
The working group expects that this release candidate is quite close to the final v0.5.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.
API versions: v1beta1, v1alpha2
Changes in this release can largely be divided into the following categories:
In this release, we've made two release channels available, experimental
and
standard
.
The experimental
channel contains all resources and fields, while standard
contains only resources that mave moved to beta status.
We've also added a way to flag particular fields within a resource as
experimental, and any fields marked in this way are only present in the
experimental
channel. Please see the versioning docs for a more
detailed explanation.
One caveat for the standard channel - due to work on the new ReferenceGrant
resource: conformance tests may not pass with the standard
set of CRDs.
The following APIs have been promoted to a v1beta1
maturity:
GatewayClass
Gateway
HTTPRoute
Gateway
listeners by port numbergateway.networking.k8s.io/bundle-version
andgateway.networking.k8s.io/channel
annotations.Namespace
could be unspecified in ReferencePolicy
kubectl get gatewayclasses
conformance/
directory.GatewayClass
kubectl get
output.RouteConditionReason
types RouteReasonNotAllowedByListeners
andRouteReasonNoMatchingListenerHostname
were added.RouteConditionReason
type added with RouteReasonAccepted
,RouteReasonResolvedRefs
and RouteReasonRefNotPermitted
constants.HTTPPathModifier
.gateway-system
namespacegateway-api
.NamedAddress
value for Gateway
's spec.addresses[].type
field hasexample.com/NamedAddress
) has been added instead to better represent the500
instead of 503
responses whenThe following are breaking changes related to status updates and end-user
experience changes.
UnsupportedExtension
named ListenerConditionReason
has been removed.RouteConflict
named ListenerConditionReason
has been removed.These changes will only affect implementations. Implementors will need to adjust
for the type changes when updating the Gateway API dependency in their projects.
NOTE: These kinds of changes are not always present in the CHANGELOG so
please be aware that the CHANGELOG is not an exhaustive list of Go
type changes. In this case there were a significant number of changes
in a single release, so we included them for extra visibility for
implementors.
ReferencePolicy
has been renamed to ReferenceGrant
.GatewayTLSConfig
's CertificateRefs
field is now a slice of pointers toHTTPPathModifer
field Absolute
renamed to ReplaceFullPath
ParentRef
type was renamed to ParentReference
ConditionRouteAccepted
and ConditionRouteResolvedRefs
are nowRouteConditionAccepted
& RouteConditionResolvedRefs