Explore how Gateway API works in Service Mesh

A few days ago, Gateway API announced that it would support service mesh in 0.8.0[1]. This 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 released 0.5.0 last June, I also wrote an article about what SMI and the GAMMA initiative of Gateway API mean? [3]. Now, SMI has been in the annual review of the sandbox project for several months and has not been submitted yet[4]. What a pity.

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 vendors have already followed up (of course, it is still in the experimental stage).

Compared to the Gateway API, which handles north-south traffic by binding routes to Gateway resources[5], routes in the mesh are bound to Services. In simple terms, Services proxy the role of Gateway, but the Service is the target Service.

Service Mesh in Gateway API

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

Abstract Service

Service is an independent resource in Kubernetes. The abstraction here refers to logical abstraction, which is abstracted into two parts: front-end and back-end.

The frontend is usually the DNS name or ClusterIP of the Service; the backend is the Endpoint or EndpointSlice selected by the label selector.

picture

Routing and Services

picture

Binding the route directly to the Service is considered the best option at present. The Service is too tightly coupled with other resources, such as IP allocation, DNS, endpoint set, load balancing, etc. However, it is also the only best option in the current grid design. In the future, we will seek better options, such as ServiceBinding (see below).

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

Different times, the backendRef in the xRoute API can also be a Service, but when routing the request, the target is still Endpoint or EndpointSlice, but they are not strongly associated with the Service in parentRef.

 kind: HTTPRoute metadata: name: smiley-route namespace: faces spec: parentRefs: - name: smiley kind: Service group: core port: 80 rules: ...

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

Request Process

1. Client sends request
2. Grid Data Plane Proxy intercepts requests
3. Identify the Service to which the traffic belongs by virtual IP address, DNS hostname, or name (the hostname field on xRoute is not used)
4. If the Service has no routing 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) for forwarding
6. If routes are configured but none match, the request is rejected

Routing namespace

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

Same namespace

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

This type of routing is called a producer route[6] and affects all requests destined for that 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

Different namespaces

The route smiley-route and Service smiley are in different namespaces. What is different from the above is that all requests accessing Service smiley (from any workload under the namespace fast-clients ) and matching the routing rule of smiley-route are affected by the timeout configuration.

This type of routing is called consumer routing [7] and affects all requests to the wood carving service in 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

picture

Multiple Routes on the Same Service

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

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

Routing and Policy

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

Policy attachment can be very simple in a mesh. 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 coming from the same namespace (following the logic of consumer routing).

picture

Grid consistency testing

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

The Gateway API provides configuration files for conformance testing, which can be selected when running conformance tests. The conformance results are then reported back to the Gateway API project and certified (e.g., badges). In addition to testing core functions, you can also add extended functions in the vendor's specific implementation for testing.

These Gateway API implementations will submit test reports to the consistency test report directory of the official repository [11], which can be used as one of the bases for selection.

Currently, there are HTTP, TLS, and TLSPassthrough (basically they are organized according to xRoute, so there will be GRPC, TCP, and UDP in the future). For service mesh, a `mesh` profile has also been 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 SMI and Gateway API GAMMA initiative mean?: https://atbug.com/why-smi-collaborating-in-gateway-api-gamma/

[4] Still no commit 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] Understanding Kubernetes Gateway API Policy Attachment 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] Official repository for conformance test reports: 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/