A few days ago, Gateway API announced that it supports service mesh[1] in 0.8.0, which means that GAMMA[2] (Gateway API for Mesh Management and Administration) has made new progress, although it is still in the experimental stage. When Gateway API 0.5.0 was released in June last year, I also wrote an article What does the GAMMA initiative of SMI and Gateway API mean? [3]. Today, SMI as the annual review of the sandbox project has not been submitted for several months [4], which is sad.

Without further ado, let’s take a look at how the Gateway API under 0.8.0 works in Service Mesh.

TL;DR

The Gateway API's support for service mesh is still in the experimental stage, but some manufacturers have followed up (of course they are all in the experimental stage).

Compared with the Gateway API, which processes north-south traffic and binds routing to Gateway resources [5], routing in the grid is bound to Service. Simply understood, Service acts as a proxy for Gateway, but the Service is the target Service.

Service mesh in Gateway API

To talk about service mesh, let’s first look at service Service.

Abstract Service

Service is an independent resource in Kubernetes. The abstraction mentioned here is logically abstracted into front-end and back-end parts.

The frontend (Frontend) is usually the DNS name or ClusterIP of the Service; the backend (Backend) is the Endpoint or EndpointSlice selected through the label selector.

picture

Routing and Services

picture

Binding the route directly to the Service is considered to be the best choice at the moment. The coupling degree between Service and other resources is too high, such as IP allocation, DNS, endpoint collection, load balancing, etc., but it is also the only optimal choice in the current grid design. In the future, we will seek better options, such as ServiceBinding ( (see below)

The advantage of this is that the front and back ends of the service are respectively associated with parentRef and backendRef in the current xRoute API, without introducing additional APIs.

At different times, the backendRef in the xRoute API can also be a Service, but in the end when routing the request, the target is still Endpoint or EndpointSlice, but they are not strongly related to the Service in parentRef.

kind: HTTPRoute
metadata:
  name: smiley-route
  namespace: faces
spec:
  parentRefs:
    - name: smiley
      kind: Service
      group: core
      port: 80
  rules:
    ...
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

If multiple routes are configured on a Service, requests matching multiple routes will be rejected.

Request process

1. Client sends request
2. Grid data plane proxy intercepts requests
3. Confirm which Service the traffic belongs to by virtual IP address, DNS hostname, or name (the hostname field on xRoute will not be used)
4. If the Service does not have a route configured, the original destination of the request will be used for forwarding.
5. Find the matching route with the highest priority (consumer route is higher than producer route, see below) and forward it
6. If routes are configured and none match, the request will be rejected.

Route namespace

The reason why we mention namespace is because routes and services have different meanings in the same or different namespaces.

Same namespace

Route smiley-route and Service smiley are in the same namespace faces, and the request timeout is set to 100ms on this route. This means that all requests to Service smiley (from any workload under any namespace) and matching the smiley-route routing rule are affected by this timeout configuration.

This route is called a Producer Route [6] and affects all requests targeting the service.

kind: HTTPRoute
metadata:
  name: smiley-route
  namespace: faces
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 100ms
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

different namespaces

Route smiley-route and Service smiley are located in different namespaces. Different from the above, all requests that access Service smiley (from any workload under the namespace fast-clients) and match the smiley-route routing rules are subject to this Effect of timeout configuration.

This kind of route is called Consumer Route [7], which affects all requests to access the wood carving service under the same namespace.

kind: HTTPRoute
metadata:
  name: smiley-route
  namespace: fast-clients
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 100ms
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

picture

Multiple routes on the same Service

The prerequisite here is that these routes are all located in the same namespace, that is, they are both producer routes or consumer routes. In this case, multiple routes will be merged according to the route merging rules [8]. If you want to configure different consumer routes for multiple workloads under the same namespace, it is currently not possible. only

For example, two consumer routes smiley-route-50 and smiley-route-100 are defined below.

kind: HTTPRoute
metadata:
  name: smiley-route-50
  namespace: fast-clients
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 50ms
---
kind: HTTPRoute
metadata:
  name: smiley-route-100
  namespace: fast-clients
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 100ms
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
twenty one.
twenty two.
twenty three.
twenty four.
25.
26.
27.
28.
29.
30.
31.

Routing and policy

I have written an article before to introduce the policies in the Gateway API. If you are interested, you can read the article Understanding the Policy Attachment of the Kubernetes Gateway API[9].

Policy attachment can be very simple in the grid. A policy can be applied to any resource in any namespace, but if the target is in a different namespace, it can only be applied to requests from the same namespace (following the logic of consumer routing).

picture

Grid conformance testing

First, let’s take a look at what a consistency configuration file is[10]:

The Gateway API will provide configuration files for conformance testing, and these configuration files can be selected when running the consistency test. Conformance results are then reported back to the Gateway API project and certified (such as a badge). In addition to testing the core functions, you can also add extended functions in the manufacturer's specific implementation for testing.

The implementation of these Gateway APIs will submit test reports to the consistency test report directory [11] of the official warehouse, which can be used as one of the basis for everyone's selection.

Currently there are HTTP, TLS, and TLSPassthrough (basically organized according to xRoute, so there will also be GRPC, TCP, and UDP in the future). For service mesh, the `mesh` configuration file was also proposed [12].

The official blog [13] mentioned that the Gateway API implementations in Kuma 2.3+, Linkerd 2.14+, and Istio 1.16+ have all passed the mesh consistency test, but no test reports have been seen so far, and they are probably still being uploaded.

References

[1] Gateway API announced support for service mesh in 0.8.0: https://gateway-api.sigs.k8s.io/blog/2023/0829-mesh-support/#service-mesh-support-in-gateway -api

[2] GAMMA: https://gateway-api.sigs.k8s.io/concepts/gamma/

[3] What does the GAMMA initiative of SMI and Gateway API mean? : https://atbug.com/why-smi-collaborating-in-gateway-api-gamma/

[4] Still not submitted after several months: https://github.com/servicemeshinterface/smi-spec/issues/254

[5] Gateway resources: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.Gateway

[6] Producer Route: https://gateway-api.sigs.k8s.io/concepts/glossary#producer-route

[7] Consumer Route: https://gateway-api.sigs.k8s.io/concepts/glossary#consumer-route

[8] Route merging rules: https://gateway-api.sigs.k8s.io/api-types/httproute#merging

[9] Understand the Policy Attachment of Kubernetes Gateway API in one article: https://atbug.com/explore-k8s-gateway-api-policy-attachment/

[10] Consistency configuration file: https://gateway-api.sigs.k8s.io/geps/gep-1709/

[11] Conformance test report directory of the official warehouse: https://github.com/kubernetes-sigs/gateway-api/tree/main/conformance/reports

[12] mesh configuration file: https://gateway-api.sigs.k8s.io/geps/gep-1686/

[13] Official blog: https://gateway-api.sigs.k8s.io/blog/2023/0829-mesh-support/