Gateway API： 在Kubernetes网络中掀起一场革命

文章转载自 Kong 公众号

在 Kubernetes 世界中，Ingress API 一直是获取集群网络外部对服务访问的长期支柱。多年来，Ingress 为我们提供了良好的服务，在几十个不同的实现中都可以找到它的身影，但随着时间的推移和 Kubernetes 的成长，明显 Ingress 无法满足持续增长的需求。

由于上游入口的范围和规范的限制，各个实现者别无选择，只能在 Kubernetes 资源以及他们自己的自定义资源上使用注解或任意元数据来实现大多数功能。这种 “注解无序状态” 的结果是，任何两个给定的 Ingress 资源在不同实现之间最近的都无法迁移。

我是 Shane Utt , 我和我的共同维护者 Rob Scott (谷歌) 以及 Nick Young (Isovalent) 一起维护 Gateway API。在这篇文章中，我们将分享来自各个组织的贡献者如何在上游创建下一代 Kubernetes 网络 API (Gateway API) 的故事，以及这个项目如何成长为 Kubernetes 历史上最具协作性的 API 之一。

起点

在 2019 年圣迭戈 KubeCon 尾声，来自 Kubernetes 网络特别兴趣小组 (SIG Network) 的一群人，包括 Kong 的 Harry Bagdi, 聚集在一起讨论 Kubernetes 用户的需求。这个群体开创了一段历史，他们启动了 Ingress 的后继项目，这个项目建立在以下目标之上:

• 泛用性

• 表达能力

• 可扩展性

• 面向角色

最大的挑战之一是试图跟上完全新的 Kubernetes API 在上游的高速发展和协作。由于其广泛采用，Kubernetes 本身在获取新功能方面的过程中变得非常缓慢。

考虑到这一点，我们将如何在一个正在朝着长期稳定前进的更大项目的限制中为一个全新的项目生成所需的速度？答案最终体现在 Kubernetes 的扩展系统中：我们决定将该项目作为一个官方的 Kubernetes 项目来开发，但使用自定义资源定义 (CRD) 来部署它们，而不是将它们添加到核心代码库中。这使得 Gateway API 像一个灵活的插件，但仍然是一个官方的 Kubernetes 项目。

直到今天，我们的原始目标在很大程度上保持不变，事实上，它们大多得以进一步扩展。Harry 和他的同伴帮助启动了这个概念，成为 Gateway API 项目的创始维护者之一，这启动了一系列改变 Kubernetes 网络世界的事件。

早期岁月

在 2020 和 2021 年的最初几年，该项目受到社区的重视，并迅速获得采用者的支持，他们为他们的 Ingress 解决方案添加了对 alpha API 的支持。就是在这个时期，Kong 的 Kubernetes 团队向我们的 Kubernetes Ingress Controller (KIC) 添加了初始的 Gateway API alpha 级别支持，并在 Feature Gate 下使其可供用户试用并提供反馈。

与 Ingress 不同，Gateway API 发展为多个单独的、可互操作的 API, 这些 API 与可以满足的不同角色保持一致:

• GatewayClass - 用于指示哪个实现负责 Gateway 资源及其 *Routes, 并且旨在由基础设施提供商管理。

• Gateway - 用于管理代理、负载均衡器等的生命周期和配置。这是为集群操作者设计的。

• HTTPRoute、TCPRoute 和 UDPRoute - 用于第 7 层和第 4 层流量，目的是由应用开发者管理。

不出所料，第 7 层 HTTP 功能是一个明显的赢家，根据实现的数量，成为我们最可扩展和最活跃的用于 Ingress 解决方案的 API, 也是最伟大的单一替代传统 Ingress 资源的选择。在此期间，我们通过添加 Ingress 中不可用的新功能大大超越了 Ingress 的功能，包括但不限于:

• 额外的匹配条件

  • Header 匹配

  • 方法匹配

  • 查询参数匹配

• 安全功能

• 跨命名空间绑定

• 跨命名空间转发

• 全新功能

  • Header 修改器

  • 请求镜像

  • 请求重定向

  • URL 重写

  • 基于权重的流量分担

