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

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

TL;DR

Gateway API 對(duì)服務(wù)網(wǎng)格的支持仍然是實(shí)驗(yàn)階段，但是已經(jīng)有廠商跟進(jìn)（當(dāng)然也都是實(shí)驗(yàn)階段）。

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

Gateway API 中的服務(wù)網(wǎng)格

要說服務(wù)網(wǎng)格，我們先來看下服務(wù) Service。

抽象 Service

Service 中 Kubernetes 中是一個(gè)獨(dú)立的資源，這里說的抽象是從邏輯上進(jìn)行抽象，抽象成前端和后端兩部分。

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

圖片

路由與服務(wù)

圖片

把路由直接綁定到 Service 上，被認(rèn)為是當(dāng)下最優(yōu)的選擇。Service 與其他資源的耦合度太高，比如 IP 分配、DNS、端點(diǎn)集合、負(fù)載均衡等等，但在目前的網(wǎng)格設(shè)計(jì)中也是唯一的最優(yōu)選擇，未來會(huì)尋求更好的選擇，比如 ServiceBinding（見后文）

這樣做的好處呢，就是將服務(wù)的前后端分別與現(xiàn)在的 xRoute API 中的 parentRef 和 backendRef 關(guān)聯(lián)，無需引入額外的 API。

不同的時(shí)候，在 xRoute API 中的 backendRef 也可以是一個(gè) Service，但是最終在路由請(qǐng)求時(shí)，目標(biāo)還是 Endpoint 或者 EndpointSlice，只不過他們與 parentRef 中的 Service 不是強(qiáng)關(guān)聯(lián)的。

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

如果一個(gè) Service 上配置了多個(gè)路由，匹配到多條路由的請(qǐng)求將被拒絕。

請(qǐng)求流程

1. 客戶端發(fā)送請(qǐng)求
2. 網(wǎng)格數(shù)據(jù)面代理攔截請(qǐng)求
3. 通過虛擬 IP 地址、DNS 主機(jī)名、或者名字來確認(rèn)流量是屬于哪個(gè) Service（不會(huì)使用 xRoute 上的 hostname 字段）
4. 如果 Service 沒有配置路由，將使用請(qǐng)求的原始目的地進(jìn)行轉(zhuǎn)發(fā)
5. 找到匹配的優(yōu)先級(jí)最高（消費(fèi)者路由高于生產(chǎn)者路由，見下文）的路由進(jìn)行轉(zhuǎn)發(fā)
6. 如果配置了路由，但都無法匹配，則拒絕請(qǐng)求

路由的命名空間

為什么要提命名空間，是因?yàn)槁酚膳c服務(wù)在相同或者不同命名空間下所代表的含義不同。

同命名空間

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

這種路由被稱為 生產(chǎn)者路由（Producer Route）[6]，影響目標(biāo)為該服務(wù)的所有請(qǐng)求。

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 下的任一工作負(fù)載）并匹配 smiley-route 路由規(guī)則的請(qǐng)求，都受該超時(shí)配置的影響。

這種路由被稱為 消費(fèi)者路由（Consumer Route）[7]，影響同命名空間下訪問木雕服務(wù)的所有請(qǐng)求。

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 上的多個(gè)路由

這里的前提條件是這些路由都位于同一命名空間下，即同為生產(chǎn)者路由，或同為消費(fèi)者路由。這種情況將會(huì)遵循 路由合并規(guī)則[8] 多這個(gè)路由進(jìn)行合并，如果要為同一命名空間下的多個(gè)工作負(fù)載配置不同的消費(fèi)者路由，目前還無法實(shí)現(xiàn)。唯一的

比如下面定義了兩個(gè)消費(fèi)者路由 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]。

在網(wǎng)格中策略附加可以非常簡(jiǎn)單。策略可以應(yīng)用于任何命名空間中的任何資源，但如果目標(biāo)位于不同的命名空間中，則它只能應(yīng)用于來自同一命名空間的請(qǐng)求（跟隨消費(fèi)者路由的邏輯）。

圖片

網(wǎng)格一致性測(cè)試

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

Gateway API 會(huì)提供用于一致性測(cè)試的配置文件，在運(yùn)行一致性測(cè)試可以選擇這些配置文件。然后將一致性結(jié)果報(bào)告回網(wǎng)關(guān) API 項(xiàng)目并獲得認(rèn)證（例如徽章）。除了測(cè)試核心的功能，也可以自主添加廠商的特定實(shí)現(xiàn)中的擴(kuò)展功能進(jìn)行測(cè)試。

這些 Gateway API 的實(shí)現(xiàn)會(huì)將測(cè)試報(bào)告提交到 官方倉庫的一致性測(cè)試報(bào)告目錄[11] 中，可以作為大家選型時(shí)的依據(jù)之一。

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

官方博客[13] 中提到 Kuma 2.3+、Linkerd 2.14+、和 Istio 1.16+ 中的 Gateway API 實(shí)現(xiàn)已經(jīng)全部通過 mesh一致性測(cè)試，但截止目前未看到測(cè)試報(bào)告，估計(jì)還在上傳中。

參考資料

[1] Gateway API 宣布在 0.8.0 中支持服務(wù)網(wǎng)格: 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] 過了幾個(gè)月仍未提交: 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] 生產(chǎn)者路由（Producer Route）: https://gateway-api.sigs.k8s.io/concepts/glossary#producer-route

[7] 消費(fèi)者路由（Consumer Route）: https://gateway-api.sigs.k8s.io/concepts/glossary#consumer-route

[8] 路由合并規(guī)則: 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] 官方倉庫的一致性測(cè)試報(bào)告目錄: 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/