ingress-nginx：Kubernetes 流量入口的经典方案，即将谢幕

ingress-nginx 在 GitHub 上拿到了 19,494 Star。

这是 Kubernetes 生态里使用最广泛的 Ingress 控制器之一，基于 NGINX 做反向代理和负载均衡，负责把集群外部的 HTTP/HTTPS 流量转发到内部 Service。过去几年，几乎所有搭建 K8s 集群的团队都绕不开它。

但有一个关键信息需要知道：这个项目正在退役。

退役时间表

根据官方公告，ingress-nginx 的维护计划如下：

2026 年 3 月之前，社区会以尽力而为的方式继续维护，可能会出一些版本更新。3 月之后，不再有新版本发布，不再修复 Bug，不再处理安全漏洞。

已有的部署不会因此崩溃。Helm Chart 和容器镜像会继续保留在原来的位置，存量集群可以正常运行。但如果你还没有开始用 ingress-nginx，官方建议不要再部署了，直接去找一个 Gateway API 的实现方案。

它到底做了什么

简单说：ingress-nginx 是 Kubernetes Ingress 资源的具体执行者。

Kubernetes 的 Ingress 是一种声明式的 API 对象，你告诉集群"这个域名的流量应该转到哪个 Service"，但集群本身不处理流量，需要一个控制器来读取这些 Ingress 规则并实际配置代理。

ingress-nginx 就是干这个的。它监听 Kubernetes API，拿到 Ingress 对象的定义，然后动态生成 NGINX 配置文件，热加载生效。支持路径匹配、TLS 终止、自定义 Header、限流、灰度发布等常见场景。

为什么要退役

Ingress API 本身有局限性。它把路由规则、负载均衡策略、安全配置全塞进一个对象里，扩展只能靠 Annotation，不同控制器的 Annotation 互不兼容，迁移成本高。

Gateway API 是 Kubernetes 社区推出的新一代流量管理标准。它把职责拆得更细：GatewayClass 管基础设施、Gateway 管监听端口、HTTPRoute 管路由规则，层次清晰，可组合性强，而且是跨实现的统一接口。

从 Ingress 到 Gateway API，不是小修小补，是架构层面的升级。ingress-nginx 选择退役，本质上是让社区把精力集中到新标准上。

当前支持的版本

截至目前，ingress-nginx 最新版本是 v1.15.1，支持 Kubernetes 1.31 到 1.35，底层用 NGINX 1.27.1。Helm Chart 版本对应 4.15.1。

如果你还在用 v1.12 及更早的版本，注意这些版本已经不再维护，建议尽快升级。

什么场景下还在用它

尽管在退役，ingress-nginx 在存量集群里依然大量运行。几个典型场景：

已经上线的生产环境，Ingress 规则和 Annotation 绑定很深，短期内迁移成本高。内部工具集群，流量不大，不需要 Gateway API 的高级特性，够用就行。学习和测试环境，用 ingress-nginx 入门 Kubernetes 网络，教程和文档都比较全。

迁移建议

如果你正在规划新集群，直接选 Gateway API 实现，比如 Envoy Gateway、Cilium、Istio 等。不要在新项目里引入 ingress-nginx。

如果你有存量集群在用 ingress-nginx，2026 年 3 月之前不需要急着动。但应该开始评估迁移方案，重点看两个方面：一是现有 Ingress 规则的复杂度，Annotation 用得越多迁移越麻烦；二是团队对 Gateway API 的熟悉程度，可以先在非核心环境跑通流程。

技术细节补充

ingress-nginx 支持的 Kubernetes 版本跨度比较大，从 1.29 到 1.35 都在支持范围内。底层 Alpine 系统版本是 3.23.3。项目采用 Apache License 2.0 开源协议。

遇到问题可以查 troubleshooting 文档，也可以在 Kubernetes Slack 的 #ingress-nginx-users 频道提问。

oting 文档，也可以在 Kubernetes Slack 的 #ingress-nginx-users 频道提问。