雲原生 2-0 網關 API 標準發展趨勢

## 雲原生網關 API 標準背景及發展現狀  

Gateway API 是一個開源的 API 標準，源自 Kubernetes SIG-NETWORK 興趣組。從出身角度講，可謂根正苗紅，自從開源以來備受關注，被寄予厚望。Gateway API 旨在通過聲明式、可擴展性和麪向角色的接口來發展 Kubernetes 服務網絡，並且希望成爲供應商的網關 API 標準並獲得廣泛行業支持。簡而言之，Gateway API 希望取代 Ingress API。

Gateway API 項目自 2019 年開源，但是經歷了緩慢的發展，直到 2022 年 7 月才發佈 Beta 版本，同時發起了 GAMMA（Gateway API for Mesh Management and Administration）。筆者認爲這裏主要有兩方面的原因：

▍ 什麼是 GAMMA

GAMMA (Gateway API for Mesh Management and Administration) 是 Gateway API 項目的一個工作組。該小組的目標是調查、設計和跟蹤網關 API 資源、語義，並負責其他與服務網格技術和用戶使用場景相關的工件。此外，GAMMA 倡導服務網格項目的網關 API 實現之間的一致性，無論 Istio 還是 Linkerd，大家最好都來遵守這裏定義的 API 規範和標準。

GAMMA 的 Lead 團隊由來自 Google 的 John Howard（Istio），來自微軟的 Keith Mattix（Open Service Mesh）和來自 HashiCorp 的 Mike Morris（Consul）組成，在不同組織和服務網格項目的推動下，Gateway API 有望統一服務網格 API。

▍ 推波助瀾

KubeCon EU 2022 上，Envoy Gateway 的指導組，包括 Envoy 創始人 Matt Klein，以及來自 Ambassador、Fidelity 、Tetrate 和 VMware 的代表共同宣佈將開源 Envoy Gateway 項目，將 Envoy 用作 “開箱即用” 的基本 API 網關和 Kubernetes Ingress 控制器。通過實現 Kubernetes Gateway API， EG 將會使 Envoy 擴展更加容易。

Envoy 上游開源一個網關項目，並且 EG 是站在 Ambassador 以及 Contour 等項目的肩膀上前進，給普通開發者帶來無限的遐想。最重要的是，EG 是第一個主要實現 Gateway API 的項目，這一操作也爲 Gateway API 帶來新的活力，直接推動 Gateway API 在 7 月份發佈了 Beta 版本。

## Gateway API 生態  

前面提到 Envoy Gateway 項目宣佈以 Gateway API 爲唯一的網關標準，並且 EG 也是唯一一個只遵守 Gateway API 標準的 Ingress 網關項目。其他實現者，都是在自身 API 的基礎上，額外支持 Gateway API。並且對 Gateway API 的支持普遍比較初級：

6b0Ov6

Gateway API 絕不僅僅關注南北向流量治理策略的標準，東西向流量也是它所重點覆蓋的方向。南北向主要是一些網關項目的領地，東西向是服務網格的領地。當然服務網格如 Istio 都有自己的 Ingress Gateway, 能夠對北向流量進行管理。東西向流量從特徵上要比南北向流量更多，因爲客戶端在集羣中，可以通過 Labels 標籤表示客戶端的屬性，通過 ServiceAccount 標識身份。網格在東西向流量治理時能夠充分利用 K8s 工作負載的標籤、身份進行更多的路由、安全策略控制。Gateway API 標準在東西向流量這一塊目前並沒有對等服務網格現有的能力，具體在最後一章再來進行對比。前期 Gateway API 主要關注的還是南北向的流量治理標準，這與它 “取代 Ingress” 的設計初衷相符。

Gateway API 設計  

Gateway API 基於可移植、可擴展、表達性強以及面向不同角色四個原則設計。

- 可移植： 相對 Ingress 來說這一點並不是改進，而是保持與 Ingress 一致，通過通用的規範，能讓更多的網關輕鬆實現。而 Gateway API 所追求的領域絕不僅限於南北向網關，而且它還要覆蓋服務網格。

- 表達性強： Gateway API 支持核心功能，如基於 Header 匹配、流量權重分隔以及其他功能，這些功能只有在 Ingress 中通過自定義註釋 Annotation 才能實現。

- 可擴展： Gateway API 允許引用其他的自定義資源對象，這使得在 API 結構中的適當位置進行個性化定製成爲可能。

- 面向角色： 從上圖可見 Gateway 由不同的 API 資源構成，分別爲不同的角色設計。其中應用開發者定義 HTTPRoute，集羣維護者定義 Gateway 對象，基礎設施提供者定義 GatewayClass。

本章選取面向角色和可擴展性兩個最具代表性的設計原則，詳細解釋 Gateway API 的設計。

▍ 面向角色的 API 設計

無論是道路、電力、數據中心還是 Kubernetes 集羣，基礎設施都是爲共享而構建的。然而，共享基礎架構提出了一個共同的挑戰 -- 如何爲基礎架構的用戶提供足夠的靈活性，同時保持基礎架構所有者的獨立控制？

