雲原生2.0閘道器API標準發展趨勢

摘要：Gateway API希望取代Ingress API。

本文分享自華為雲社群《雲原生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）。筆者認為這裡主要有兩方面的原因：

- Ingress存在已久，並且是幾乎所有的Ingress Controller的預設實現，Kubernetes的使用者早已習慣Ingress，儘管Ingress在易用性和功能豐富度上面存在很大的差距。

- 服務網格或者API閘道器專案，例如Istio、Linkerd、Kong、Contour、Ambassador等都有自己的API標準，Gateway API使用者接受度還不夠高。

- 由於Gateway API並沒有強大的使用者基礎，因而缺少功能、體驗上的反饋，因而迭代比較緩慢。

什麼是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 EUateway 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的支援普遍比較初級：

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終結。

```yaml
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"標籤。

```yaml
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開發者也可以定義自己的路由然後繫結到閘道器。

```yaml
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掛載，允許在閘道器、路由中插入個性化的策略控制。

從上圖可以看到，無論是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閘道器的標準將會統一。

在當前的歷史契機下，華為雲應該牢牢把握機會，基於Gateway API推出自己的雲原生閘道器服務，這將是一次難得的彎道超車的好機會。新增小助手微信k8s2222，進入技術交流群。

參考文獻

點選關注，第一時間瞭解華為雲新鮮技術~