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

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 最初的重點始終是入口（南北向）流量，但幾乎從一開始就很清楚，相同的基本路由概念也應適用於服務網格（東西向）流量。在 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 現在可以有一個 parentRef，它是一個 Service，而不僅僅是一個 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 — 並且由於這是由服務網格而不是入口控制器處理的，因此 A/B 測試可以在應用程式的呼叫圖中的任何位置發生。

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

Gateway API 一直在對其支援的所有功能進行大量的一致性測試，網格也不例外。GAMMA 計畫遇到的挑戰之一是，許多這些測試都與給定的實作提供入口控制器的想法緊密相關。許多服務網格沒有，並且要求符合 GAMMA 標準的網格也實作入口控制器在最佳情況下似乎也不切實際。這導致了 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 中還有什麼？

此版本完全是為了準備 Gateway API 即將到來的 v1.0 版本，其中 HTTPRoute、Gateway 和 GatewayClass 將升級到 GA。有兩個與此相關的主要變更：CEL 驗證和 API 版本變更。

CEL 驗證

第一個主要變更是 Gateway API v0.8.0 是從 Webhook 驗證過渡到 CEL 驗證的開始，使用內建於 CRD 中的資訊。這對於您使用的 Kubernetes 版本而言，意味著不同的事情

Kubernetes 1.25+

完全支援 CEL 驗證，幾乎所有驗證都在 CEL 中實作。（唯一的例外是標頭修改器篩選器中的標頭名稱只能進行不區分大小寫的驗證。更多資訊請參閱 issue 2277。）

我們建議不要在這些 Kubernetes 版本上使用驗證 Webhook。

Kubernetes 1.23 和 1.24

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

我們建議繼續在這些 Kubernetes 版本上使用驗證 Webhook。

Kubernetes 1.22 及更舊版本

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

API 版本變更

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

我如何開始使用 Gateway API？

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

如果您有興趣開始使用 Gateway API，請查看 API 概念文件並查看一些指南以嘗試使用它。由於這是一個基於 CRD 的 API，您可以在任何 Kubernetes 1.23+ 叢集上安裝最新版本。

如果您特別有興趣協助貢獻 Gateway API，我們非常歡迎您！請隨時在儲存庫上開啟一個新 issue，或加入討論。另請查看社群頁面，其中包含 Slack 頻道和社群會議的連結。我們期待您的加入！！

Kubernetes 部落格