原文作者：Micheál Kingston - F5 Principal engineer
原文链接： Ingress NGINX 的替代方案：面向长期的开源 NGINX Ingress Controller
转载来源： NGINX 中文社区

 

---

Kubernetes 社区宣布 Ingress NGINX 将于 2026 年 3 月退役。此后，将不再有任何更新、bug修复或安全补丁发布。这个决定是在多年来该项目仅由 1-2 名开发者在夜间和周末维护之后做出的，再加上一些今年早些时候发生的严重安全问题（IngressNightmare CVE-2025-1974），这些情况清楚地表明该项目需要的资源远远超过了现有的支持。

就像您已经知道的那样，虽然您现有的部署将继续工作，但在没有安全更新的情况下运行是有风险的，且未来不会再有功能开发。当然，您已经了解这些情况。

您的选择（以及我们希望您考虑 NGINX OSS 的原因）

目前有多个优秀的 Ingress Controller 可供选择——如Traefik、HAProxy、Kong、基于 Envoy 的选项以及 Gateway API 的实现。Kubernetes 文档列出了其中许多项目，它们各有所长。

有些人可能知道，F5 维护着一个开源许可证的 NGINX Ingress Controller（有趣的是，它最初是 2016 年 NGINX, Inc. 的一个实习项目，在 F5 收购之前）。该项目是开源的，采用 Apache 2.0 许可证，并将一直保持这种状态。现在有一个专门的工程师团队正在开发它，并计划进行一系列升级。如果您已经熟悉 NGINX，并且只想要一个能顺利工作的解决方案，而不需要面对巨大的学习曲线，我们相信 F5 NGINX Ingress Controller for Kubernetes 是您最顺利的选择。

以下是我们认为您会喜欢它的原因：

• 真正的开源：采用 Apache 2.0 许可证，拥有来自不同组织的 150 多名贡献者，而不仅仅是来自 F5。所有开发都在 GitHub 上公开进行，F5 承诺永将永远保持开源。此外，每两周会有社区电话会议
• 最小的学习曲线：使用您已经熟悉的相同 NGINX engine。大多数 Ingress NGINX annotation 都有直接对应的功能，迁移指南为您的现有配置提供了清晰的映射
• 可持续的维护：F5 的全职专属团队确保定期的安全更新、bug 修复和功能开发
• 大规模生产验证：大约 40% 的 Kubernetes Ingress 部署由其提供支持，下载量超过 1000 万次，已在真实的生产环境中经过了实战检验
• Kubernetes 原生设计：Custom Resource Definitions (CRDs)（如 VirtualServer, Policy, TransportServer）提供比 annotation overload 更整洁的配置，并内置校验以防止错误
• 按需提供高级功能：支持金丝雀发布、A/B testing、流量切分、JWT 验证、限流、mTLS 等——这些都可以在开源版本中使用
• 面向未来的架构：当您准备好转向 Gateway API 时，NGINX Gateway Fabric 的积极开发提供了清晰的迁移路径
• 可选的商业支持：开源版本已经足够强大，但如果企业需要主动健康检查、动态重新配置、先进的会话持久化以及商业支持，可以选择 NGINX Plus 集成

迁移至 NGINX Ingress Controller

这是一个大致的迁移指南。您还可以查看我们文档网站上更详细的迁移指南。

第一阶段：盘点现状

• 查看现有资源：记录您当前的 Ingress resource、annotation 和 ConfigMap
• 检查 snippets：识别任何 nginx.ingress.kubernetes.io/configuration-snippet 注解
• 确认正在使用：运行 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
• 并行设置：保持当前配置运行的同时，将 NGINX Ingress Controller 安装到一个单独的namespace

第二阶段：转换配置

• 转换 annotation：您现有的大多数 annotation 在 NGINX Ingress Controller 中都有对应项——我们提供了全面的迁移指南来进行对照
• 考虑使用 VirtualServer 资源：这些自定义资源比充满 annotation 的 Ingress 更简洁，并且提供更多控制，但这取决于您的选择
• 或者继续使用 Ingress：如果您希望改动最小，它用标准的 Kubernetes Ingress 资源也是完全可行的
• 处理边缘情况：对于任何无法直接映射的内容，您可以使用 snippet 或 Policy 资源

第三阶段：全面测试

• 使用测试应用：创建一些指向 NGINX Ingress Controller 的测试 Ingress 规则
• 并行运行：保持两个控制器同时运行，并通过新控制器路由测试流量
• 验证功能：检查路由、SSL、限流、CORS、身份验证等您正在使用的功能
• 检查性能：验证它是否按照您的需求处理流量

第四阶段：逐步切换

• 从小处开始：首先迁移那些不太关键的应用
• 缓慢切换流量：逐步更新 DNS 和路由
• 密切监控：在切换过程中密切关注日志和指标
• 保留应急通道：确保如果出现问题可以随时回滚

第五阶段：完成迁移

• 完成迁移：迁移剩余的工作负载
• 清理旧控制器：迁移完成后卸载社区版的 Ingress NGINX
• 整理：删除不再需要的旧 ConfigMap 和资源

为什么选择 NGINX Ingress Controller（总结）

它是真正的开源

• 完全开源，采用 Apache 2.0 协议，您不会被锁定在某个专有系统中
• 来自多个组织的 150 多名贡献者（不仅限于 F5 员工）
• 所有开发工作均在 GitHub 上公开进行
• F5 承诺将始终保持开源，这是我们业务模式的核心
• 拥有来自 F5 的可持续支持和投资

它是熟悉的领域

• 使用您早已熟悉的相同 NGINX 引擎
• 如果您一直在使用 Ingress NGINX，那么您已经掌握了 Ingress Controller 的大部分功能
• 迁移文档展示了现有配置中大部分内容的直接映射关系
• 您无需学习全新的东西

它在积极维护中

• F5 NGINX 配备了专属的全职工程师
• 提供定期的更新和安全补丁
• 约 40% 的 Kubernetes 部署使用它，因此经过充分的测试
• 如果您有需求，也可以获得商业支持（尽管开源版本已经非常稳定）

立足当下，通向未来

• 我们准备了详尽的迁移指南，以确保您顺利过渡
• 如果您需要迁移到商业版，我们可以协助将 annotation 和其他自定义配置迁移到 NGINX
• NGINX 团队还提供了 Gateway API 实现方案——NGINX Gateway Fabric，当您准备迁移到 Gateway API 时可供使用

其他选项如何？ Gateway API 是未来，但它仍在成熟发展过程中。Traefik、HAProxy、Kong 都是不错的选择，但如果您已经在使用 NGINX 并且想要最顺畅的迁移路径，我们相信 NGINX Ingress Controller 将是最佳选择。（当然，我们确实带有立场）

立即开始

准备好开始迁移了吗？您需要以下资源：

📚 阅读完整文档：https://docs.nginx.com/nginx-ingress-controller/

💻 克隆仓库：https://github.com/nginx/kubernetes-ingress

🐳 拉取镜像：https://hub.docker.com/r/nginx/nginx-ingress/

🔄 遵循迁移指南：https://docs.nginx.com/nginx-ingress-controller/install/migrate-ingress-nginx/

NGINX Ingress Controller 社区响应迅速且充满热情，您有足够的时间来规划这次迁移，但请不要等到 2026 年 3 月才动手。