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

CSDN·2025年12月05日 11:18

“最简单的答案就是，付费给维护者。”

在刚结束不久的 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 一同退役。