仅1–2人硬抗、致命Bug缠身！Ingress NGINX宣布4个月后“退役”，全球用户慌了：剩下的时间太短了

整理 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

在刚结束不久的 KubeCon 北美大会后，大家都在讨论 eBPF、AI 原生基础设施、云原生安全的未来——不过，真正让整个社区心头一紧的，却是一个被低调放出的消息：

Kubernetes 宣布 Ingress NGINX 将于 2026 年 3 月正式退役，届时，Ingress NGINX 将彻底停止维护，即“不再修复 Bug、不再推出新版本，GitHub 仓库转为只读”。

换句话说：这个被广泛部署在各类托管 Kubernetes 平台和自建集群、还有成千上万个集群在使用的 Ingress NGINX，4个月后就要彻底“退休”了。

Ingress NGINX 是什么，又为什么重大？

先简单介绍一下 Ingress NGINX。

Ingress 是 Kubernetes 最早的一种“用户友善型”流量入口方式，用于将外部网络请求导向集群内的应用（Gateway API 是更新的替代方式）。要让 Ingress 生效，你的集群中就必须运行一个 Ingress Controller。

而 Ingress NGINX 就是 Kubernetes 集群里最常用的 Ingress Controller 之一，负责根据各种可配置的 Ingress 规则，将外部的 HTTP/HTTPS 流量路由到内部服务。它相当于一个反向代理：根据路径、域名、TLS 配置等把请求分发到正确的后端，做负载均衡，并管理边界流量。

因灵活度高、功能丰富、且不依赖特定云平台，Ingress NGINX 自诞生起就迅速受到了许多开发者的喜爱。甚至，Kubernetes 在官宣 Ingress NGINX 退役时也提到：

“Ingress NGINX 在全球的数据中心和 homelab 中承载了数十亿次请求。从某种意义上，没有 Ingress NGINX，就没有今天的 Kubernetes 生态。”

不过，这个曾经以灵活和功能丰富著称的热门项目，却要成为“弃坑软件”。

你可能会觉得：“软件退役有什么稀奇？”的确 ，这也不是第一次了，像 dBase、Lotus 1-2-3、VisiCalc……都曾经风光无限。但问题是，Ingress NGINX 目前仍在被全球成千上万个集群使用。

Ingress NGINX 的维护噩梦：技术债累积，却“没人维护”

关于 Ingress NGINX 退役的缘由，官方总结得很直接：

“Ingress NGINX 的强劲功能与灵活性，给后期维护带来了巨大的负担。”

举个典型的例子：Ingress NGINX 允许用户直接通过注解添加任意 NGINX 配置（snippet），这在过去被认为是灵活性优势，如今却成为了安全黑洞。这类特性从根上破坏了“配置安全边界”，让 NGINX 运行时几乎变得不可控。而在今天云原生安全标准越来越严格的背景下，已经属于“无法容忍级别”的设计。

而这类功能并不止一个，随着用户规模增长，这些历史包袱慢慢累积成了难以修复的技术债。

当然，如果一个项目很复杂，但有一个 20 人的团队维护，那还是可以运转的——但 Ingress NGINX只有 1-2 名维护者，在业余时间才有空维护。

是的，你没看错，这个十亿级流量入口、深受用户欢迎、无数生产集群依赖的组件，多年来维护者仅有 1-2 位，他们得利用业余时间、晚间和周末抽空修Bug，与此同时项目复杂度与安全要求却不断上升。

实则，早在去年 Ingress NGINX 的维护者就曾公开表明计划逐步放弃 Ingress NGINX，并尝试与 Gateway API 社区合作开发一个替代方案 InGate。可即使给出了退役预告，也没能吸引更多贡献者加入维护。InGate 甚至都没能走到成熟阶段，也将与 Ingress NGINX 一同退役。

压死 Ingress NGINX 的“最后一根稻草”：致命性安全 Bug

不过，Ingress NGINX 的维护疲态早已暴露多年，真正让 Kubernetes 最终决定“按下退役按钮”的，是今年 3 月安全公司 Wix 发现的一个严重 Bug。

严重到什么程度呢？Wix 的原话是：

“攻击者可利用该 Bug 执行任意代码，并获取所有命名空间内的所有集群密钥，从而完全接管整个集群。”

显然，这种级别的 Bug 足以让所有中招的项目直接进入“高危状态”。

社区用户愤怒：剩下的时间太短了！

听到这个消息，在 Reddit、Slack、GitHub 上，不少用户都表达了愤怒甚至恐慌。

其中有人抱怨道：“这么重大的组件，至少应该要给我们一年的迁移期，光是重写所有文档就不止 4 个月了。”

对此，Kubernetes 核心维护者 Tim Hockin 的回应也相当直接：

“请不要带有理所当然的态度。维护 Ingress NGINX 的人都是免费做这件事，靠责任感在支撑。这两年来几乎没人愿意加入维护工作，关闭项目是必然的。”

这句话，再次揭开了整个开源领域的残忍真相：许多关键开源软件，社区用户依赖度极高，但维护者却没有任何报酬。

Ingress NGINX 不会是最后一个倒下的？

说实话，软件出现重大安全 Bug 也不是什么稀罕事，像 Windows 几乎每个月都有“爆炸级补丁日”。如上文所说，Ingress NGINX 退役的根因也不是由于Bug，而是：它是一个核心基础设施软件，却没有可持续的维护资金。

Buoyant CEO、Linkerd 作者 William Morgan 在 LinkedIn 上讨论此事时指出：“CNCF 的生态并不真正适合志愿者维护。这个社区对开源的态度更像‘消费’，而不是‘贡献’。”

这句话，一针见血。无论是 FFmpeg、log4j、OpenSSL、SQLite 还是 cURL，这些支撑着互联网的关键项目都很类似：影响力巨大、企业依赖程度极高，但只有少数几个人在默默维护。

如果继续选择“白嫖开源”，不愿意为关键基础设施付费、支持、贡献，那么 Ingress NGINX 必然不会是最后一个倒下的关键组件。而解决这个问题的关键，或许正如 William Morgan 所说：“最简单的答案就是，付费给维护者。”

参考链接：
https://www.theregister.com/2025/12/02/ingress_nginx_opinion/

【活动分享】2025 年是 C++ 正式发布以来的 40 周年，也是全球 C++ 及系统软件技术大会举办 20 周年。这一次，C++ 之父 Bjarne Stroustrup 将再次亲临「2025 全球 C++及系统软件技术大会」现场，与全球顶尖的系统软件工程师、编译器专家、AI 基础设施研究者同台对话。

本次大会共设立现代 C++ 最佳实践、架构与设计演化、软件质量建设、安全与可靠、研发效能、大模型驱动的软件开发、AI 算力与优化、异构计算、高性能与低时延、并发与并行、系统级软件、嵌入式系统十二大主题，共同构建了一个全面而立体的知识体系，确保每一位参会者——无论是语言爱好者、系统架构师、性能优化工程师，还是技术管理者——都能在这里找到自己的坐标，收获深刻的洞见与启发。详情参考官网：https://cpp-summit.org/