Gateway API 通過面向角色的設計爲 K8s 服務網絡提供靈活的控制，該設計在分佈式靈活性和集中控制之間取得了平衡。它允許許多不同的團隊使用共享網絡基礎架構（硬件負載平衡器、雲網絡、網關等），所有這些團隊都受集羣維護者設置的策略限制和約束。如下是 Gateway API 官網的實例，集羣維護者通過 Gateway 定義流量入口，以及 TLS Terminate。集羣中有兩個租戶，其中存儲開發者在 Store 命名空間部署了自己的微服務，站點開發者在 Site 命名空間也部署了自己的微服務。他們在集羣網關上共用同一域名，同一端口，因此網關只能通過匹配不同的 HTTP Authority 來路由客戶端的請求。路由策略的設置則是由應用開發者們（Store、Site 開發者）自己定義，然後綁定到同一個 Gateway 上。

下面通過一個官方示例，爲大家展示不同的角色如何根據自己的權限來定義服務的治理策略。

集羣維護者通過 Gateway 定義 Listener 以及允許綁定的路由策略。如下 *shared-gateway * 表示在 443 端口監聽連接，通過 *foo-example-com * 證書在網關處做 TLS 終結。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra-ns
spec:
  gatewayClassName: shared-gateway-class
  listeners:
  - name: https
    hostname: "foo.example.com"
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            shared-gateway-access: "true"
    tls:
      certificateRefs:
      - name: foo-example-com

集羣維護者定義只允許以下命名空間的路由策略能夠綁定網關，因爲它們有 shared-gateway-access: "true" 標籤。

apiVersion: v1
kind: Namespace
metadata:
  name: infra-ns
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: site-ns
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: store-ns
  labels:
    shared-gateway-access: "true"

Store 開發者可以定義以下 HTTP 路由，當請求路徑前綴是 / store 時，將其路由到 store 服務，同理 Site 開發者也可以定義自己的路由然後綁定到網關。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
  namespace: store-ns
spec:
  parentRefs:
  - name: shared-gateway
    namespace: infra-ns
  rules:
  - matches:
    - path:
        value: /store
    backendRefs:
    - name: store
      port: 8080

這裏可以看出，不同角色權限控制比較嚴格，只有集羣維護者允許的路由策略才能綁定到網關上。應用開發者，只能對所擁有的服務具有控制權。

▍ 可擴展性 - Policy 掛載

策略掛載提供了高擴展性，雖然超時，重試，以及個性化的健康檢查在一些網關實現中很常見，但是大多數網關的實現方式是不同的，沒有統一的 API 標準。保持這類 API 的一致性變得艱難，所以 Gateway API 特意設計了 Policy 掛載，允許在網關、路由中插入個性化的策略控制。

Ingress 策略掛載

Mesh 策略掛載

從上圖可以看到，無論是 Gateway 還是 HTTPRoute 都允許任意引用其他的策略，此設計大大提高了 Gateway API 的擴展能力。

Gateway API 還有多遠  

Gateway API 與其他主流 API 對比

從上述功能豐富度對比來看，Istio API > Gateway API > Ingress, 然而 Gateway API 通過 Reference 其他自定義對象提供的擴展能力明顯強於 Istio。儘管當前 Gateway API 沒有提供故障注入，超時、重試，限流等策略，但是通過它超強的擴展能力能夠很容易做到。

閱讀本文，大家對 Gateway API 一定充滿了好奇，Gateway API 距離成熟、大規模商用還有多遠？

首先從目前的生態分析，Gateway API 被 Kubernetes 圈普遍認可，包括開源項目、甚至商業服務 GKE 的支持。歸根到底，Gateway API 由 Kubernetes 網絡組發起、維護，並且吸引了大量開源網絡項目的維護者參與。當然實際背後控制者是 Google，Google 在開源技術的領導力毋庸置疑。但是不得不認識到，目前所有 Gateway API 的支持都處於初級階段。

其次，從兼容性的角度看，一些成熟的項目，比如 Istio，用戶長期以來習慣了 Istio 的 API 標準，Istio 社區也不會貿然的廢棄原有的 API，轉而只支持 Gateway API。因此這種多種 API 並存的局面將會持續很久，即使在未來 Gateway API 成熟了。

最後，前面講到 Gateway API 對超時、重試、故障注入等能力預留了擴展能力，但是這種基本的網絡能力，Gateway API 應該提供標準的 API，而不是讓用戶自己去定義私有的標準。 這也違背了 Gateway API 想要統一服務網絡標準的初衷。除此之外，靈活的擴展性如果違背了易用性，顯然用戶是不會買賬的。

綜上所述，筆者認爲至少在一兩年之內，Gateway API 將會持續迭代，短時間內很難形成成熟的標準。或許可以期待，2024 年以後服務網格和 API 網關的標準將會統一。

參考文獻

  1. Kubernetes gateway API 官網：https://gateway-api.sigs.k8s.io/

  2. https://blog.envoyproxy.io/introducing-envoy-gateway-ad385cc59532

  3. Istio 官網：https://istio.io/

  4. Nginx Ingress Controller: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/T7gaRolxtQULz2qY04Dp4A

猜你喜歡