云原生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，進入技術交流群，

參考文獻

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：常用內核架構

下一篇：返回列表