本文已釋出一年多。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已失效。

Gateway API v1.0 中的新實驗性功能

作者：Candace Holman (Red Hat)、Dave Protasowski (VMware)、Gaurav K Ghildiyal (Google)、John Howard (Google)、Simone Rodigari (IBM) | 2023 年 11 月 28 日，星期二

最近，Gateway API 宣佈了其 v1.0 正式釋出，標誌著該專案的一個重要里程碑。

除了穩定 API 中的一些核心功能外，還添加了許多令人興奮的新的實驗性功能。

後端 TLS 策略

BackendTLSPolicy 是一種新的 Gateway API 型別，用於透過 Service API 物件指定從閘道器到後端 Pod 的連線的 TLS 配置。它被指定為直接策略附件，沒有預設值或覆蓋，應用於訪問後端的 Service，其中 BackendTLSPolicy 位於與它所應用的 Service 相同的名稱空間中。所有指向引用 Service 的 Gateway API 路由都應遵循配置的 BackendTLSPolicy。

雖然已經提供了配置邊緣和直通終止的 TLS 的現有方法，但這個新的 API 物件專門解決了 TLS 的配置，以便將 HTTPS 從閘道器資料平面傳輸到後端。這被稱為“後端 TLS 終止”，並使閘道器能夠知道如何連線到擁有自己證書的後端 Pod。

Termination Types

BackendTLSPolicy 的規範包括：

targetRef - 定義策略的目標 API 物件。只允許 Service。
tls - 定義 TLS 的配置，包括 hostname、caCertRefs 和 wellKnownCACerts。可以指定 caCertRefs 或 wellKnownCACerts，但不能同時指定兩者。
hostname - 定義閘道器用於連線到後端的伺服器名稱指示 (SNI)。後端提供的證書必須與此 SNI 匹配。
caCertRefs - 定義一個或多個對包含 PEM 編碼 TLS 證書的物件的引用，這些證書用於在閘道器和後端之間建立 TLS 握手。
wellKnownCACerts - 指定是否可以在閘道器和後端之間的 TLS 握手中使用系統 CA 證書。

示例

使用系統證書

在此示例中，BackendTLSPolicy 配置為使用系統證書連線 TLS 加密的上游連線，其中支援 dev 服務的 Pod 預計將為 dev.example.com 提供有效證書。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-dev
spec:
  targetRef:
    kind: Service
    name: dev-service
    group: ""
  tls:
    wellKnownCACerts: "System"
    hostname: dev.example.com

使用顯式 CA 證書

在此示例中，BackendTLSPolicy 配置為使用配置對映 auth-cert 中定義的證書連線 TLS 加密的上游連線，其中支援 auth 服務的 Pod 預計將為 auth.example.com 提供有效證書。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-auth
spec:
  targetRef:
    kind: Service
    name: auth-service
    group: ""
  tls:
    caCertRefs:
      - kind: ConfigMapReference
        name: auth-cert
        group: ""
    hostname: auth.example.com

以下示意圖說明了一個為服務後端配置 TLS 的 BackendTLSPolicy：

flowchart LR client(["client"]) gateway["Gateway"] style gateway fill:#02f,color:#fff httproute["HTTP
Route"] style httproute fill:#02f,color:#fff service["Service"] style service fill:#02f,color:#fff pod1["Pod"] style pod1 fill:#02f,color:#fff pod2["Pod"] style pod2 fill:#02f,color:#fff client -.->|HTTP
request| gateway gateway --> httproute httproute -.->|BackendTLSPolicy|service service --> pod1 & pod2

有關更多資訊，請參閱 TLS 文件。

HTTPRoute 超時

Gateway API 最新版本 (v1.0) 的一個關鍵增強是在 HTTPRoute Rules 中引入了 timeouts 欄位。此功能提供了一種動態管理傳入 HTTP 請求超時的方法，為您的閘道器設定增加了精確性和可靠性。

透過超時，開發者可以透過兩種基本方式微調其 Gateway API 的行為：

請求超時:
請求超時是閘道器 API 實現必須向客戶端的 HTTP 請求傳送響應的持續時間。它提供了在指定此超時何時開始方面的靈活性，可以在接收到整個客戶端請求流之前或之後，這使其成為實現特定的。此超時有效地涵蓋了整個請求-響應事務，增強了服務的響應能力。
後端請求超時:
backendRequest 超時對於處理後端的人來說是一個遊戲規則改變者。它為從閘道器傳送到後端服務的單個請求設定了超時。此超時從請求的啟動到從後端接收完整響應為止。此功能在閘道器需要重試與後端連線的場景中特別有用，確保在各種條件下順利通訊。

值得注意的是，request 超時包含 backendRequest 超時。因此，backendRequest 的值不應超過 request 超時。

配置這些超時的能力為您的 Kubernetes 服務增加了新的可靠性層。無論是確保客戶端請求在指定時間內處理，還是管理後端服務通訊，Gateway API 的超時都提供了您所需的控制和可預測性。

