前幾天 Gateway API 宣布在 0.8.0 中支持服務(wù)網(wǎng)格[1]，這意味著 GAMMA[2]（Gateway API for Mesh Management and Administration）有了新進展，雖然目前還是實驗階段。去年 6 月 Gateway API 發(fā)布 0.5.0 時，我還寫了一篇 SMI 與 Gateway API 的 GAMMA 倡議意味著什么？[3]。如今，SMI 作為 sandbox 項目的年度審查已經(jīng) 過了幾個月仍未提交[4]，唏噓。
廢話不多說，我們來看下 0.8.0 下的 Gateway API 如何在 Service Mesh 中工作。
TL;DR
Gateway API 對服務(wù)網(wǎng)格的支持仍然是實驗階段，但是已經(jīng)有廠商跟進（當(dāng)然也都是實驗階段）。
相比 Gateway API 處理南北向流量將路由綁定到 Gateway 資源[5] 相比，在網(wǎng)格中路由則是與 Service 進行綁定。簡單理解成 Service 代理了 Gateway 的角色，不過該 Service 是目標(biāo) Service。
Gateway API 中的服務(wù)網(wǎng)格
要說服務(wù)網(wǎng)格，我們先來看下服務(wù) Service。
抽象 Service
Service 中 Kube.NETes 中是一個獨立的資源，這里說的抽象是從邏輯上進行抽象，抽象成前端和后端兩部分。
前端（Frontend）通常就是 Service 的 DNS 名字或者 ClusterIP；后端（Backend）則是通過標(biāo)簽選擇器選擇的 Endpoint 或者 EndpointSlice。
圖片
路由與服務(wù)
圖片
把路由直接綁定到 Service 上，被認為是當(dāng)下最優(yōu)的選擇。Service 與其他資源的耦合度太高，比如 IP 分配、DNS、端點集合、負載均衡等等，但在目前的網(wǎng)格設(shè)計中也是唯一的最優(yōu)選擇，未來會尋求更好的選擇，比如 ServiceBinding（見后文）
這樣做的好處呢，就是將服務(wù)的前后端分別與現(xiàn)在的 xRoute API 中的 parentRef 和 backendRef 關(guān)聯(lián)，無需引入額外的 API。
不同的時候，在 xRoute API 中的 backendRef 也可以是一個 Service，但是最終在路由請求時，目標(biāo)還是 Endpoint 或者 EndpointSlice，只不過他們與 parentRef 中的 Service 不是強關(guān)聯(lián)的。
kind: HTTPRoute
metadata:
name: smiley-route
namespace: faces
spec:
parentRefs:
- name: smiley
kind: Service
group: core
port: 80
rules:
...
如果一個 Service 上配置了多個路由，匹配到多條路由的請求將被拒絕。
請求流程
- 客戶端發(fā)送請求
- 網(wǎng)格數(shù)據(jù)面代理攔截請求
- 通過虛擬 IP 地址、DNS 主機名、或者名字來確認流量是屬于哪個 Service（不會使用 xRoute 上的 hostname 字段）
- 如果 Service 沒有配置路由，將使用請求的原始目的地進行轉(zhuǎn)發(fā)
- 找到匹配的優(yōu)先級最高（消費者路由高于生產(chǎn)者路由，見下文）的路由進行轉(zhuǎn)發(fā)
- 如果配置了路由，但都無法匹配，則拒絕請求
路由的命名空間
為什么要提命名空間，是因為路由與服務(wù)在相同或者不同命名空間下所代表的含義不同。
同命名空間
路由 smiley-route 與 Service smiley 位于同一個命名空間 faces，該路由上設(shè)置了請求超時時間 100ms。這意味著，所有訪問 Service smiley （來自任一命名空間下的任一工作負載）并匹配 smiley-route路由規(guī)則的請求，都受該超時配置的影響。
這種路由被稱為 生產(chǎn)者路由（Producer Route）[6]，影響目標(biāo)為該服務(wù)的所有請求。
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 路由規(guī)則的請求，都受該超時配置的影響。
這種路由被稱為 消費者路由（Consumer Route）[7]，影響同命名空間下訪問木雕服務(wù)的所有請求。
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 上的多個路由
這里的前提條件是這些路由都位于同一命名空間下，即同為生產(chǎn)者路由，或同為消費者路由。這種情況將會遵循 路由合并規(guī)則[8] 多這個路由進行合并，如果要為同一命名空間下的多個工作負載配置不同的消費者路由，目前還無法實現(xiàn)。唯一的
比如下面定義了兩個消費者路由 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)格中策略附加可以非常簡單。策略可以應(yīng)用于任何命名空間中的任何資源，但如果目標(biāo)位于不同的命名空間中，則它只能應(yīng)用于來自同一命名空間的請求（跟隨消費者路由的邏輯）。
圖片
網(wǎng)格一致性測試
首先來看下何為 一致性配置文件[10]：
Gateway API 會提供用于一致性測試的配置文件，在運行一致性測試可以選擇這些配置文件。然后將一致性結(jié)果報告回網(wǎng)關(guān) API 項目并獲得認證（例如徽章）。除了測試核心的功能，也可以自主添加廠商的特定實現(xiàn)中的擴展功能進行測試。
這些 Gateway API 的實現(xiàn)會將測試報告提交到 官方倉庫的一致性測試報告目錄[11] 中，可以作為大家選型時的依據(jù)之一。
目前有 HTTP、TLS、TLSPassthrough（基本上都是根據(jù) xRoute 來進行組織，因此后續(xù)也會有 GRPC、TCP、UDP）。針對服務(wù)網(wǎng)格，也提出了 `mesh` 配置文件[12]。
官方博客[13] 中提到 Kuma 2.3+、Linkerd 2.14+、和 Istio 1.16+ 中的 Gateway API 實現(xiàn)已經(jīng)全部通過 mesh一致性測試，但截止目前未看到測試報告，估計還在上傳中。
參考資料
[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] 過了幾個月仍未提交: 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] 消費者路由（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] 官方倉庫的一致性測試報告目錄: 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/
