閘道 API

透過使用可擴充、面向角色、協定感知的組態機制，使網路服務可用。Gateway API 是一個附加元件，包含 API 種類，可提供動態基礎架構佈建和進階流量路由。

設計原則

以下原則塑造了 Gateway API 的設計和架構

• 面向角色： Gateway API 種類以負責管理 Kubernetes 服務網路的組織角色為模型
  • 基礎架構提供者： 管理基礎架構，允許隔離的多個叢集為多個租戶提供服務，例如雲端供應商。
  • 叢集運營商： 管理叢集，通常關注策略、網路存取、應用程式權限等。
  • 應用程式開發人員： 管理在叢集中運行的應用程式，通常關注應用程式層級組態和 服務 組合。
• 可移植： Gateway API 規範定義為自訂資源，並受到許多實作的支援。
• 富有表現力： Gateway API 種類支援常見流量路由使用案例的功能，例如基於標頭的匹配、流量權重和其他只能在 Ingress 中透過使用自訂註解實現的功能。
• 可擴充： Gateway 允許在 API 的各個層級連結自訂資源。這使得在 API 結構內的適當位置進行精細自訂成為可能。

資源模型

Gateway API 有三個穩定的 API 種類

• GatewayClass： 定義一組具有通用組態的閘道，並由實作該類別的控制器管理。

• Gateway： 定義流量處理基礎架構的執行個體，例如雲端負載平衡器。

• HTTPRoute： 定義 HTTP 特定的規則，用於將來自閘道監聽器的流量映射到後端網路端點的表示。這些端點通常表示為服務。

Gateway API 組織成不同的 API 種類，這些種類具有相互依賴的關係，以支援組織面向角色的性質。一個 Gateway 物件恰好與一個 GatewayClass 相關聯；GatewayClass 描述了負責管理此類別閘道的閘道控制器。然後，一個或多個路由種類（例如 HTTPRoute）與閘道相關聯。閘道可以篩選可能附加到其 listeners 的路由，從而與路由形成雙向信任模型。

下圖說明了三個穩定 Gateway API 種類之間的關係

GatewayClass

閘道可以由不同的控制器實作，通常具有不同的組態。閘道必須參考包含實作該類別的控制器名稱的 GatewayClass。

最小的 GatewayClass 範例

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-class
spec:
  controllerName: example.com/gateway-controller

在此範例中，已實作 Gateway API 的控制器已組態為管理具有控制器名稱 example.com/gateway-controller 的 GatewayClass。此類別的閘道將由實作的控制器管理。

請參閱 GatewayClass 參考，以取得此 API 種類的完整定義。

Gateway

Gateway 描述了流量處理基礎架構的執行個體。它定義了一個網路端點，可用於處理流量，即針對後端（例如服務）進行篩選、負載平衡、分割等。例如，閘道可以表示雲端負載平衡器或組態為接受 HTTP 流量的叢集內代理伺服器。

最小的 Gateway 資源範例

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80

在此範例中，流量處理基礎架構的執行個體已編程為監聽埠 80 上的 HTTP 流量。由於未指定 addresses 欄位，因此實作的控制器會將位址或主機名稱指派給閘道。此位址用作處理路由中定義的後端網路端點流量的網路端點。

請參閱 Gateway 參考，以取得此 API 種類的完整定義。

HTTPRoute

HTTPRoute 種類指定從閘道監聽器到後端網路端點的 HTTP 請求的路由行為。對於服務後端，實作可以將後端網路端點表示為服務 IP 或服務的後端端點。HTTPRoute 表示應用於底層閘道實作的組態。例如，定義新的 HTTPRoute 可能會導致在雲端負載平衡器或叢集內代理伺服器中組態額外的流量路由。

最小的 HTTPRoute 範例

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

在這個範例中，來自閘道器 example-gateway 的 HTTP 流量，其 Host: 標頭設定為 www.example.com，且請求路徑指定為 /login，將會路由至連接埠 8080 上的服務 example-svc。

請參閱 HTTPRoute 參考文件，以取得此 API 類型的完整定義。

請求流程

以下是一個簡單的範例，說明如何使用閘道器和 HTTPRoute 將 HTTP 流量路由至服務

在此範例中，實作為反向代理的閘道器的請求流程如下：

1. 用戶端開始準備 URL 為 http://www.example.com 的 HTTP 請求
2. 用戶端的 DNS 解析器查詢目的地名稱，並學習到與閘道器相關聯的一個或多個 IP 位址的映射。
3. 用戶端將請求傳送到閘道器 IP 位址；反向代理接收 HTTP 請求，並使用 Host: 標頭來比對從閘道器和附加的 HTTPRoute 衍生的組態。
4. 選擇性地，反向代理可以根據 HTTPRoute 的比對規則執行請求標頭和/或路徑比對。
5. 選擇性地，反向代理可以修改請求；例如，根據 HTTPRoute 的篩選器規則新增或移除標頭。
6. 最後，反向代理將請求轉發到一個或多個後端。

一致性

Gateway API 涵蓋了廣泛的功能，並被廣泛實作。這種組合需要明確的一致性定義和測試，以確保 API 在任何使用地點都能提供一致的體驗。

請參閱一致性文件，以瞭解發佈管道、支援層級和執行一致性測試等詳細資訊。

從 Ingress 遷移

Gateway API 是 Ingress API 的後繼者。但是，它不包含 Ingress 種類。因此，需要將現有的 Ingress 資源一次性轉換為 Gateway API 資源。

請參閱 Ingress 遷移指南，以取得將 Ingress 資源遷移至 Gateway API 資源的詳細資訊。

下一步

Gateway API 資源並非由 Kubernetes 原生實作，而是將規格定義為由各種 實作 支援的 Custom Resources。安裝 Gateway API CRD，或遵循您選擇的實作的安裝指示。安裝實作後，使用入門指南來協助您快速開始使用 Gateway API。

請參閱 API 規格，以取得所有 Gateway API 種類的更多詳細資訊。