Gateway API Mesh Support Promoted To Stable

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 a Gateway.
• Compared to VirtualService, where routes associate with a set of hosts, routes target a Service.

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 targeting reviews.
• 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:

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!