云原生 2.0 网关 API 标准发展趋势

2023-04-20
广东
本文字数：4070 字
阅读完需：约 13 分钟

本文分享自华为云社区《云原生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 EU2022 上，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 的支持普遍比较初级：

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 挂载，允许在网关、路由中插入个性化的策略控制。

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 网关的标准将会统一。

在当前的历史契机下，华为云应该牢牢把握机会，基于 Gateway API 推出自己的云原生网关服务，这将是一次难得的弯道超车的好机会。添加小助手微信 k8s2222，进入技术交流群。