这个列表持续增长。我们对该项目的承诺与项目的增长相匹配，我们为项目提供了管理和技术指导，以保持项目的前进。Kong 继续投资该项目导致开发基于 “Gateway API 优先” 原则的 Kong Gateway Operator (KGO)。这包括来自 Gateway API 项目的 GatewayClass、Gateway、HTTPRoute、TCPRoute 和 UDPRoute 的支持，作为在 Kubernetes 集群上部署和管理 Kong 控制平面 (KIC) 和数据平面 (Kong Gateway) 的基本 API, 全部基于 Kubernetes operator 原则构建。

在这些年里，社区继续发展，Kubernetes 网络 SIG 继续迭代。2021 年实现的持续增长证明我们可以将 API (GatewayClass、Gateway 和 HTTPRoute) 移动到 beta 版本，从那时起，继续加速采用。

关键质量

2022 年，Gateway API 项目成为社区的一个闪电般的焦点，大量的关注被投入到它身上。讨论在增长，大量新的实现加入支持该项目。现在有 20 多个实现支持 Gateway API, 这个数字持续增长。在 Kubecon 上，Gateway API 已经成为一个 “热门话题”, 有几场演讲都在这个主题上。

继续我们对 Gateway API 的投资，Kong 开发了一个名为 “Blixt” 的负载均衡器。该项目使用 eBPF 作为数据平面和 Gateway API 作为唯一的控制平面 API, 可以以闪电般的速度为入口流量提供服务 (Blixt 在瑞典语中意为 “闪电”) 并支持 TCPRoute 和 UDPRoute 第 4 层入口选项。这个项目有各种目标，许多目标围绕探索新兴技术。但主要目标很快变成支持 Gateway API 中的第 4 层。从这里，我们将这个项目捐赠给 Kubernetes SIGs 社区，以提供 CI 和测试工具，以及 Gateway API 控制平面的参考实现。

在这个时期内 Gateway API 项目正在变革中，我们也看到了项目的范围和目标的巨大增长。也许最显着的变化是 “网关 API 面向网格管理和管理 (GAMMA)” 子项目的开始。在这之前，Gateway API 资源仅被认为用于入口 / 南北向网络流量拓扑，但然后 GAMMA 开辟了一条新道路，几个实现开始尝试使用 HTTPRoute 进行服务网格内的流量。我们的 mesh 团队的成员已经向 Kuma 和 Kong Mesh 的入口添加了 Gateway API 支持。该团队进一步为项目做出了贡献，帮助实验和迭代 GAMMA 以为东西向流量提供 HTTPRoute 支持。

随着项目在 beta 中发展的更深入，显然这确实将是 Kubernetes 网络的未来，特别是现在我们看到我们的 API 通用性足以有效地应用到其他网络上下文，如 mesh。该 API 已准备好实现首个 “通用可用 (GA)” 版本的目标，“通向 GA 之路” 已经开始。

通向 GA 之路

2023 年春天的阿姆斯特丹 KubeCon 上，我们决定我们的目标是在 11 月的芝加哥 KubeCon 美国之前发布 v1.0.0。我们知道这是一个艰巨的任务，但时机已经成熟，稳定该版本，因为许多组织已经在使用 Gateway API beta 资源运行生产系统，每个人的投资需要汇总到一个稳定的方式。在此期间，维护者定期会面 (特别是在最后几个月，我们每周见一次面) 来组织、整理和制定策略以发布这个版本。在这个时候，社区对新功能的兴趣没有衰减，所以我们必须确保对这些想法保持开放并以所有方式为社区服务，同时尽量保持注重发布。

今天，未来已经到来。Gateway API 刚刚在 Kubecon 芝加哥达到了第一个通用可用 (GA) 版本 v1.0.0。从一开始，Gateway API 项目就得到了前所未有的社区支持，现在正式进入聚光灯下，并为 Kubernetes 网络的未来奠定基础。然而，这只是个开端！Gateway API 社区将继续发展和成熟，并提供更多功能以持续为用户创造价值。这也是我们对用户的承诺，因为我们将继续致力于上游开发。

感谢每位帮助 Gateway API 发展至今的人，我们将继续致力于维护和发展该项目，以便为所有 Kubernetes 用户提供更好的服务！