最近 Envoy Gateway 0.2 发布了，API 网关的生态系统迎来了新的变化。这篇文章将想你介绍 Kubernetes API 网关领域的新进展。
如何将外部的网络请求路由到 Kubernetes 集群?你可以使用入口控制器：一组 HTTP 反向代理，将流量转接到集群中，并由 operator 来管理。也可以使用 Ambassador、Contour、Traefik 或 HAproxy 这类软件。还可以使用云提供商的解决方案，或者只是用默认的的 Nginx Ingress。或者你可能使用一个功能更全面的 API 网关，如 Tyk 或 Kong，或者在 Kubernetes Ingress 前面的另一层有一个单独的网关，如 AWS 的 API 网关，或内部的 F5，可以选择的实在太多。
为什么我们需要一个新的入口控制器
因为很多入口控制器都有不同程度的限制：有些是基于旧的技术，如 Nginx、HAproxy，甚至是基于 Apache 建立的。这些技术的特性不适用于云原生环境，比如在配置改变时放弃已建立的连接(如果你想深入了解，Ambassador 发表了一篇比较文章)。云供应商的产品确实倾向于基于更现代的东西(比如 SDN[3])，但是这可能产生厂商锁定。目前，你只需用一个 Kubernetes API 来指定所有不同选项的配置：Ingress。这个 API 的可配置项很少，几乎任何你想配置的设置都需要通过 annotation 来实现，而不是作为一类字段。
Envoy Gateway：未来 Gateway 发展的基础
现在又有了新的选择：Envoy Gateway，简称 EG。顾名思义，这是一个基于 Envoy 代理的网关(入口控制器)。它是一个托管在 GitHub 上的 Envoy 社区项目。除了这个基于 Envoy 的入口;已经有流行的建立在 Envoy 之上的 Contour 和 Ambassador 等项目。但是这些项目的开发者和更多的人正在一起为 EG 做出贡献，Ambassador 和 Contour 都说他们会在适当的时候在 Envoy Gateway 的代码上重构(也就是说，我们 Tetrate 公司无可否认地为我们在这个项目中的领导作用感到自豪)。
Envoy 本身是久经考验的入口代理、sidecar 代理，并且正在准备取代谷歌的 GFE。
代码演示
如果你想在了解更多关于 Envoy Gateway 的内容之前先演练一番，我已经写了一篇姐妹篇 ，其中有详细的说明，可以自己设置 Envoy Gateway，如果你没有环境，那篇文章中也包括了我机器上所有的命令输出，这样你就可以看到会发生什么。
通往 API 的 Gateway
Envoy Gateway 以其最简单的形式 —— 你可能刚刚设置好的系统，将请求转发到其集群中。它根据 HTTP host 和 path 进行路由，也可以根据其他 header 进行路由。每个集群都需要这样做，很高兴看到 Envoy Gateway 在开发的短短 6 个月内就能做到这一点(要了解更多关于 Envoy Gateway 的信息，请看 Gateway to a New Frontier。
超越基本入口的高级功能
然而，许多组织需要比这个基本的 7 层网络路由更多的功能。如果需要像 WAF、body 的模式验证、bot 拦截等，许多人就会使用 API 网关。我们看到很多组织在他们的入口控制器前面部署了一个单独的 API 网关。然而，API 网关可以取代入口控制器，因为它也可以做路由和流量观察的基本功能。它们可以提供这些功能，因为它们是由与入口控制器相同的代理构建的，例如，Kong 是基于 nginx 的。API 网关产品在市场上很受欢迎，但如果你真的想一想 API 网关是什么，它就是一个 HTTP 代理，有一系列的附加功能(我之前提到的 WAF 等)。这并不是说它们不增加任何价值 —— 它们提供的功能是多种多样的，而且很强大，但有一个共同的功能基线和实现代码。
使用 Wasm 的动态可扩展性
因此，Envoy Gateway 完全有能力发展成为一个全功能的 API 网关。Envoy 实际上已经具备了一些更先进的功能，包括 JWT 验证、OIDC 认证流和速率限制。此外，Envoy 是动态可扩展的;它可以在不重启的情况下加载插件，这意味着可以很容易地按需添加更多的功能。这些插件是以 WASM 字节码的形式提供的，这意味着它们可以用任何可以编译成 WASM 的语言(Tiny Go、Rust 等)编写，而不仅仅是其他代理支持的脚本语言。社区正在开始编写这些插件：缓存可能会首先落地，Coraza[8] 项目是一个相对成熟的 mod_security 风格的 WAF，用 Go 编写，可以编译成 WASM，现在可以用于 Envoy 代理。
Gateway API 鼓励扩展
在入口控制器市场上，扩展和竞争的另一大障碍是 API。需要特定于供应商的注解(或全新的特定于供应商的 API)，这些注解很笨重，而且妨碍了交叉兼容。相比之下，Envoy Gateway 是由 Gateway API 配置的，这是 gateway.networking.k8s.io API 组的一组资源。这个 API 将最终取代 Ingress 资源。它的核心已经比 Ingress 更加灵活和富有表现力，而且它被设计成以可管理的方式增长和扩展。这将允许它发展成为所有南北流量控制的模型，从基本的路由到先进的 API 管理功能。这反过来又会将 Envoy Gateway 拥有的所有功能，以一种标准的、与供应商无关的方式暴露出来，让人们在使用这些功能时无需跳过障碍或担心锁定问题。Envoy Gateway 将在 2023 年 3 月的 0.3 版本中支持 Gateway API 的这些新部分。
为未来的网关发展提供一个共同的的基础
Envoy Gateway 的动力来自于对 API 网关功能堆栈的日益关注。基本的入口正在变得商业化，所以社区正在汇集其资源和专业知识，为未来的网关开发创造一个共同的基础。同时提供新的 Gateway API 供其实现是非常方便的，Envoy Gateway 的 0.2 版本标志着对目前定义的 Gateway API 核心类型的全面支持。
扩展到高级用例模型的工作已经开始，现在正在设计 JWT auth 配置，其他的也将陆续推出。插件本身的工作也已经开始(例如，Coraza，一个仿照无处不在的 mod_security 的 Golang WAF)。虽然这些都有很长的路要走，但我个人非常期待看到这一切在未来一两年的发展。
通往服务网格的 Gateway
你可能在想，已经有一类产品支持 OIDC 认证和速率限制等功能了：服务网格。这是真的;最突出的网格，Istio，在其默认配置中为入口部署了一套代理服务器。Istio 现在支持 Gateway API(就像 Envoy Gateway 一样)来配置该入口。我们在 Tetrate 对这种融合感到兴奋：企业现在可以采用 Envoy Gateway 来简单而快速地开展工作。Envoy Gateway 在管理这种南北流量方面做得很好，运行它可以让他们了解 Envoy 在生产中的性能和操作特点。当这些组织准备好控制他们的服务到服务，也就是东西向流量时，他们可以部署 Istio，因为他们已经熟悉了主要的基础组件(Envoy)。虽然他们可能会选择使用 Istio 的入口网关(以保持他们的控制平面数量减少到 1)，但他们现有的 Gateway API 资源将继续工作。由于同样基于 Envoy，Istio 的 Ingress 也可以接受任何加载到 Envoy Gateway 的 API Gateway 风格的插件。所有这一切都使得在必要时增加服务网格的力量变得非常容易。
用于入口和服务网格的统一 Gateway API
更重要的是，现在已经有了一个工作组来协调网关和网格网络之间的重叠部分：GAMMA 倡议 [10]。GAMMA 是 Gateway API for Mesh Management and Administration 的缩写，这是对 Gateway API 未来发展方向的一个倡议;计划是开始对服务网格的关注进行建模，即东西向流量也是如此。GAMMA 将确保 Envoy Gateway 和服务网格的良好合作，并将关注 Gateway API 的统一，以涵盖入口和网格。我们很高兴看到，这将为许多组织轻松和逐步地采用服务网格，基于一个与产品无关的 API，这对所有人都是好事。
结束语
这篇文章对新的标准 API、Gateway API 和参考实现 Envoy Gateway 作了很好的介绍，希望能对你了解当前的入口网关生态有所帮助。
如果你想关注 EG 的发展，你可以加入 Envoy slack 的 #gateway 频道，并在 查看提交和问题。该项目有一个 未来几个版本的路线图 ，0.3.0 版本发布预期是在 2023 年 3 月。
如果你想测试一下 Envoy Gateway，我写了一个配套的教程，其中包含了启动和运行的步骤说明。
如果你正在开始使用 Istio 和 Envoy，请查看 Tetrate 学院，你会发现大量的免费课程、研讨会，以及 Tetrate 的 Istio 管理员认证考试。
要想以最简单的方式安装、管理和升级 Istio，请查看开源 Tetrate Istio 发行版(TID)[13]。TID 是一个经过审查的 Istio 的上游发行版 ——Istio 的加固镜像，具有持续的支持，更容易安装、管理和升级。