Authors: Shane Utt (Kong), Rob Scott (Google), Nick Young (VMware), Jeff Apple (HashiCorp)
We are excited to announce the v0.5.0 release of Gateway API. For the first
time, several of our most important Gateway API resources are graduating to
beta. Additionally, we are starting a new initiative to explore how Gateway API
can be used for mesh and introducing new experimental concepts such as URL
rewrites. We’ll cover all of this and more below.
What is Gateway API?
Gateway API is a collection of resources centered around Gateway resources
(which represent the underlying network gateways / proxy servers) to enable
robust Kubernetes service networking through expressive, extensible and
role-oriented interfaces that are implemented by many vendors and have broad
Originally conceived as a successor to the well known Ingress API, the
benefits of Gateway API include (but are not limited to) explicit support for
many commonly used networking protocols (e.g.
well as tightly integrated support for Transport Layer Security (TLS). The
Gateway resource in particular enables implementations to manage the lifecycle
of network gateways as a Kubernetes API.
If you’re an end-user interested in some of the benefits of Gateway API we
invite you to jump in and find an implementation that suits you. At the time of
this release there are over a dozen implementations for popular API
gateways and service meshes and guides are available to start exploring quickly.
Gateway API is an official Kubernetes API like
Gateway API represents a superset of Ingress functionality, enabling more
advanced concepts. Similar to Ingress, there is no default implementation of
Gateway API built into Kubernetes. Instead, there are many different
implementations available, providing significant choice in terms of underlying
technologies while providing a consistent and portable experience.
Take a look at the API concepts documentation and check out some of
the Guides to start familiarizing yourself with the APIs and how they
work. When you’re ready for a practical application open the implementations
page and select an implementation that belongs to an existing technology
you may already be familiar with or the one your cluster provider uses as a
default (if applicable). Gateway API is a Custom Resource Definition
(CRD) based API so you’ll need to install the CRDs onto a
cluster to use the API.
If you’re specifically interested in helping to contribute to Gateway API, we
would love to have you! Please feel free to open a new issue on the
repository, or join in the discussions. Also check out the community
page which includes links to the Slack channel and community meetings.
Graduation to beta
v0.5.0 release is particularly historic because it marks the growth in
maturity to a beta API version (
v1beta1) release for some of the key APIs:
This achievement was marked by the completion of several graduation criteria:
- API has been widely implemented.
- Conformance tests provide basic coverage for all resources and have multiple implementations passing tests.
- Most of the API surface is actively being used.
- Kubernetes SIG Network API reviewers have approved graduation to beta.
For more information on Gateway API versioning, refer to the official
documentation. To see
what’s in store for future releases check out the next steps
This release introduces the
standard release channels
which enable a better balance of maintaining stability while still enabling
experimentation and iterative development.
standard release channel includes:
- resources that have graduated to beta
- fields that have graduated to standard (no longer considered experimental)
experimental release channel includes everything in the
- fields that are considered experimental and have not graduated to
Release channels are used internally to enable iterative development with
quick turnaround, and externally to indicate feature stability to implementors
For this release we’ve added the following experimental features:
For an exhaustive list of changes included in the
v0.5.0 release, please see
the v0.5.0 release notes.
Gateway API for service mesh: the GAMMA Initiative
Some service mesh projects have already implemented support for the Gateway
API. Significant overlap
between the Service Mesh Interface (SMI) APIs and the Gateway API has inspired
discussion in the SMI
We are pleased to announce that the service mesh community, including
representatives from Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX
Service Mesh and Open Service Mesh, is coming together to form the GAMMA
Initiative, a dedicated
workstream within the Gateway API subproject focused on Gateway API for Mesh
Management and Administration.
This group will deliver enhancement
of resources, additions, and modifications to the Gateway API specification for
mesh and mesh-adjacent use-cases.
This work has begun with an exploration of using Gateway API for
and will continue with enhancement in areas such as authentication and
As we continue to mature the API for production use cases, here are some of the highlights of what we’ll be working on for the next Gateway API releases:
- GRPCRoute for gRPC traffic routing
- Route delegation
- Layer 4 API maturity: Graduating TCPRoute, UDPRoute and
TLSRoute to beta
- GAMMA Initiative – Gateway API for Service Mesh
If there’s something on this list you want to get involved in, or there’s
something not on this list that you want to advocate for to get on the roadmap
please join us in the #sig-network-gateway-api channel on Kubernetes Slack or our weekly community calls.
Originally posted on Kubernetes – Production-Grade Container Orchestration