本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Gateway API v0.8.0：引入服务网格支持

作者：Flynn (Buoyant)、John Howard (Google)、Keith Mattix (Microsoft)、Michael Beaumont (Kong)、Mike Morris (independent)、Rob Scott (Google) | 2023 年 8 月 29 日，星期二

我们很高兴地宣布 Gateway API v0.8.0 发布！随着此版本的发布，Gateway API 对服务网格的支持已达到实验性状态。我们期待你的反馈！

我们特别高兴地宣布，Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都是完全符合 Gateway API 服务网格支持的实现。

Gateway API 中的服务网格支持

虽然 Gateway API 最初的重点始终是 Ingress（南北向）流量，但几乎从一开始就很清楚，相同的基本路由概念也应该适用于服务网格（东西向）流量。2022 年，Gateway API 子项目启动了 GAMMA 倡议，这是一个专门的、与供应商无关的工作流，专门研究如何最好地将服务网格支持融入 Gateway API 资源的框架中，而不需要 Gateway API 的用户重新学习他们对 API 的所有理解。

在过去的一年中，GAMMA 深入研究了围绕使用 Gateway API 实现服务网格的挑战和可能的解决方案。最终的结果是少数几个增强提案，其中包含了数小时的思考和辩论，并为允许 Gateway API 用于服务网格提供了一条最小可行的路径。

使用 Gateway API 时，网格路由将如何工作？

你可以在 Gateway API 网格路由文档和 GEP-1426 中找到所有细节，但 Gateway API v0.8.0 的简短版本是，HTTPRoute 现在可以有一个作为 Service 的 parentRef，而不仅仅是 Gateway。随着我们对服务网格用例的经验越来越多，我们预计未来会有更多的 GEP 在这个领域出现——绑定到 Service 使得将 Gateway API 与服务网格一起使用成为可能，但仍有一些有趣的用例难以覆盖。

例如，你可以使用 HTTPRoute 在网格中进行 A/B 测试，如下所示：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: demo-app
    port: 5000
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: v1
    backendRefs:
    - name: demo-app-v1
      port: 5000
  - backendRefs:
    - name: demo-app-v2
      port: 5000

任何对 demo-app Service 的 5000 端口且带有 env: v1 标头的请求都将被路由到 demo-app-v1，而任何没有该标头的请求都将被路由到 demo-app-v2——并且由于这是由服务网格而不是 Ingress 控制器处理的，A/B 测试可以发生在应用程序调用图的任何地方。

我如何知道这将是真正可移植的？

Gateway API 一直在其支持的所有功能上大力投入一致性测试，网格也不例外。GAMMA 倡议遇到的挑战之一是，许多这些测试都与一个给定的实现提供一个 Ingress 控制器的想法紧密相连。许多服务网格并不提供，并且要求一个符合 GAMMA 的网格也实现一个 Ingress 控制器，这至少看起来是不切实际的。这导致了 Gateway API 一致性配置文件工作的重启，如 GEP-1709 中所讨论的。

一致性配置文件的基本思想是，我们可以定义 Gateway API 的子集，并允许实现选择（并记录）它们符合哪些子集。GAMMA 正在添加一个名为 Mesh 的新配置文件，并在 GEP-1686 中进行了描述，它只检查 GAMMA 定义的网格功能。此时，Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都符合 Mesh 配置文件。

Gateway API v0.8.0 中还有什么？

此版本旨在为即将发布的 v1.0 版本做准备，其中 HTTPRoute、Gateway 和 GatewayClass 将升级到 GA。与此相关的有两个主要变化：CEL 验证和 API 版本变化。

CEL 验证

第一个主要变化是，Gateway API v0.8.0 是从 webhook 验证过渡到使用 CRD 中内置信息的 CEL 验证的开始。这将意味着不同的事情，具体取决于你使用的 Kubernetes 版本：

Kubernetes 1.25+

CEL 验证得到完全支持，并且几乎所有验证都在 CEL 中实现。（唯一的例外是标头修饰符过滤器中的标头名称只能进行不区分大小写的验证。更多信息请参见 issue 2277。）

我们建议在这些 Kubernetes 版本上**不**使用 validating webhook。

Kubernetes 1.23 和 1.24

不支持 CEL 验证，但仍可以安装 Gateway API v0.8.0 CRD。当你升级到 Kubernetes 1.25+ 时，这些 CRD 中包含的验证将自动生效。

我们建议在这些 Kubernetes 版本上继续使用 validating webhook。

Kubernetes 1.22 及更早版本

Gateway API 仅承诺支持最近 5 个版本的 Kubernetes。因此，Gateway API 不再支持这些版本，并且不幸的是，Gateway API v0.8.0 无法安装在这些版本上，因为包含 CEL 验证的 CRD 将被拒绝。

API 版本变更

在我们准备 v1.0 版本，将 Gateway、GatewayClass 和 HTTPRoute 从 v1beta1 升级到 v1 API 版本时，我们正在继续将已升级到 v1beta1 的资源从 v1alpha2 中移出。有关此变更以及此版本中包含的所有其他内容的更多信息，请参阅 v0.8.0 发行说明。

如何开始使用 Gateway API？

Gateway API 代表了 Kubernetes 中负载均衡、路由和服务网格 API 的未来。已经有超过 20 个实现可用（包括 Ingress 控制器和服务网格），并且这个列表还在不断增长。

如果你有兴趣开始使用 Gateway API，请查看 API 概念文档，并查看一些指南来尝试一下。因为这是一个基于 CRD 的 API，所以你可以在任何 Kubernetes 1.23+ 集群上安装最新版本。

如果你特别有兴趣为 Gateway API 做出贡献，我们非常欢迎你！请随时在仓库上开启一个新 issue，或者加入讨论。也请查看社区页面，其中包含 Slack 频道和社区会议的链接。我们期待你的加入！

Kubernetes 博客