Ingress NGINX 宣布退役：开源基础设施维护的困境与未来

在KubeCon北美大会落幕不久后，业界热议eBPF、AI原生基础设施和云原生安全的未来方向——然而，一个低调发布的消息却令整个社区倍感紧张：

Kubernetes官方宣布Ingress NGINX将于2026年3月正式退役，届时将完全停止维护，即“不再修复漏洞、不再发布新版本，GitHub仓库转为只读”。

换言之：这个广泛部署于各类托管Kubernetes平台和自建集群、被成千上万集群使用的Ingress NGINX，四个月后即将彻底“退出舞台”。

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，就没有今日的Kubernetes生态。”

然而，这个曾以灵活和功能丰富著称的热门项目，如今却面临“弃用”命运。

Ingress NGINX的维护困境：技术债积累与维护者短缺

关于Ingress NGINX退役的原因，官方总结直言不讳：

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

典型例子是：Ingress NGINX允许用户通过注解直接添加任意NGINX配置片段（snippet），这过去被视为灵活性优势，如今却成为安全漏洞。此类特性从根本上破坏了“配置安全边界”，使得NGINX运行时几乎失控。在当前云原生安全标准日益严格的背景下，这已属于“不可容忍”的设计。

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

当然，若项目复杂但有20人团队维护，仍可运转——但Ingress NGINX仅有1-2名维护者，且只能在业余时间处理。

是的，您没看错，这个处理十亿级流量、广受欢迎、无数生产集群依赖的组件，多年来维护者仅1-2位，他们利用晚间和周末抽空修复漏洞，而项目复杂度与安全要求却持续攀升。

实际上，去年Ingress NGINX维护者就曾公开表示计划逐步弃用该项目，并尝试与Gateway API社区合作开发替代方案InGate。但即使发布退役预告，也未能吸引更多贡献者加入。InGate甚至未成熟便也将与Ingress NGINX一同退役。

压倒Ingress NGINX的“最后一根稻草”：致命安全漏洞

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

该漏洞有多严重？Wix的原话是：

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

显然，这种级别的漏洞足以让受影响项目直接进入“高危状态”。

社区用户不满：迁移时间过于紧迫！

消息传出后，在Reddit、Slack、GitHub上，许多用户表达了愤怒与恐慌。

有人抱怨：“如此重要的组件，至少应给予一年迁移期，仅重写所有文档就不止四个月。”

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

“请不要视为理所当然。维护Ingress NGINX的人都是免费工作，依靠责任感支撑。近两年来几乎无人愿意加入维护，关闭项目是必然的。”

这番话再次揭示了开源领域的残酷现实：许多关键开源软件被社区高度依赖，但维护者却无任何报酬。

Ingress NGINX会是个例吗？

平心而论，软件出现重大安全漏洞并不罕见，如Windows几乎每月都有“爆炸级补丁日”。如上文所述，Ingress NGINX退役的根本原因并非漏洞，而是：作为核心基础设施软件，它缺乏可持续的维护资金。

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

此言一针见血。无论是FFmpeg、log4j、OpenSSL、SQLite还是cURL，这些支撑互联网的关键项目都相似：影响力巨大、企业依赖度极高，但仅由少数人默默维护。

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