Explore how Gateway API works in Service Mesh

A few days ago, Gateway API announced that it supports service mesh in 0.8.0 , which means that GAMMA ( Gateway A PI 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 last June, I also wrote an article What does the GAMMA initiative of SMI and Gateway API mean? . Nowadays, SMI as the annual review of the sandbox project has not been submitted for several months , which is 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 manufacturers have followed up (of course they are all in the experimental stage).

Compared with the Gateway API that processes north-south traffic and binds routes to Gateway resources , routes in the grid are bound to Services. Simply understood, Service acts as a proxy for Gateway, but the Service is the target Service.

Service Mesh in Gateway API

To talk about the service grid, let's first look at the service Service.

abstract`Service`

ServiceKubernetes is an independent resource. The abstraction mentioned here is logically abstracted into two parts: front-end and back-end.

The frontend (Frontend) is usually Servicethe DNS name of or ClusterIP; the backend (Backend) is selected through the tag selector Endpointor EndpointSlice.

Routing and Services

Binding the route directly to the Service is considered to be the best choice at the moment . ServiceThe coupling degree with 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 (see below ServiceBinding) arts)

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

At different times, xRoutethe in the API backendRefcan also be one Service, but in the end when routing the request, the target is still Endpointor EndpointSlice, but they are not strongly related to parentRefthe in .Service

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 matching multiple routes will be rejected.

Request process

Client sends request
Grid data surface proxy intercepts requests
Confirm which traffic belongs to it by virtual IP address, DNS host name, or name Service( the field xRouteon will not be used hostname)
If Serviceno route is configured, the original destination of the request will be used for forwarding
Find the matching route with the highest priority (consumer route is higher than producer route, see below) and forward it
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

The route is in the same namespace smiley-routeas the Service , and the request timeout is set on the route . This means that all requests that access the Service (from any workload under any namespace) and match the routing rules are affected by this timeout configuration.smileyfaces100mssmileysmiley-route

This route is called a Producer Route 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

different namespaces

Routing smiley-routeand Service smileyare located in different namespaces. Different from the above, all requests that access Service (from any workload under smileythe namespace ) and match routing rules are affected by this timeout configuration.fast-clientssmiley-route

This kind of route is called Consumer Route and 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

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 . If you want to configure different consumer routes for multiple workloads in the same namespace , it is currently not possible. only

For example, the following defines two consumer routes smiley-route-50andsmiley-route-100

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 strategy

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

Attaching policies to a grid can be very simple. 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).

Grid conformance testing

Let's first look at what is a consistency configuration file :

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 of the official warehouse , which can be used as one of the basis for everyone's selection.

Currently, there are HTTP, TLS, TLSPassthrough(basically organized based on xRoute, so there will be GRPC, TCP, in the future UDP). For service mesh, meshconfiguration files are also proposed .

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