試用Kubernetes Gateway API 的五大理由

相較於Kubernetes Ingress 資源來說，Gateway API 是更好的替代方案。在這篇文章中，我們討論了試用和引進NGINX Gateway Fabric 的原因——這是一個開源工具，能讓你使用NGINX 作為資料面的Gateway

Kubernetes從早期階段就包含一個API — 內建Ingress 資源，用於設定外部HTTP 流量到Service的請求路由。雖然已被用戶廣泛採用並得到許多實現（如Ingress controller）的支援，但Ingress 資源在以下三大方面限制了其用戶：

  • 功能不足– 減少了支援的用例數量。
  • 可擴展性模型不佳– 限制了對NGINX 等許多資料平面中已有的進階功能的存取。
  • 缺少不同的使用者角色– 阻礙了叢集內多個團隊之間安全共享資料平面基礎設施。

為了因應這些限制，Kubernetes 社群設計了Gateway API，這個新專案可更有效地取代Ingress 資源。本文闡釋了試用Gateway API 的五大理由，並將其與Ingress 資源進行了比較，另外也介紹了我們的開源專案NGINX Gateway Fabric。此專案支援您在Kubernetes 叢集中啟用Gateway API，同時將NGINX 用作資料平面。

註： Gateway API 支援與Service 網路相關的多種用例，包括實驗性service mesh（服務網格）。不過，本文將重點放在Gateway API 的主要用例：將外部流量路由到叢集中的Service。此外，雖然API 支援多個協議，但我們的探討僅限於最常用的HTTP 協議。

Gateway API 概述

Gateway API 是自訂資源的集合，可部署和配置資料平面，從而對叢集內Service 的Service 網路流量進行建模。

以下是主要的Gateway API 資源： 

  • GatewayClass – 定義尚未部署的資料平面範本。
  • Gateway – 從範本（GatewayClass）部署資料平面，並在其上配置入口點（連接埠）以接受外部流量。
  • HTTPRoute – 設定外部流量到叢集內Service 的HTTP 要求路由規則，並將這些規則附加到Gateway 定義的入口點。

Gateway API 的另一個重要組成部分是閘道實現，它是一個Kubernetes控制器，可根據Gateway API 資源實際部署和配置資料平面。

如欲了解有關API 的更多訊息，請前往Gateway API 專案網站或觀看影片介紹。

試用Gateway API 的理由有哪些？

以下為試用全新Gateway API 的五大理由：

  1. 豐富的功能
  2. 強大的可擴展性模型
  3. 角色分離
  4. 可移植性
  5. 社群

下面我們來詳細了解每個理由。

理由1：豐富的功能

Gateway API 提供了大量功能，有助於解鎖許多新用例，其中一些用例可能還未獲得Ingress 資源的全面支援。

這些用例包括：

  • 灰階發布
  • A/B 測試
  • 請求和回應操作
  • 請求重定向
  • 流量鏡像
  • 跨命名空間的流量路由

例如，以下是來自 HTTPRoute 的一個請求路由規則，它使用權重在兩個Kubernetes service 之間精分流量，以支援灰階發布用例。

- matches: 
  - path: 
      type: PathPrefix 
      value: / 
  backendRefs: 
  - name: my-app-old 
    port: 80 
    weight: 95 
  - name: my-app-new 
    port: 80 
    weight: 5

這樣一來，資料平面將95% 的請求路由到Service my-app-old，將其餘5% 的請求路由到my-app-new。

接下來的範例包含兩個規則。其中一個規則利用了Gateway API 進階路由功能，使用請求頭和查詢參數進行路由。

- matches: # 規則 1 
  - path: 
      type: PathPrefix 
      value: /coffee 
  backendRefs: 
  - name: coffee-v1-svc 
    port: 80 
- matches: # 規則 2 
  - path: 
      type: PathPrefix 
      value: /coffee 
    headers: 
    - name: version 
      value: v2 
  - path: 
      type: PathPrefix 
      value: /coffee 
    queryParams: 
    - name: TEST 
      value: v2 
  backendRefs: 
  - name: coffee-v2-svc 
    port: 80

因此，在以下兩種情況下，資料平面會以 /coffee 開頭的URI 請求路由到 Service coffee-v2-svc：請求頭版本為 v2，或查詢參數 TEST 為 v2（例如規則2 中的 /coffee?TEST=v2 ）。同時，資料平面將所有對 /coffee的請求路由到 coffee-v1-svc（如規則1 所示）。

請參閱HTTPRoute 文檔，以了解所有支援的功能。

理由2：強大的可擴展性模型

Gateway API 採用強大的可擴充性模型，支援實現暴露API 本身不支援的進階資料平面功能。儘管Ingress controller 可透過應用註解（annotations）支援自訂擴展，從而繞過Ingress 資源的一些限制，但Gateway API 可擴展性模型還是優於Ingress 可擴展性模型。

例如，在下面的範例中，使用NGINX Ingress Controller的註解擴充的資源可啟用一些進階NGINX 功能（對每項功能的說明已作為註解新增至註解旁邊）：

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: webapp  
 annotations: 
    nginx.org/lb-method: "ip_hash" # 選擇 ip_hash 附載均衡方法
    nginx.org/ssl-services: "webapp" # 向後端開啟 TLS 
    nginx.org/proxy-connect-timeout: "10s" # 向後端配置超時 
    nginx.org/proxy-read-timeout: "10s" 
    nginx.org/proxy-send-timeout: "10s" 
    nginx.org/rewrites: "serviceName=webapp rewrite=/v1" # 重寫請求 URI 
    nginx.com/jwt-key: "webapp-jwk" # 啟用對請求的 JWT 身份驗證 
    nginx.com/jwt-realm: "Webb App" 
    nginx.com/jwt-token: "$cookie_auth_token" 
    nginx.com/jwt-login-url: "https://login.example.com" 
