前幾天 Gateway API 宣布在 0.8.0 中支持服務網格[1]，這意味著 GAMMA[2]（Gateway API for Mesh Management and Administration）有了新進展，雖然目前還是實驗階段。去年 6 月 Gateway API 發布 0.5.0 時，我還寫了一篇 SMI 與 Gateway API 的 GAMMA 倡議意味著什么？[3]。如今，SMI 作為 sandbox 項目的年度審查已經 過了幾個月仍未提交[4]，唏噓。

廢話不多說，我們來看下 0.8.0 下的 Gateway API 如何在 Service Mesh 中工作。

TL;DR

Gateway API 對服務網格的支持仍然是實驗階段，但是已經有廠商跟進（當然也都是實驗階段）。

相比 Gateway API 處理南北向流量將路由綁定到 Gateway 資源[5] 相比，在網格中路由則是與 Service 進行綁定。簡單理解成 Service 代理了 Gateway 的角色，不過該 Service 是目標 Service。

Gateway API 中的服務網格

要說服務網格，我們先來看下服務 Service。

抽象 Service

Service 中 Kubernetes 中是一個獨立的資源，這里說的抽象是從邏輯上進行抽象，抽象成前端和后端兩部分。

前端（Frontend）通常就是 Service 的 DNS 名字或者 ClusterIP；后端（Backend）則是通過標簽選擇器選擇的 Endpoint 或者 EndpointSlice。

圖片

路由與服務

圖片

把路由直接綁定到 Service 上，被認為是當下最優的選擇。Service 與其他資源的耦合度太高，比如 IP 分配、DNS、端點集合、負載均衡等等，但在目前的網格設計中也是唯一的最優選擇，未來會尋求更好的選擇，比如 ServiceBinding（見后文）

這樣做的好處呢，就是將服務的前后端分別與現在的 xRoute API 中的 parentRef 和 backendRef 關聯，無需引入額外的 API。

不同的時候，在 xRoute API 中的 backendRef 也可以是一個 Service，但是最終在路由請求時，目標還是 Endpoint 或者 EndpointSlice，只不過他們與 parentRef 中的 Service 不是強關聯的。

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

如果一個 Service 上配置了多個路由，匹配到多條路由的請求將被拒絕。

請求流程

1. 客戶端發送請求
2. 網格數據面代理攔截請求
3. 通過虛擬 IP 地址、DNS 主機名、或者名字來確認流量是屬于哪個 Service（不會使用 xRoute 上的 hostname 字段）
4. 如果 Service 沒有配置路由，將使用請求的原始目的地進行轉發
5. 找到匹配的優先級最高（消費者路由高于生產者路由，見下文）的路由進行轉發
6. 如果配置了路由，但都無法匹配，則拒絕請求

路由的命名空間

為什么要提命名空間，是因為路由與服務在相同或者不同命名空間下所代表的含義不同。

同命名空間

路由 smiley-route 與 Service smiley 位于同一個命名空間 faces，該路由上設置了請求超時時間 100ms。這意味著，所有訪問 Service smiley （來自任一命名空間下的任一工作負載）并匹配 smiley-route路由規則的請求，都受該超時配置的影響。

這種路由被稱為 生產者路由（Producer Route）[6]，影響目標為該服務的所有請求。

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

不同命名空間

路由 smiley-route 與 Service smiley 位于不同的命名空間，與上面不同的是，所有訪問 Service smiley（來自命名空間 fast-clients 下的任一工作負載）并匹配 smiley-route 路由規則的請求，都受該超時配置的影響。

這種路由被稱為 消費者路由（Consumer Route）[7]，影響同命名空間下訪問木雕服務的所有請求。

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

圖片

同一 Service 上的多個路由

這里的前提條件是這些路由都位于同一命名空間下，即同為生產者路由，或同為消費者路由。這種情況將會遵循 路由合并規則[8] 多這個路由進行合并，如果要為同一命名空間下的多個工作負載配置不同的消費者路由，目前還無法實現。唯一的

比如下面定義了兩個消費者路由 smiley-route-50 和 smiley-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

路由與策略

之前也寫文介紹過 Gateway API 中的策略，有興趣的可以看一下 一文搞懂 Kubernetes Gateway API 的 Policy Attachment[9]。

在網格中策略附加可以非常簡單。策略可以應用于任何命名空間中的任何資源，但如果目標位于不同的命名空間中，則它只能應用于來自同一命名空間的請求（跟隨消費者路由的邏輯）。

圖片

網格一致性測試

首先來看下何為 一致性配置文件[10]：

Gateway API 會提供用于一致性測試的配置文件，在運行一致性測試可以選擇這些配置文件。然后將一致性結果報告回網關 API 項目并獲得認證（例如徽章）。除了測試核心的功能，也可以自主添加廠商的特定實現中的擴展功能進行測試。

這些 Gateway API 的實現會將測試報告提交到 官方倉庫的一致性測試報告目錄[11] 中，可以作為大家選型時的依據之一。

目前有 HTTP、TLS、TLSPassthrough（基本上都是根據 xRoute 來進行組織，因此后續也會有 GRPC、TCP、UDP）。針對服務網格，也提出了 `mesh` 配置文件[12]。

官方博客[13] 中提到 Kuma 2.3+、Linkerd 2.14+、和 Istio 1.16+ 中的 Gateway API 實現已經全部通過 mesh一致性測試，但截止目前未看到測試報告，估計還在上傳中。

參考資料

[1] Gateway API 宣布在 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] SMI 與 Gateway API 的 GAMMA 倡議意味著什么？: https://atbug.com/why-smi-collaborating-in-gateway-api-gamma/

[4] 過了幾個月仍未提交: https://github.com/servicemeshinterface/smi-spec/issues/254

[5] Gateway 資源: 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] 路由合并規則: https://gateway-api.sigs.k8s.io/api-types/httproute#merging

[9] 一文搞懂 Kubernetes Gateway API 的 Policy Attachment: https://atbug.com/explore-k8s-gateway-api-policy-attachment/

[10] 一致性配置文件: https://gateway-api.sigs.k8s.io/geps/gep-1709/

[11] 官方倉庫的一致性測試報告目錄: https://github.com/kubernetes-sigs/gateway-api/tree/main/conformance/reports

[12] mesh 配置文件: https://gateway-api.sigs.k8s.io/geps/gep-1686/

[13] 官方博客: https://gateway-api.sigs.k8s.io/blog/2023/0829-mesh-support/