Kubernetes Ingress NGINX 宣布2026年退役：开源维护危机再凸显

在刚刚落幕的KubeCon北美大会上，与会者热议eBPF、AI原生基础设施以及云原生安全等前沿技术。然而，一个低调发布的消息却让整个社区为之震动：

Kubernetes官方宣布，Ingress NGINX将于2026年3月正式停止维护。届时，该项目将不再修复任何漏洞、不再发布新版本，其GitHub仓库也将切换为只读状态。

换言之，这个被广泛部署于各类托管Kubernetes平台、自建集群以及无数生产环境中的Ingress NGINX，距离彻底“退休”仅剩四个月时间。

Ingress NGINX是什么，为何如此重要？

首先简要说明Ingress NGINX的背景。

Ingress是Kubernetes早期推出的“用户友好型”流量接入方式，负责将外部请求路由至集群内部的服务（Gateway API是其更新的替代方案）。要使Ingress规则生效，集群中必须运行一个Ingress控制器。

而Ingress NGINX正是Kubernetes生态中最常用的Ingress控制器之一。它依据用户配置的Ingress规则，将外部HTTP/HTTPS流量精准地转发到后端服务，扮演着反向代理的角色：基于路径、域名、TLS设置等条件进行请求分发、负载均衡以及边界流量管理。

凭借其高度灵活、功能全面且不绑定特定云厂商的特点，Ingress NGINX自诞生起便赢得了大量开发者的青睐。甚至在退役公告中，Kubernetes官方也给予了高度评价：

“Ingress NGINX在全球各地的数据中心和实验环境中处理了数以十亿计的请求。从某种程度上说，没有Ingress NGINX，就不会有今天繁荣的Kubernetes生态。”

然而，这个曾经以灵活和丰富功能著称的明星项目，如今却即将走向终点。

或许你会认为：“软件退役并不罕见。”确实，历史上dBase、Lotus 1-2-3、VisiCalc等都曾风光一时。但关键在于，Ingress NGINX至今仍在全球成千上万个集群中承担着关键流量入口的角色。

维护噩梦：技术债堆积，却“无人问津”

关于Ingress NGINX退役的根本原因，官方给出了直截了当的解释：

“Ingress NGINX的强大功能和灵活性，给后期维护带来了难以承受的负担。”

一个典型的例子是：Ingress NGINX允许用户通过注解直接注入任意的NGINX配置片段。这一设计在过去被视为灵活性的体现，如今却演变为安全漏洞的温床。此类特性从根本上破坏了配置的安全边界，使得NGINX运行时几乎无法被有效管控。在云原生安全标准日益严苛的当下，这已属于“不可接受”的设计缺陷。

而类似的历史遗留问题远不止一个。随着用户规模的扩大，这些技术债务逐渐累积，最终变得难以修复。

当然，如果项目足够复杂但有一个20人的团队专职维护，或许还能维持运转——然而Ingress NGINX仅有1-2名维护者，且他们只能利用业余时间进行维护。

是的，你没有看错：这个承载着十亿级流量、深受用户信赖、无数生产环境赖以运行的组件，多年来仅靠一两位志愿者在业余时间、夜晚和周末抽空修复漏洞，而项目本身的复杂度和安全要求却在持续攀升。

事实上，早在去年，Ingress NGINX的维护者就已公开表示计划逐步放弃该项目，并尝试与Gateway API社区合作开发替代方案InGate。但即便提前预告，也未能吸引更多贡献者加入。InGate甚至未能步入成熟阶段，最终将与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所言：“最简单的答案就是，向维护者付费。”