Kubernetes 退役了流行的 Ingress NGINX 控制器

Kubernetes SIG网络和安全响应委员会宣布Ingress NGINX退役，这是生态系统中最广泛部署的 Ingress 控制器之一。根据在 2025 年北美 Kubecon 上发布的公告，到 2026 年 3 月，将对其继续保持尽力而为的维护，之后将不再有进一步的发布、缺陷修复或安全更新。

这一决定将对许多运行 Kubernetes 集群的组织产生重大影响，因为Ingress NGINX多年来一直是将网络流量导向工作负载的基础组件。由于其灵活性、功能广泛以及与特定云提供商的独立性，该控制器在 Kubernetes 历史的早期就变得非常流行。

公告帖子解释说，该项目因维护者短缺而遭受困扰，最终变得不可持续。Ingress NGINX 只有一两个人在业余时间、下班后和周末进行开发。寻找额外支持以使项目继续可行的努力失败了。

退役揭示了维护成功开源软件所面临的挑战，这些软件为关键基础设施提供了动力，但公告也承认了 Ingress NGINX 维护者的重大贡献，指出该控制器在全球数据中心和家庭实验室中驱动了数十亿次的请求。

Ingress NGINX 的功能范围曾被认为是其主要优势之一，但是，它现在已经演变成项目维护者所描述的不可逾越的技术债务。通过“snippets”注释使用任意 NGINX 配置指令的功能，最初因其灵活性而受到重视，现在则被视为现代云原生软件背景下的严重安全漏洞。

曾经，有人尝试开发替代控制器（名为 InGate），但这没有产生足够的兴趣或支持，也没有超越早期开发阶段。它也将在同时退役。

Kubernetes 社区建议迁移到 Gateway API，这是 Ingress 的现代化替代方案。Gateway API 是为了解决 Ingress 规范的许多限制而创建的，并且具有基于角色的设计，将基础设施提供商、集群运维人员和应用程序开发人员之间的关注点分开。它在 2023 年底达到了普遍可用（GA），支持所有的 Ingress 功能，并且还原生支持许多只有在 Ingress NGINX 中通过注释才能获得的其他功能。除了 HTTP 和 HTTPS，API 还原生支持其他协议，包括 TCP、UDP 和 gRPC，并且还具有其他高级功能，如流量分割和基于头信息的匹配，而不需要特定供应商的注释。

对于那些无法采用 Gateway API 的组织，还有其他人仍在积极维护的替代性 Ingress 控制器，包括 NGINX、Kong、Traefik、HAProxy 等供应商支持的方案。这些控制器在功能集、性能特征和治理模型上有所不同。

云原生倡导者 Jimmy Song 将这一公告描述为“基础设施演变中的一个关键时刻”，并继续说，“一旦基础设施组件无法安全更新，它们就不再是资产，而变成了负债。”他认为，退役表明维护成本已经永久超过了社区贡献的速度，特别是考虑到高灵活性带来的巨大攻击面。Song 的分析强调，核心问题不是使用量的下降，而是不可持续的维护动态。他推测，大多数用户会转向 Gateway API 或其他 Ingress 控制器，这将需要大量的迁移工作。（Jimmy Song 关于该事件的中文博客）

他指出，长期社区观察发现，多数用户将 Ingress NGINX 当作黑盒使用。如今需要从 Ingress 迁移到 Gateway API 或其他 Ingress 控制器，这对大量集群来说是一场“隐性迁移潮”。他还建议，转向统一和可扩展的 API 是新云原生基础设施项目的新兴模式。

它的退役不是失败，而是体系发展到下一个阶段的必然结果。

- Jimmy Song

网络供应商将这一公告定位为对 Gateway API 的验证和商业机会。NGINX 推广自己的 NGINX Gateway Fabric 作为长期继任者，而 Kong、Traefik 等已经发布了迁移指南，强调了他们商业产品的改进治理和更丰富的策略控制。HAProxy 还提供了一个迁移工具，帮助用户从 Ingress NGINX 迁移到他们的产品。

博客帖子解释说，组织可以通过运行命令 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 来检查他们是否在使用 Ingress NGINX，该命令需要集群管理员权限。他们最后强调了尽快规划迁移的重要性，以保持集群的可靠性和安全性。

原文链接：

Kubernetes Community Retires Popular Ingress NGINX Controller