Gateway API Mesh Support Promoted To Stable
The next-generation Kubernetes traffic routing APIs are now Generally Available for service mesh use cases.
We are thrilled to announce that Service Mesh support in the Gateway API is now officially “Stable”! With this release (part of Gateway API v1.1 and Istio v1.22), users can make use of the next-generation traffic management APIs for both ingress (“north-south”) and service mesh use cases (“east-west”).
What is the Gateway API?
The Gateway API is a collection of APIs that are part of Kubernetes, focusing on traffic routing and management.
The APIs are inspired by, and serve many of the same roles as, Kubernetes’ Ingress
and Istio’s VirtualService
and Gateway
APIs.
These APIs have been under development both in Istio, as well as with broad collaboration, since 2020, and have come a long way since then. While the API initially targeted only serving ingress use cases (which went GA last year), we had always envisioned allowing the same APIs to be used for traffic within a cluster as well.
With this release, that vision is made a reality: Istio users can use the same routing API for all of their traffic!
Getting started
Throughout the Istio documentation, all of our examples have been updated to show how to use the Gateway API, so explore some of the tasks to gain a deeper understanding.
Using Gateway API for service mesh should feel familiar both to users already using Gateway API for ingress, and users using VirtualService
for service mesh today.
- Compared to Gateway API for ingress, routes target a
Service
instead of aGateway
. - Compared to
VirtualService
, where routes associate with a set ofhosts
, routes target aService
.
Here is a simple example, which demonstrates routing requests to two different versions of a Service
based on the request header:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: reviews
spec:
parentRefs:
- group: ""
kind: Service
name: reviews
port: 9080
rules:
- matches:
- headers:
- name: my-favorite-service-mesh
value: istio
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
add:
- name: hello
value: world
backendRefs:
- name: reviews-v2
port: 9080
- backendRefs:
- name: reviews-v1
port: 9080
Breaking this down, we have a few parts:
- First, we identify what routes we should match.
By attaching our route to the
reviews
Service, we will apply this routing configuration to all requests that were originally targetingreviews
. - Next,
matches
configures criteria for selecting which traffic this route should handle. - Optionally, we can modify the request. Here, we add a header.
- Finally, we select a destination for the request. In this example, we are picking between two versions of our application.
For more details, see Istio’s traffic routing internals and Gateway API’s Service documentation.
Which API should I use?
With overlapping responsibilities (and names!), picking which APIs to use can be a bit confusing.
Here is the breakdown:
API Name | Object Types | Status | Recommendation |
---|---|---|---|
Gateway APIs | HTTPRoute, Gateway, … | Stable in Gateway API v1.0 (2023) | Use for new deployments, in particular with ambient mode |
Istio APIs | Virtual Service, Gateway | v1 in Istio 1.22 (2024) | Use for existing deployments, or where advanced features are needed |
Ingress API | Ingress | Stable in Kubernetes v1.19 (2020) | Use only for legacy deployments |
You may wonder, given the above, why the Istio APIs were promoted to v1
concurrently?
This was part of an effort to accurate categorize the stability of the APIs.
While we view Gateway API as the future (and present!) of traffic routing APIs, our existing APIs are here to stay for the long run, with full compatibility.
This mirrors Kubernetes’ approach with Ingress
, which was promoted to v1
while directing future work towards the Gateway API.
Community
This stability graduation represents the culmination of countless hours of work and collaboration across the project. It is incredible to look at the list of organizations involved in the API and consider back at how far we have come.
A special thanks goes out to my co-leads on the effort: Flynn, Keith Mattix, and Mike Morris, as well as the countless others involved.
Interested in getting involved, or even just providing feedback? Check out Istio’s community page or the Gateway API contributing guide!