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

Gateway API v1.1：服務網格、GRPCRoute 以及更多

作者：Richard Belleville (Google)、Frank Budinsky (IBM)、Arko Dasgupta (Tetrate)、Flynn (Buoyant)、Candace Holman (Red Hat)、John Howard (Solo.io)、Christine Kim (Isovalent)、Mattia Lavacca (Kong)、Keith Mattix (Microsoft)、Mike Morris (Microsoft)、Rob Scott (Google)、Grant Spence (Red Hat)、Shane Utt (Kong)、Gina Yeh (Google) 以及其他評審和釋出說明貢獻者 | 2024 年 5 月 9 日，星期四

繼去年十月 Gateway API 的 GA 版本釋出之後，Kubernetes SIG Network 很高興地宣佈 Gateway API 的 v1.1 版本釋出。在此版本中，有幾個功能升級到 Standard Channel (GA)，其中最引人注目的是對服務網格和 GRPCRoute 的支援。我們還引入了一些新的實驗性功能，包括會話永續性和客戶端證書驗證。

新增內容

畢業至 Standard Channel

此版本包括四個備受期待的功能畢業至 Standard Channel。這意味著它們不再是實驗性的概念；被納入 Standard 釋出渠道表明對 API 介面的高度信心，並提供向後相容性的保證。當然，與任何其他 Kubernetes API 一樣，Standard Channel 的功能可以隨著時間的推移，透過向後相容的增補繼續演進，我們當然期望這些新功能在未來會有進一步的完善和改進。有關此工作原理的更多資訊，請參閱 Gateway API 版本控制策略。

服務網格支援

Gateway API 中的服務網格支援允許服務網格使用者使用相同的 API 來管理入口流量和網格內流量，複用相同的策略和路由介面。在 Gateway API v1.1 中，路由（例如 HTTPRoute）現在可以有一個 Service 作為 parentRef，以控制到特定服務的流量行為。更多資訊請閱讀 Gateway API 服務網格文件或檢視 Gateway API 實現列表。

舉個例子，可以在應用程式呼叫圖的深處使用 HTTPRoute 進行工作負載的金絲雀部署，如下所示：

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 v1 之前，暫緩升級到 GRPCRoute 的 Standard Channel 版本。在此之前，升級到 v1.1 中包含 v1alpha2 和 v1 API 版本的 GRPCRoute 實驗性渠道版本是安全的。

ParentReference Port

port 欄位已新增到 ParentReference 中，允許你將資源附加到 Gateway Listener、Service 或其他父資源（取決於實現）。繫結到埠還允許你一次附加到多個 Listener。

例如，你可以將一個 HTTPRoute 附加到一個或多個由 Listener port 指定的 Gateway 的特定 Listener 上，而不是使用 Listener 的 name 欄位。

更多資訊，請參見附加到閘道器。

一致性配置檔案和報告

一致性報告 API 已透過 mode 欄位（用於指定實現的工件模式）和 gatewayAPIChannel（standard 或 experimental）進行了擴充套件。gatewayAPIVersion 和 gatewayAPIChannel 現在由套件機制自動填充，並附有測試結果的簡要描述。報告已以更結構化的方式重新組織，並且實現現在可以新增有關測試執行方式的資訊並提供復現步驟。

Experimental Channel 的新增內容

閘道器客戶端證書驗證

透過在 tls 中引入一個新的 frontendValidation 欄位，閘道器現在可以為每個 Gateway Listener 配置客戶端證書驗證。該欄位支援配置一個 CA 證書列表，可用作信任錨來驗證客戶端提供的證書。

以下示例展示瞭如何使用儲存在 foo-example-com-ca-cert ConfigMap 中的 CA 證書來驗證連線到 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 的未來。

檢視使用者指南，瞭解可以解決哪些用例。
試用現有的 Gateway 控制器之一。
或者加入我們的社群，幫助我們共同構建 Gateway API 的未來！

Gateway API v1.0 中的新實驗性功能 11/2023
Gateway API v1.0: GA 版本 10/2023
介紹 ingress2gateway；簡化到 Gateway API 的升級 10/2023
Gateway API v0.8.0：引入服務網格支援 08/2023