Kubernetes Ingress NGINX即将退役：开源软件的维护困境

在不久前结束的KubeCon北美大会上，尽管eBPF、AI原生基础设施和云原生安全成为热议话题，但一个低调的消息却令整个社区心头一紧：

Kubernetes宣布Ingress NGINX将于2026年3月正式退役，这意味着它将停止维护，包括不再修复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的维护者就公开表示计划逐步放弃该项目并尝试与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所说：“最简单的答案就是付费给维护者。”