Ingress NGINX 退役：你需要了解的内容
为了优先考虑生态系统的安全，Kubernetes SIG Network 和安全响应委员会宣布 Ingress NGINX 即将退役， 并将尽力将其维护期持续到 2026 年 3 月。 之后，将不再有进一步的版本发布、错误修复和更新来解决可能发现的任何安全漏洞。 现有的 Ingress NGINX Deployment 将继续运行，并且安装工件仍将可用。
我们建议迁移到替代方案之一。考虑迁移到 Gateway API， 这是 Ingress 的现代替代品。如果你必须继续使用 Ingress，许多替代的 Ingress 控制器已在 Kubernetes 文档中列出。 下文介绍有关 Ingress NGINX 的历史和当前状态以及后续步骤的更多信息。
关于 Ingress NGINX
Ingress 是将网络流量导向运行在 Kubernetes 上的工作负载的原生的、用户友好的方式。 （Gateway API 是实现许多相同目标的新方法。） 为了使 Ingress 在集群中工作，你必须运行一个 Ingress 控制器。 有多种 Ingress 控制器可供选择，可以满足不同用户和使用场景的需求。 有些是特定于云提供商的，而其他的则具有更广泛的应用性。
Ingress NGINX 是一个 Ingress 控制器，作为 API 的示例实现，在 Kubernetes 项目早期开发。 由于其极大的灵活性、丰富的特性以及不依赖于任何特定的云或基础设施提供商，它变得非常流行。 自那时以来，许多其他的 Ingress 控制器已经在 Kubernetes 项目中由社区小组和云原生供应商创建。 Ingress NGINX 一直是其中最受欢迎的选择之一，被部署在许多托管的 Kubernetes 平台上以及无数独立用户的集群中。
历史与挑战
Ingress NGINX 的广度和灵活性导致了维护上的挑战，对于云原生软件不断变化的期望也增加了复杂性。 其中曾经被认为是有帮助的选项，有时却被视为严重的安全缺陷，例如通过“片段”注解添加任意 NGINX 配置指令的能力。 昨天的灵活性已成为今天的难以克服的技术债务。
尽管该项目在用户中非常受欢迎，但 Ingress NGINX 一直存在一个问题，就是维护者很少、勉强应付。 多年来，项目仅有的一到两个人在其业余时间、下班后和周末进行开发工作。去年，Ingress NGINX 维护者宣布 他们的计划是逐步停止 Ingress NGINX，并与 Gateway API 社区一起开发替代控制器。 不幸的是，即使是这样的公告也未能激起更多兴趣来帮助维护 Ingress NGINX 或开发 InGate 以取代它。 （InGate 的开发从未进展到足以创建一个成熟的替代品；它也将被退役。）
当前状态与下一步
目前，Ingress NGINX 的维护模式是尽力而为的。 SIG Network 和安全响应委员会已经用尽全力寻找额外的支持来使 Ingress NGINX 可持续发展。 为了优先考虑用户的安全，我们必须停止该项目。
2026 年 3 月，Ingress NGINX 的维护将被停止，项目将被退役。 之后，将不再有进一步的版本发布、错误修复或更新来解决可能发现的任何安全漏洞。 GitHub 仓库将变为只读，并留作参考。
现有的 Ingress NGINX 部署不会受到影响。现有的项目制品，如 Helm 图表和容器镜像，仍将保持可用。
在大多数情况下，你可以通过运行 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
来检查是否使用了 Ingress NGINX，这需要集群管理员权限。
我们想感谢 Ingress NGINX 的维护者们在创建和维护此项目中所做的工作——他们的奉献精神令人印象深刻。 这个 Ingress 控制器在全球的数据中心和家庭实验室中处理了数十亿次请求。 在很多方面，如果没有 Ingress NGINX，Kubernetes 不会取得如今的成就，我们对如此多年的杰出努力表示感激。
**SIG Network 和安全响应委员会建议所有 Ingress NGINX 用户立即开始迁移到 Gateway API 或其他 Ingress 控制器。 ** Kubernetes 文档中列出了许多选项：Gateway API、 Ingress。 与你合作的供应商可能还提供其他选项。