要開始使用，您可以在 HTTPRoute 規則中使用 Timeouts 欄位定義超時，將其型別指定為 Duration。零值超時 (0s) 會停用超時，而有效的非零值超時應至少為 1 毫秒。

以下是在 HTTPRoute 中設定請求和後端請求超時的示例

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: timeout-example
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /timeout
    timeouts:
      request: 10s
      backendRequest: 2s
    backendRefs:
    - name: timeout-svc
      port: 8080

在此示例中，定義了 10 秒的 request 超時，確保客戶端請求在此時間範圍內處理。此外，為從閘道器到名為 timeout-svc 的後端服務的單個請求設定了 2 秒的 backendRequest 超時。

這些新的 HTTPRoute 超時為 Kubernetes 使用者提供了更多控制和靈活性來管理網路通訊，有助於確保客戶端和後端都獲得更順暢、更可預測的體驗。有關更多詳細資訊和示例，請參閱官方超時 API 文件。

閘道器基礎設施標籤

雖然 Gateway API 為不同的實現提供了通用的 API，但每個實現都會在底層建立不同的資源來應用使用者的意圖。這可能包括配置雲負載均衡器、建立叢集內 Pod 和服務等等。

雖然 API 始終提供了一個擴充套件點——GatewayClass 中的 parametersRef ——用於自定義特定於實現的事物，但沒有一種通用的核心方式來表達常見的基礎設施自定義。

Gateway API v1.0 透過 Gateway 物件上的新 infrastructure 欄位為此鋪平了道路，允許自定義底層基礎設施。目前，這從兩個關鍵欄位開始：標籤和註解。設定這些欄位後，任何生成的基礎設施都將設定提供的標籤和註解。

例如，我可能希望將一個應用程式的所有資源組合在一起

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: hello-world
spec:
  infrastructure:
    labels:
      app.kubernetes.io/name: hello-world

未來，我們正在研究更常見的基礎設施配置，例如資源大小。

有關更多資訊，請參閱此功能的文件。

支援 Websockets、HTTP/2 等！

並非所有 Gateway API 實現都支援自動協議選擇。在某些情況下，如果未明確選擇加入，則會停用協議。

當路由的後端引用 Kubernetes 服務時，應用程式開發人員可以使用 ServicePort appProtocol 欄位指定協議。

例如，以下 store Kubernetes 服務表明埠 8080 支援 HTTP/2 Prior Knowledge。

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  selector:
    app: store
  ports:
  - protocol: TCP
    appProtocol: kubernetes.io/h2c
    port: 8080
    targetPort: 8080

目前，Gateway API 具有以下一致性測試

kubernetes.io/h2c - HTTP/2 Prior Knowledge
kubernetes.io/ws - WebSocket over HTTP

有關更多資訊，請參閱後端協議選擇的文件。

`gwctl`，我們新的 Gateway API 命令列工具

gwctl 是一個命令列工具，旨在替代 kubectl 以檢視 Gateway API 資源。

與 Gateway v1.0 版本捆綁在一起的 gwctl 的初始版本包含用於管理 Gateway API 策略的有用功能。Gateway API 策略作為強大的擴充套件機制，用於修改 Gateway 資源的行為。使用策略的一個挑戰是可能很難發現哪些策略正在影響哪些 Gateway 資源。gwctl 透過回答以下問題來幫助彌合這一差距：

Kubernetes 叢集中有哪些策略可用？
哪些策略附加到特定的閘道器、HTTPRoute 等？
如果策略應用於 Gateway 資源層次結構中的多個資源，那麼影響特定資源的有效策略是什麼？（例如，如果 HTTP 請求超時策略同時應用於 HTTPRoute 及其父 Gateway，則 HTTPRoute 的有效超時是多少？）

gwctl 仍處於開發的早期階段，因此可能有些粗糙。請按照儲存庫中的說明安裝並試用 gwctl。

示例

以下是一些如何使用 gwctl 的示例

# List all policies in the cluster. This will also give the resource they bind
# to.
gwctl get policies -A
# List all available policy types.
gwctl get policycrds
# Describe all HTTPRoutes in namespace ns2. (Output includes effective policies)
gwctl describe httproutes -n ns2
# Describe a single HTTPRoute in the default namespace. (Output includes
# effective policies)
gwctl describe httproutes my-httproute-1
# Describe all Gateways across all namespaces. (Output includes effective
# policies)
gwctl describe gateways -A
# Describe a single GatewayClass. (Output includes effective policies)
gwctl describe gatewayclasses foo-com-external-gateway-class

參與進來

這些專案以及更多專案正在 Gateway API 中不斷改進。有很多機會可以參與進來，幫助定義 Kubernetes 入口和網格路由 API 的未來。

如果您對此感興趣，請加入我們的社群，幫助我們共同構建 Gateway API 的未來！