spec: 
  rules: 
  - host: webapp.example.com 
  . . .

註解（annotations）本不適合用於表達如此大量配置，它只是簡單的鍵值字串對，缺乏結構、驗證和細粒度。 （我們所說的「缺乏細粒度」是指註解應用於整個資源，而不是像Ingress 資源中的單一路由規則那樣應用於資源的某些部分。）

Gateway API 包含一個功能強大的無註解可擴充性模型。此模型具有多個擴充點、自訂篩選器、策略附加及目的地，可支援Gateway API 實作透過能夠提供結構和驗證的自訂資源來提供進階資料平面功能。此外，使用者還可對資源的每個部分（如路由規則）套用擴展，從而進一步增加細粒度。

例如，以下是一個假想的Gateway API 實作的自訂過濾器，它透過對/coffee 規則精細應用速率限制來增強HTTPRoute 中的路由規則：

rules: 
- matches: 
  - path: 
      type: PathPrefix 
      value: /coffee 
  filters: 
  - type: ExtensionRef 
    extensionRef: 
      group: someproxy.example.com 
      kind: RateLimit 
      name: coffee-limit 
  backendRefs: 
  - name: coffee 
    port: 80

這樣，Gateway API 實作將 coffee-limit 自訂資源中配置的篩選器套用到 /coffee 規則，其中速率限制規格如下所示：

rateLimit: 
  rate: 10r/s 
  key: ${binary_remote_addr}

註：本例只是一個可能的擴展，而非具體實例，因為NGINX Gateway Fabric 專案尚未利用Gateway API 可擴展性模型。不過，未來這種情況將會改變，因為該專案將支援許多擴展，可讓使用者獲得Gateway API 無法提供的進階NGINX 功能。

理由3：角色分離

Ingress 資源僅支援單一使用者角色（應用程式開發人員），該角色全權控制流量到達Kubernetes 叢集中應用的方式。但這種控制層級往往沒有必要，甚至可能妨礙多個開發人員團隊安全地共享資料平面基礎設施。

Gateway API 將部署和配置基礎設施的職責分​​給三個角色：基礎設施提供者、叢集維運人員及應用開發人員。下表匯總了這些角色。

角色 Gateway API 資源的擁有者 職責
基礎設施提供者 GatewayClass 管理叢集相關基礎設施**
集群維運人員 Gateway, GatewayClass*為應用程式開發人員管理集群
應用程式開發者 HTTPRoute 管理應用

*如果叢集維運人員安裝並管理Gateway API 實現，而非使用基礎設施提供者提供的實現，那麼他們將管理GatewayClass 資源。

**類似於提供託管Kubernetes 叢集的雲端提供者。

上述角色實現了RBAC 執行的職責分工。這種分工適用於企業的常見情況，即平台團隊（集群維運人員）管理資料平面基礎設施，並希望在叢集中的多個開發人員團隊（應用開發人員）之間進行安全共享。

理由4：可移植性

Gateway API 的兩個方面提高了其可移植性：

  • 功能– 如理由1 所述，大量功能減少了對特定Gateway API 實作擴充API 的需求，這意味著使用者將不太依賴這些API。相比之下，Ingress 用戶高度依賴其Ingress controller 的特定擴充。
  • 一致性測試– Gateway API 具有測試功能，可確保不同實作以一致的方式支援API 功能。若要確保實現一致性，就必須通過一致性測試，如NGINX Gateway Fabric的測試結果所示。

由於這種可移植性，使用者可以輕鬆地從一個Gateway API 實現切換到另一個Gateway API 實現，這遠比切換Ingress controller 簡單得多。

理由5：社群

Gateway API 是一個社群驅動型項目，也是處於起步階段的新項目。如果您希望為該專案貢獻一己之力— 無論是透過提出新功能還是提供回饋意見，請造訪該專案的貢獻頁面。

如何試用Gateway API

試用Gateway API 只需簡單兩步驟：

  1. 將Gateway API 安裝到Kubernetes 叢集中。
  2. 安裝一個Gateway API 實作。

NGINX 建立了一個Gateway API 實作— NGINX Gateway Fabric。此實作將NGINX 用作資料平面。若要試用，請按照其最新版本的安裝說明進行操作。如要提出問題或參與項目，請查看我們的貢獻指南。

我們的文件提供了若干指南和範例，展示了Gateway API 支援的不同用例。如需更多支援，請查看Kubernetes Gateway API 專案頁面上的指南。

附註： NGINX Gateway Fabric 是一個新項目，與我們類似的NGINX Ingress Controller項目相比，它尚未達到成熟的水平。此外，儘管NGINX Gateway Fabric 支援Gateway API 的所有核心功能（請參閱理由1），但尚未為NGINX 常用功能提供Gateway API 擴充（請參閱理由2），而NGINX Ingress Controller 具備這些功能。

總結

Kubernetes Gateway API 是一個新的社群項目，旨在消除Ingress 資源的限制。我們闡述了試用這項全新API 的五個理由，並簡要介紹了基於NGINX 的Gateway API 實作— NGINX Gateway Fabric。

NGINX Gateway Fabric 將會是我們全力打造的一款Gateway API 的原生NGINX 實作。我們誠摯邀請您一起加入，共同塑造Kubernetes 應用互聯的未來！

您可透過以下方式加入NGINX Gateway Fabric 專案：

  • 以貢獻者的身份加入項目
  • 在實驗室中試用實現
  • 執行測試並提供回饋

如欲加入該項目，請造訪GitHub 上的NGINX Gateway Fabric。

查看原文：NGINX

標籤