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

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

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

Gateway API 中的服务网格支持

虽然 Gateway API 的最初重点始终是入口（南北）流量，但几乎从一开始就清楚，相同的基本路由概念也应适用于服务网格（东西）流量。在 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 服务的 5000 端口的任何请求，如果其标头为 env: v1，则将被路由到 demo-app-v1，而任何没有该标头的请求都将被路由到 demo-app-v2——由于这是由服务网格而不是入口控制器处理的，因此 A/B 测试可以发生在应用程序的调用图中的任何位置。

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

Gateway API 一直在对其支持的所有功能进行大量一致性测试，网格也不例外。GAMMA 计划遇到的一个挑战是，许多此类测试都与给定实现提供入口控制器的想法紧密相关。许多服务网格并非如此，并且要求符合 GAMMA 的网格也实现入口控制器似乎充其量是不切实际的。这导致了关于 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 版本准备 Gateway API，在该版本中，HTTPRoute、Gateway 和 GatewayClass 将升级到 GA。与此相关的有两个主要更改：CEL 验证和 API 版本更改。

CEL 验证

第一个主要更改是，Gateway API v0.8.0 开始从 webhook 验证过渡到使用构建在 CRD 中的信息进行CEL 验证。这将根据您使用的 Kubernetes 版本意味着不同的事情

Kubernetes 1.25+

完全支持 CEL 验证，并且几乎所有验证都在 CEL 中实现。（唯一的例外是，标头修改器过滤器中的标头名称只能执行不区分大小写的验证。有关详细信息，请参见问题 2277。）

我们建议不要在这些 Kubernetes 版本上使用验证 webhook。

Kubernetes 1.23 和 1.24

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

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

Kubernetes 1.22 及更早版本

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

API 版本更改

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

如何开始使用 Gateway API？

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

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

如果您特别有兴趣为 Gateway API 做出贡献，我们很乐意为您效劳！请随时在存储库上打开一个新问题，或加入讨论。另请查看社区页面，其中包含 Slack 频道和社区会议的链接。我们期待见到您！！

进一步阅读

• GEP-1324提供了 GAMMA 目标和一些重要定义的概述。对于其对问题空间的讨论，此 GEP 非常值得一读。
• GEP-1426定义了如何使用 Gateway API 路由资源（例如 HTTPRoute）来管理服务网格内的流量。
• GEP-1686建立在GEP-1709的工作基础上，定义了服务网格的一致性配置文件，以声明符合 Gateway API。

尽管这些是实验性模式，但请注意，它们在标准发布通道中可用，因为 GAMMA 计划迄今为止不需要引入新的资源或字段。

• ←上一篇
下一篇→