本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Gateway API v0.8.0：引入服務網格支援

作者：Flynn (Buoyant)、John Howard (Google)、Keith Mattix (Microsoft)、Michael Beaumont (Kong)、Mike Morris (independent)、Rob Scott (Google) | 2023 年 8 月 29 日，星期二

我們很高興地宣佈 Gateway API v0.8.0 釋出！隨著此版本的釋出，Gateway API 對服務網格的支援已達到實驗性狀態。我們期待你的反饋！

我們特別高興地宣佈，Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都是完全符合 Gateway API 服務網格支援的實現。

Gateway API 中的服務網格支援

雖然 Gateway API 最初的重點始終是 Ingress（南北向）流量，但幾乎從一開始就很清楚，相同的基本路由概念也應該適用於服務網格（東西向）流量。2022 年，Gateway API 子專案啟動了 GAMMA 倡議，這是一個專門的、與供應商無關的工作流，專門研究如何最好地將服務網格支援融入 Gateway API 資源的框架中，而不需要 Gateway API 的使用者重新學習他們對 API 的所有理解。

在過去的一年中，GAMMA 深入研究了圍繞使用 Gateway API 實現服務網格的挑戰和可能的解決方案。最終的結果是少數幾個增強提案，其中包含了數小時的思考和辯論，併為允許 Gateway API 用於服務網格提供了一條最小可行的路徑。

使用 Gateway API 時，網格路由將如何工作？

你可以在 Gateway API 網格路由文件和 GEP-1426 中找到所有細節，但 Gateway API v0.8.0 的簡短版本是，HTTPRoute 現在可以有一個作為 Service 的 parentRef，而不僅僅是 Gateway。隨著我們對服務網格用例的經驗越來越多，我們預計未來會有更多的 GEP 在這個領域出現——繫結到 Service 使得將 Gateway API 與服務網格一起使用成為可能，但仍有一些有趣的用例難以覆蓋。

例如，你可以使用 HTTPRoute 在網格中進行 A/B 測試，如下所示：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: demo-app
    port: 5000
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: v1
    backendRefs:
    - name: demo-app-v1
      port: 5000
  - backendRefs:
    - name: demo-app-v2
      port: 5000

任何對 demo-app Service 的 5000 埠且帶有 env: v1 標頭的請求都將被路由到 demo-app-v1，而任何沒有該標頭的請求都將被路由到 demo-app-v2——並且由於這是由服務網格而不是 Ingress 控制器處理的，A/B 測試可以發生在應用程式呼叫圖的任何地方。

我如何知道這將是真正可移植的？

Gateway API 一直在其支援的所有功能上大力投入一致性測試，網格也不例外。GAMMA 倡議遇到的挑戰之一是，許多這些測試都與一個給定的實現提供一個 Ingress 控制器的想法緊密相連。許多服務網格並不提供，並且要求一個符合 GAMMA 的網格也實現一個 Ingress 控制器，這至少看起來是不切實際的。這導致了 Gateway API 一致性配置檔案工作的重啟，如 GEP-1709 中所討論的。

一致性配置檔案的基本思想是，我們可以定義 Gateway API 的子集，並允許實現選擇（並記錄）它們符合哪些子集。GAMMA 正在新增一個名為 Mesh 的新配置檔案，並在 GEP-1686 中進行了描述，它只檢查 GAMMA 定義的網格功能。此時，Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都符合 Mesh 配置檔案。

Gateway API v0.8.0 中還有什麼？

此版本旨在為即將釋出的 v1.0 版本做準備，其中 HTTPRoute、Gateway 和 GatewayClass 將升級到 GA。與此相關的有兩個主要變化：CEL 驗證和 API 版本變化。

CEL 驗證

第一個主要變化是，Gateway API v0.8.0 是從 webhook 驗證過渡到使用 CRD 中內建資訊的 CEL 驗證的開始。這將意味著不同的事情，具體取決於你使用的 Kubernetes 版本：

Kubernetes 1.25+

CEL 驗證得到完全支援，並且幾乎所有驗證都在 CEL 中實現。（唯一的例外是標頭修飾符過濾器中的標頭名稱只能進行不區分大小寫的驗證。更多資訊請參見 issue 2277。）

我們建議在這些 Kubernetes 版本上**不**使用 validating webhook。

Kubernetes 1.23 和 1.24

不支援 CEL 驗證，但仍可以安裝 Gateway API v0.8.0 CRD。當你升級到 Kubernetes 1.25+ 時，這些 CRD 中包含的驗證將自動生效。

我們建議在這些 Kubernetes 版本上繼續使用 validating webhook。

Kubernetes 1.22 及更早版本

Gateway API 僅承諾支援最近 5 個版本的 Kubernetes。因此，Gateway API 不再支援這些版本，並且不幸的是，Gateway API v0.8.0 無法安裝在這些版本上，因為包含 CEL 驗證的 CRD 將被拒絕。

API 版本變更

在我們準備 v1.0 版本，將 Gateway、GatewayClass 和 HTTPRoute 從 v1beta1 升級到 v1 API 版本時，我們正在繼續將已升級到 v1beta1 的資源從 v1alpha2 中移出。有關此變更以及此版本中包含的所有其他內容的更多資訊，請參閱 v0.8.0 發行說明。

如何開始使用 Gateway API？

Gateway API 代表了 Kubernetes 中負載均衡、路由和服務網格 API 的未來。已經有超過 20 個實現可用（包括 Ingress 控制器和服務網格），並且這個列表還在不斷增長。

如果你有興趣開始使用 Gateway API，請檢視 API 概念文件，並檢視一些指南來嘗試一下。因為這是一個基於 CRD 的 API，所以你可以在任何 Kubernetes 1.23+ 叢集上安裝最新版本。

如果你特別有興趣為 Gateway API 做出貢獻，我們非常歡迎你！請隨時在倉庫上開啟一個新 issue，或者加入討論。也請檢視社群頁面，其中包含 Slack 頻道和社群會議的連結。我們期待你的加入！

Kubernetes 部落格