Gateway API v1.1:服務網格、GRPCRoute 以及更多功能

Gateway API logo

繼去年十月 Gateway API 正式版 (GA) 發布後,Kubernetes SIG Network 很高興宣布 Gateway API v1.1 版本發布。在此版本中,多項功能已升級至標準通道 (GA),特別是包含對服務網格和 GRPCRoute 的支援。我們也推出了一些新的實驗性功能,包括會話持久性和用戶端憑證驗證。

新功能

升級至標準

此版本包含四項備受期待的功能升級至標準。這表示它們不再是實驗性概念;納入標準發布通道表示對 API 介面具有高度信心,並提供向後相容性的保證。當然,與任何其他 Kubernetes API 一樣,標準通道功能可以隨著時間的推移透過向後相容的新增功能持續發展,而且我們當然期望未來對這些新功能進行進一步的改進和提升。如需更多關於所有這些運作方式的資訊,請參閱 Gateway API 版本控制政策

服務網格支援

Gateway API 中的服務網格支援讓服務網格使用者可以使用相同的 API 來管理入口流量和網格流量,重複使用相同的政策和路由介面。在 Gateway API v1.1 中,路由 (例如 HTTPRoute) 現在可以將 Service 作為 parentRef,以控制特定服務的流量行為。如需更多資訊,請閱讀 Gateway API 服務網格文件 或參閱 Gateway API 實作列表

例如,可以使用 HTTPRoute 對應用程式呼叫圖深處的工作負載進行 Canary 部署,如下所示

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

這會將傳送到 faces 命名空間中 color 服務的流量,在原始 color 服務和 color2 服務之間以 50/50 的比例分配,使用可從一個網格輕鬆移至另一個網格的可攜式組態。

GRPCRoute

如果您已在使用實驗性版本的 GRPCRoute,我們建議暫緩升級到標準通道版本的 GRPCRoute,直到您使用的控制器已更新以支援 GRPCRoute v1 為止。在那之前,升級到 v1.1 中包含 v1alpha2 和 v1 API 版本的實驗性通道版本 GRPCRoute 是安全的。

ParentReference Port

port 欄位已新增至 ParentReference,讓您可以將資源附加到 Gateway Listener、Service 或其他父資源 (取決於實作)。繫結到埠也讓您可以一次附加到多個 Listener。

例如,您可以將 HTTPRoute 附加到 Gateway 的一個或多個特定 Listener,如 Listener port 所指定,而不是 Listener name 欄位。

如需更多資訊,請參閱 附加到閘道

一致性設定檔和報告

一致性報告 API 已透過 mode 欄位 (旨在指定實作的工作模式) 和 gatewayAPIChannel (標準或實驗性) 進行擴充。gatewayAPIVersiongatewayAPIChannel 現在由套件機制自動填入,並附帶測試結果的簡要說明。報告已以更結構化的方式重新組織,實作現在可以新增關於測試如何執行的資訊,並提供重現步驟。

實驗性通道的新增功能

閘道用戶端憑證驗證

閘道現在可以透過在 tls 中引入新的 frontendValidation 欄位,為每個 Gateway Listener 設定用戶端憑證驗證。此欄位支援設定可用作信任錨點以驗證用戶端提供的憑證的 CA 憑證清單。

以下範例顯示如何使用儲存在 foo-example-com-ca-cert ConfigMap 中的 CACertificate 來驗證連線到 foo-https Gateway Listener 的用戶端所提供的憑證。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

會話持久性和 BackendLBPolicy

會話持久性 透過新的政策 (BackendLBPolicy) 引入到 Gateway API,用於服務層級組態,以及 HTTPRoute 和 GRPCRoute 內的欄位,用於路由層級組態。BackendLBPolicy 和路由層級 API 提供相同的會話持久性組態,包括會話逾時、會話名稱、會話類型和 Cookie 生存期類型。

以下是 BackendLBPolicy 的範例組態,它為 foo 服務啟用基於 Cookie 的會話持久性。它將會話名稱設定為 foo-session,定義絕對和閒置逾時,並將 Cookie 設定為會話 Cookie

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

其他事項

TLS 術語澄清

作為使我們的 TLS 術語在整個 API 中更一致的更廣泛目標的一部分,我們對 BackendTLSPolicy 進行了一些重大變更。這導致了新的 API 版本 (v1alpha3),並且需要此政策的任何現有實作正確處理版本升級,例如透過備份資料並在安裝較新版本之前解除安裝 v1alpha2 版本。

任何對 v1alpha2 BackendTLSPolicy 欄位的參考都需要更新為 v1alpha3。對欄位的具體變更包括

  • targetRef 變更為 targetRefs,以允許 BackendTLSPolicy 附加到多個目標
  • tls 變更為 validation
  • tls.caCertRefs 變更為 validation.caCertificateRefs
  • tls.wellKnownCACerts 變更為 validation.wellKnownCACertificates

如需此版本中包含的變更完整列表,請參閱 v1.1.0 發行說明

Gateway API 背景

Gateway API 的想法最初是在 2019 年聖地牙哥 KubeCon 上 提出,作為下一代 Ingress API。從那時起,一個令人難以置信的社群已經形成,開發了可能已成為 Kubernetes 歷史上最具協作性的 API。到目前為止,已有 200 多人為此 API 做出貢獻,而且這個數字還在持續增長。

維護者要感謝每位為 Gateway API 做出貢獻的人,無論是以提交程式碼到儲存庫、討論、想法或一般支援的形式。如果沒有這個專注且活躍的社群的支持,我們絕對無法走到這一步。

試用看看

與其他 Kubernetes API 不同,您不需要升級到最新版本的 Kubernetes 即可取得最新版本的 Gateway API。只要您執行的是 Kubernetes 1.26 或更新版本,就可以開始使用此版本的 Gateway API。

若要試用 API,請按照我們的 入門指南 進行操作。

參與其中

有許多機會可以參與其中,並協助定義 Kubernetes 路由 API 的未來,適用於入口和服務網格。