2025 年 11 月 11 日，k8s 社区在发布了 Ingress NGINX 退役公告[1]。Ingress API 是外部使用 HTTP/HTTPS 协议访问 k8s 集群中服务的技术规范，而 Ingress NGINX 是该技术规范的实现。所有使用 Ingress 的系统工程师，都应该仔细阅读该公告，并理解它背后的含义：
k8s 继续支持 Ingress API，k8s 项目没有计划移除对 Ingress API 的支持；但同时 Ingress API 未来不会再持续开发，没有新的修改或者更新。这意味着，现在已经部署了 Ingress NGIX，未来继续升级 k8s 集群的版本，依然可以继续保留当前部署的 Ingress NGINX 作为外部 HTTP/HTTPS 流量入口。
现有的 Ingress NGINX 将会继续支持在 k8s 中部署，现有的部署工具如 Helm charts 或者是容器镜像仍继续可用。这意味着，未来部署新的 k8s 集群，依然可以继续部署 Ingress NGINX 作为外部 HTTP/HTTPS 流量入口。
从 2026 年 3 月份开始，Ingress NGINX 的维护工作会完全停止，从此之后，Ingress NGINX 不会有新的版本发布，不会有缺陷修复，也不会再修复任何发现的任何安全漏洞，它的代码库会被设置为只读模式。这意味着，当 Ingress NGINX 再发现如 CVE-2025-1974 这样严重的越权漏洞，也不可能通过等待并更新社区的安全更新修复了，一切只能靠自己。
从 2016 年到 2026 年，Ingress NGINX 走过了十年多的历史，而且是在 k8s 和容器生态蓬勃发展的十年。Ingress NGINX 是 Ingress API 技术规范的一种实现，但是它是最重要的实现，因为它是最早出现的、k8s 社区自带的、被广泛使用的 Ingress API 实现。在一定程度上，Ingress API 跟 Ingress NGINX 是共生一体的关系：在 Ingress API 被提出来后三个月后，Ingress NGINX 作为一个示范性项目得到了官方的背书和认可；而当 Ingress NGINX 项目终结的时候，Ingress API 规范也被冻结。
导致 Ingress NGINX 退役的直接导火线是近年来高发的安全漏洞，表一是从 CVE 数据库查询到的由 Ingress NGINX 自身导致的漏洞，这些漏洞均源于其长期存在的输入验证缺陷（CWE-20）和过度宽松的配置注入机制，使得攻击者可绕过安全边界，直接读取 TLS 私钥、执行任意代码，甚至完全接管集群控制平面。尤其是 2025 年 3 月份被发现的、被安全界称为 IngressNightmare 的一系列漏洞：CVE-2025-1974/CVE-2025-1097/CVE-2025-1098/CVE-2025-24513/CVE-2025-24514，更是引起了社区和用户的广泛关注与安全警觉。
与此形成强烈对照的是，Ingress NGINX 社区只有 2 个半的维护者，并且他们都不是全职维护这这个项目。2024 年春天的 kubecon 欧洲峰会上，他们还在雄心勃勃地计划令人振奋的功能特性：更新的 NGINX 版本、支持 NGINX Javascript、启动新的演进。但是缺乏足够维护者的窘境，让他们把所有精力都放在了修复安全问题上，以及引入 security level 以期全方面加强安全性和稳定性，这导致了前面宣布的支持 NGINX Javascript、新的演进到今天都没有完成。这两年的 kubecon 峰会，从北美到欧洲再到亚洲，Ingress NGINX 维护者不变的胶片是呼吁更多的开发者加入：
一系列的原因导致了 Ingress NGINX 的退役，这里面既有技术的原因，也有社区运作的原因。
首先是它的架构设计，Ingress NGINX 架构设计的最明显特征是“转发管控一体”，也就是它的控制平面（负责配置生成）和转发平面（负责处理HTTP/HTTPS 流量）是跑在同一个 POD 中的。这导致了这个 POD 中必须中持有所有的配置（如 TLS 私钥），同时又能够被各种角色的用户（集群管理员/业务 SRE/开发者）直接访问到。这个设计是所有越权和敏感信息漏洞泄露的基础。这个设计已经被后来出现的各式各样的 Ingress 实现抛弃。
其次是它过于灵活的设计，带来了安全隐患。比如配置片段这个功能，它支持在配置文件中注入任意的 nginx 配置，这个功能在最开始是被认为一个灵活有用的功能，但是后来的发展表明它带来了严重的安全隐患。当灵活性和转发管控一体这两个特点结合在一起，是许多安全隐患的根源。
长久的发展让它背负了沉重的技术债务。维护者在 kubecon2024 北美峰会上曾经列举过一些数字来反映它的复杂性：……43 个依赖项，分布在 4 种架构，3 个 k8s 版本，2 种配置模型下；支持 68 个命令行选项；支持 186 个配置选项；有 100+ E2E 测试集；光编译时间就长达 4 个小时。引用 k8s 资深架构师 Tim Hockin 的一句话：“我非常清楚它有多难，我当时想：我可以帮忙。于是我下载了源代码，开始浏览代码，天哪，这比我想象中的要复杂得多。结果，我也没有时间”。
最后一个问题在它的运作模式，严重分散了这个项目的投入力量。k8s 的 Ingress API 是一个相对简单的规范，缺乏很多如流量治理、更灵活的匹配规则等高级功能。而为了追求灵活与快速迭代，Ingress NGINX 采用了大量自定义的注解（annotations）。直观对比一下，Ingress API 只实现是“从 URL 路径的精确或前缀匹配映射到某个服务”这么一个单一的功能，说明带范例不过 1000 个英文单词，耐心一点 5 分钟就能读完；而 Ingress NGINX 却定义了 118 种注解来增强它的能力。这种不是标准化的运作模式，严重地分散了这个项目的投入力量。如果 Ingress NGINX 的维护者和 k8s 的网络技术委员会一起，致力于提升 Ingress API 的标准化程度，让更多的技术和实现能够在不同的 Ingress 实现之间复用，必将能有更多的力量能够投入到这个项目的运作之中。
Ingress-NGINX 的退役根源在于其早期“简单灵活”的设计哲学与长期演进中积累的结构性缺陷之间的不可调和矛盾：控制面与数据面合一的架构使敏感信息暴露于高风险环境，过度依赖非标准化注解和任意配置注入虽带来短期灵活性，却埋下了严重的安全漏洞隐患，加之技术债沉重、社区协作分散，最终使其难以适应云原生时代对安全性、标准化和可维护性的更高要求。
正如 k8s 委员会委员 Rita Zhang 评价的那样：“我发自内心的说，这个项目对 k8s 的发展历程起到了非常重要的帮助，使它达到了今天的成就”。我们非常感谢这个项目，感谢它所有的贡献者，在长达 10 年的历程中，它凝聚了 1000+ 位开发者的努力，有 8000+ 多次代码的提交，发布了 251 个版本。
Ingress-NGINX 的退役并非失败，而是一次必要的进化：基础设施的“灵活性”必须建立在“标准化”和“安全边界之上，否则敏捷终将沦为脆弱。Kubernetes 社区正通过 Gateway API 完成这一范式转移——Gateway API 是 Ingress API 的升级和未来，它不再鼓励“每个 Controller 自定义一套注解”，而是提供可组合、角色分离、厂商中立的流量治理模型。这不仅是技术升级，更是协作模式的成熟：从“各自为战”走向“共建标准”。Ingress-NGINX 功成身退，其遗产将融入下一代网关的基因；而它的教训，将成为所有云原生项目设计的警示碑。
同时，它再次提醒我们，依靠极少数贡献者的开源模式，不是健康持续的发展路径。过去几年还爆发过非常严重的安全漏洞：OpenSSL 的“心脏出血”（Heartbleed）漏洞，Log4j 的 Log4Shell 漏洞，开源压缩工具 xz 的植入隐蔽后门。这让无数IT工程师和决策者惊出一身身冷汗：这些极为基础、广泛使用的关键基础设施，只有极为少数的维护者。这暴露出“关键开源项目人力严重不足”的系统性风险。真正的可持续性，不仅需要社区的热情，更需要制度化的资源投入、多元化的贡献者生态和厂商的长期责任共担。这也是未来选择基础设施的必须纳入决策判断的重要因素。
Ingress NGINX 的故事到此告一段落，而留给系统工程师的选择却来了：接下来是应该继续坚守 Ingress NGINX，还是应该升级到 Gateway API 上？或者是切换到其它的 Ingress 上？面对这一关键决策，我们需要结合安全性、演进趋势、运维成本与业务连续性进行审慎评估。让我们对这几个选项进行分析：
在这里，我们推荐部署在阿里云上的ACK/ACS/ASK/自建k8s用户，切换到阿里云原生的ALB ingress，尤其是对于生产级的业务。
ALB，全名是阿里云应用型负载均衡 ALB（Application Load Balancer），是阿里云推出的专门面向 HTTP、HTTPS 和 QUIC 等应用层负载场景的负载均衡服务，具备超强弹性及大规模七层流量处理能力。ALB 具备处理复杂业务路由的能力，与云原生相关服务深度集成。
作为一款在通用领域深耕多年的产品，ALB 具有如下非常鲜明的优势，并且已经在大型互联网、视频直播、游戏行业、金融机构等众多行业众多场景得到了长时间的验证：
应用型负载均衡 ALB 具有即开即用，超大性能，稳定可靠，弹性伸缩，按需付费等特点，SLA 高达 99.995%，更加适合 7 层应用交付场景。
支持：
云原生产品，无缝对接 VPC、私网连接 PrivateLink、网关型负载均衡 GWLB、流量镜像、转发路由器等云网络产品，WAF、证书管理、访问控制等云原生安全能力，以及函数计算 FC、容器服务 ACK/ACS/ASK、SAE、EDAS、ASM 等 PaaS 服务。
ALB Ingress 是阿里云官方提供的云原生 Ingress 网关，除了继承 ALB 产品的 SLA 高、稳定性强等诸多优势外，还具有安全性高、免运维、兼容 Ingress NGINX 等特点。
ALB Ingress 采用控制面与转发面分离的架构设计，将配置管理逻辑（控制平面）与流量处理引擎（转发平面）彻底解耦：控制面运行在 Kubernetes 元集群内，负责监听 Ingress 资源并下发策略；而实际的 HTTP/HTTPS 流量则由阿里云托管的高可用、多租户隔离的应用型负载均衡（ALB）实例处理。这种分离机制确保了敏感信息（如 TLS 私钥、认证凭证）无需驻留在用户集群中，从根本上规避了因配置注入、越权访问或容器逃逸导致的敏感数据泄露风险。同时，ALB 作为云原生基础设施，具备自动安全加固、DDoS 防护和 WAF 集成能力，为用户提供企业级、极致安全的南北向流量入口体验。
ALB Ingress 作为阿里云官方托管的云原生网关，真正实现了“零运维”体验。用户无需关心底层负载均衡实例的部署、扩缩容、高可用架构、安全补丁或性能调优——所有这些均由阿里云平台自动完成。这极大降低了 SRE 团队的运维负担，使开发者能聚焦于业务逻辑而非基础设施稳定性，尤其适合缺乏专职网络运维团队的中小型企业或快速迭代的业务场景。
ALB Ingress 兼容 Ingress NGINX 高频使用的注解，显著降低迁移成本。它支持包括金丝雀发布、跨域资源共享等数十种常用注解，使得现有基于 Ingress-NGINX 编写的 YAML 配置几乎无需修改即可平滑迁移至 ALB Ingress，还提供自动化迁移工具支持一键迁移。同时，ALB Ingress 还扩展了云原生能力，如支持 QPS 限流、访问控制、WAF 绑定等高级功能，既保留了用户熟悉的操作范式，又无缝衔接阿里云生态，让用户能在保障业务连续性的同时，逐步享受云原生网关带来的安全与稳定性红利。
ALB Ingress 的未来，将坚定地融入 Kubernetes 流量治理的标准化演进路径——Gateway API。作为阿里云官方打造的云原生入口网关，ALB Ingress 当前以对 Ingress 资源的深度支持和卓越的免运维体验赢得了广泛采用。然而，社区共识已明确：Gateway API 是 Kubernetes 南北向流量管理的未来标准，它通过角色分离、可组合资源模型和跨实现兼容性，解决了传统 Ingress 注解碎片化、能力受限等根本问题。阿里云已积极投入 Gateway API 生态，ALB Ingress 正在加速对 Gateway API 的全面支持，未来将同时兼容 Ingress 与 Gateway 两种模型，并逐步引导用户向后者迁移。这一演进不仅确保现有业务平滑过渡，更使 ALB 能够原生支持 HTTPRoute、TLSRoute、ReferenceGrant 等高级能力，实现精细化流量治理、多租户隔离与统一策略管控。
为帮助您顺利告别 Ingress NGINX，阿里云提供了完整的迁移路径与实操指南。请参阅官方文档：《自建 Nginx Ingress 迁移 ALB Ingress 最佳实践》[3]。该指南涵盖迁移评估、ALB Ingress 部署配置、注解兼容性对照、基于 DNS 的灰度切换方案及回滚策略，并提供自动化转换工具，确保业务零中断、安全无风险地完成升级。如需专家支持，您可随时通过工单系统、7×24 服务热线或专属客户经理联系我们，我们将全程协助您高效完成迁移。
*以上所有观点仅供参考
更多更详尽的分析和实践指导，请扫描下方图片二维码预约 3 月 19 日 14:00-16:00 阿里云开发者社区直播平台举办的线上直播活动：「洛神实战营」第一期《Nginx Ingress 升级 ALB Ingress：分析和实操》
