layout: blog
title: "Gateway API v0.8.0：引入服务网格支持"
date: 2023-08-29T10:00:00-08:00
slug: gateway-api-v0-8
作者： Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google)
译者： Xin Li (Daocloud)
我们很高兴地宣布 Gateway API 的 v0.8.0 版本发布了！
通过此版本，Gateway API 对服务网格的支持已达到实验性（Experimental）状态。
我们期待你的反馈！
我们很高兴地宣布 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 Mesh 路由文档和 GEP-1426 中找到所有详细信息，
但对于 Gateway API v0.8.0 的简短的版本是现在 HTTPRoute 可以设置 parentRef，
它是一个 Service，而不仅仅是一个网关。随着我们对服务网格用例的经验不断丰富，我们预计在这个领域会出现更多
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 控制器。
许多服务网格不提供 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 版本上不使用验证 Webhook。
Kubernetes 1.23 和 1.24
不支持 CEL 验证，但仍可以安装 Gateway API v0.8.0 CRD。
当你升级到 Kubernetes 1.25+ 时，这些 CRD 中包含的验证将自动生效。
我们建议在这些 Kubernetes 版本上继续使用验证 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 个实现可用（包括入口控制器和服务网格），而这一列表还在不断增长。
如果你有兴趣开始使用 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 的服务网格定义了一个一致性配置文件。
虽然这些都是实验特性，但请注意，它们可在 standard 发布频道使用，
因为 GAMMA 计划迄今为止不需要引入新的资源或字段。
