为何我们决定从零开始创建 NGINX Gateway Fabric

原文作者：Brian Ehlert - F5 产品管理总监，Matthew Yacobucci - F5 首席软件工程师

原文链接：为何我们决定从零开始创建 NGINX Gateway Fabric

转载来源：NGINX 中文官网

---

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

在 Kubernetes Ingress controllers 领域，NGINX 取得了巨大成功。NGINX Ingress Controller 被广泛部署用于商业 Kubernetes 生产用例，同时也作为开源版进行开发和维护。因此，您可能会想当然地认为，当 Kubernetes 网络（Gateway API）获得重大改进时，我们会再进一步，将其部署到我们的现有 Ingress 产品中。

然而，我们选择了一条不同的道路。通过评估全新 Gateway API 的强大潜能以及是否有可能彻底重塑 Kubernetes 中的互联处理方式，我们意识到将 Gateway API 实现强塞到现有 Ingress 产品中会限制未来发展。

因此，我们决定推出自己的 Gateway API 项目 — NGINX Gateway Fabric。该项目是开源项目，将以透明、协作的方式运行。我们很高兴与外部贡献者合作，并乐于分享最新成果，共同推动创新，造福于整个社区和行业。

 

我们为何决定推出自己的 Gateway API 项目

尽管我们满怀激情和信心做出了围绕 Gateway API 创建一个全新项目的决定，但这一决定也基于合理的业务和产品战略逻辑。

想必 Kubernetes 采用者已经对 NGINX Ingress Controller 的开源版和商业版有所了解。两者都部署了经过严格测试的 NGINX 数据平面（在 NGINX Plus 和 NGINX 开源版反向代理中运行）。在 Kubernetes 之前，NGINX 的数据平面已在负载均衡和反向代理用例中有不凡表现。在 Kubernetes 中，我们的 Ingress controller 可完成相同类型的关键请求路由和应用交付任务。

NGINX 因轻量级、高性能、久经考验并可满足严苛环境要求的商业产品而享负盛名。我们在 Kubernetes Ingress controller 领域的产品战略与我们的反向代理产品策略相一致，即为简单用例提供强大的开源产品，并为关键业务应用环境中的生产 Ingress 控制提供具有更多特性和功能的商业产品。这一策略在 Ingress controller 领域中行之有效，部分原因是过去 Ingress controller 缺乏标准化，需要大量自定义资源定义（CRD）来提供负载均衡和反向代理高级功能，开发人员和架构师在 Kubernetes 以外的网络产品中享用这些高级功能。

我们的客户依赖并信任 NGINX Ingress Controller，其商业版本已经具备了 Gateway API 旨在提供的许多关键高级功能。此外，NGINX 很早就参与了 Gateway API 项目，并认识到 Gateway API 生态系统要达到完全成熟还需要几年的时间。（事实上，Gateway API 的许多规范都在不断演进，例如 GAMMA 规范，该规范有助于更好地集成 service mesh（服务网格）。）

但我们认为，将测试级 Gateway API 规范强塞到 NGINX Ingress Controller 中会给成熟的企业级 Ingress controller 带来无谓的不确定性和复杂性。我们销售的任何产品都必须具有稳定性和可靠性，并完全符合生产就绪要求。Gateway API 解决方案也会做到这一点，只是目前仍处于起步阶段。

 

我们的 NGINX Gateway Fabric 目标

对于 NGINX Gateway Fabric，我们的主要目标是打造一款经得起时间考验的产品，就像 NGINX Plus 和 NGINX 开源版一样。为了确保我们的 Gateway API 项目能够“满足未来需求”，我们意识到需要为其数据平面和控制平面尝试不同的架构选择。例如，我们可能需要研究不同的方法来管理四层和七层互联或尽量减少外部依赖项。我们最好从零开始，而不沿袭任何历史先例和遵从任何要求。虽然我们正在使用业经试用和测试的 NGINX 数据平面作为 NGINX Gateway Fabric 的基础组件，但对新想法也持开放态度。

我们还希望为 Gateway API 资源提供不受厂商限制的全面配置互操作性。与现有 Kubernetes Ingress 范式相比，Gateway API 最大的改进之一就是规范了服务网络的许多组件。从理论上讲，这种标准化可支持许多 Gateway API 资源轻松地进行交互和连接，助力创造更加美好的未来。

不过，创造这一未来的关键是摒弃厂商特定的 CRD（可能导致厂商锁定）。对于必须支持专为 Ingress controller 领域而设计的 CRD 的混合产品而言，这可能极具挑战性。而在以互操作性为第一要务的开源项目中，做到这一点则相对容易些。为了摒弃紧密关联的 CRD，我们需要构建一个新框架，仅关注 Gateway API 及其组成 API 所暴露的新层面。

 

加入我们的 Gateway API 之旅

目前，我们仍处于早期发展阶段。只有少数项目和产品实施了 Gateway API 规范，其中大多数都选择将其融入现有项目和产品中。

因此，现在是启动新项目的最佳时机。我们的 NGINX Gateway Fabric 项目完全开放，决策和项目管理高度透明。因为该项目使用 Go 编写而成，所以我们诚邀广大 Gopher 社区成员建言献策、提交 PR。

Gateway API 可能会改变整个 Kubernetes 世界。一些产品可能不再需要，新的产品或将出现。Gateway API 蕴藏着无限可能，虽然不知道它终将走向何方，但我们翘首以待。诚邀您加入我们，共创精彩未来！

您可以首先：

• 以贡献者的身份加入项目
• 在实验室中试用实现
• 执行测试并提供反馈

如欲加入该项目，请访问 GitHub 上的 NGINX Gateway Fabric。

---

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号