本文发表已超过一年。较旧的文章可能包含过时内容。请确认页面中的信息自发表以来是否仍然正确。

Gateway API v0.8.0：引入 Service Mesh 支持

作者：Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (独立), 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 而不是 Gateway 的 parentRef。随着我们对服务网格用例获得更多经验，我们预计未来在此领域会有更多 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 端口、带有 header env: v1 的请求将被路由到 demo-app-v1，而任何不带该 header 的请求将被路由到 demo-app-v2 -- 并且由于这是由服务网格而非 ingress controller 处理，因此 A/B 测试可以在应用的调用图中的任何位置进行。

我怎么知道这会是真正可移植的？

Gateway API 一直在一致性测试方面投入大量精力，涵盖其支持的所有特性，服务网格也不例外。GAMMA 项目遇到的挑战之一是，许多测试与某个实现提供 ingress controller 的想法紧密相关。许多服务网格不提供 ingress controller，要求符合 GAMMA 规范的服务网格也实现 ingress controller 似乎充其量是不切实际的。这导致重新启动了关于 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 中还有什么？

本次发布主要是为 Gateway API 的即将到来的 v1.0 版本做准备，其中 HTTPRoute、Gateway 和 GatewayClass 将升级到 GA（通用可用）。与此相关的有两个主要变化：CEL 验证和 API 版本变更。

CEL 验证

第一个主要变化是，Gateway API v0.8.0 开始从 webhook 验证过渡到使用内置在 CRD 中的信息进行CEL 验证。这意味着根据你使用的 Kubernetes 版本会有不同的情况：

Kubernetes 1.25+

完全支持 CEL 验证，几乎所有验证都在 CEL 中实现。（唯一的例外是 header modifier filter 中的 header 名称只能进行不区分大小写的验证。在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 API 版本升级到 v1）时，我们正在继续淘汰已升级到 v1beta1 的资源的 v1alpha2 版本。有关此变更以及此版本中包含的所有其他内容的更多信息，请参阅v0.8.0 发布说明。

如何开始使用 Gateway API？

Gateway API 代表着 Kubernetes 中负载均衡、路由和服务网格 API 的未来。目前已有超过 20 个实现可用（包括 ingress controller 和服务网格），并且列表仍在不断增长。

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

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

Kubernetes 博客