原文作者：温曙光（花名 风浙）

Ingress NGINX退役，这意味着什么？

2025年11月11日，k8s社区在发布了Ingress NGINX退役的公告。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规范也被冻结。

导火线：高发的安全漏洞 VS 缺乏维护者的窘境

导致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维护者不变的胶片是呼吁更多的开发者加入：

深层分析：简单灵活的理念 VS 持久积累的技术债

一系列的原因导致了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工程师和决策者惊出一身身冷汗：这些极为基础、广泛使用的关键基础设施，只有极为少数的维护者。这暴露出“关键开源项目人力严重不足”的系统性风险。真正的可持续性，不仅需要社区的热情，更需要制度化的资源投入、多元化的贡献者生态和厂商的长期责任共担。这也是未来选择基础设施的必须纳入决策判断的重要因素。

ALB ingress，生产级的平替方案

下一步策略分析

Ingress NGINX的故事到此告一段落，而留给系统工程师的选择却来了：接下来是应该继续坚守Ingress NGINX，还是应该升级到Gateway API上？或者是切换到其它的Ingress上？面对这一关键决策，我们需要结合安全性、演进趋势、运维成本与业务连续性进行审慎评估。让我们对这几个选项进行分析：

• 坚守Ingress NGINX：这意味着作为南北向入口的流量处理关键组件丧失SLA保障。首先应该检查使用的Ingress注解是否属于高风险等级（参考链接），我们强烈建议仅仅在测试环境同时没有使用高风险等级的注解的情况下中采用该策略。（注释）
• 升级到Gateway API：Gateway API是k8s社区定义的未来，这是我们都认可的。选择该方案你需要充分考虑如下几点：

• k8s集群升级：需要升级到1.28+版本，最好是1.30+版本，以获得稳定的 Gateway API CRD 和功能支持。
• 实现选型与维护责任：Kubernetes 官方发行版不包含任何 Gateway API 实现。目前 Envoy Gateway 是 SIG Network 认可的参考实现，但需独立部署和运维，并持续跟踪其版本演进。
• 数据面行为差异需重点验证：Ingress-NGINX 基于 Nginx，而主流 Gateway 实现（如 Envoy Gateway、Higress）基于 Envoy Proxy，两者在 HTTP 处理上存在细微但关键的差异，例如：

• Header 大小写：Nginx 默认透传原始大小写（如 X-Token），Envoy 默认转为小写（x-token）；
• URL Path 处理：Nginx 原样转发路径，Envoy 默认执行规范化（如 /a//b → /a/b）；
• Host Header：Nginx 默认设为 upstream 域名，Envoy 默认透传客户端原始值。

• ⚠️这些差异可能导致后端服务解析异常，迁移前务必通过流量回放或兼容性测试验证。
• 更高的架构复杂度与学习成本：Ingress API 仅需管理单一 Ingress 资源；而 Gateway API 引入角色分离模型，需协同配置 Gateway（平台侧）、HTTPRoute（应用侧）和 ReferenceGrant（授权），显著增加调试链路长度和团队认知负担。对于仅需简单 host/path 路由的场景，这种抽象可能构成过度设计，尤其在中小团队或资源受限环境中。

• 建议：优先在全新业务或具备云原生演进规划的项目中试点 Gateway API，存量系统可保持 Ingress 并行运行，逐步迁移。
• 切换到其它的Ingress：对于大多数处于平稳运行期或希望最小化迁移风险的业务，迁移到其他成熟、活跃维护的 Ingress Controller 往往是最务实的选择。这类方案既能规避 Ingress-NGINX 的安全悬崖，又避免了 Gateway API 的初期复杂性，实现平滑过渡。

在这里，我们推荐部署在阿里云上的ACK/ACS/ASK/自建k8s用户，切换到阿里云原生的ALB ingress，尤其是对于生产级的业务。

ALB：应用层负载均衡的扛把子

ALB，全名是阿里云应用型负载均衡ALB（Application Load Balancer），是阿里云推出的专门面向HTTP、HTTPS和QUIC等应用层负载场景的负载均衡服务，具备超强弹性及大规模七层流量处理能力。ALB具备处理复杂业务路由的能力，与云原生相关服务深度集成。

作为一款在通用领域深耕多年的产品，ALB具有如下非常鲜明的优势，并且已经在大型互联网、视频直播、游戏行业、金融机构等众多行业众多场景得到了长时间的验证：

• 应用型负载均衡ALB具有即开即用，超大性能，稳定可靠，弹性伸缩，按需付费等特点，SLA高达99.995%，更加适合7层应用交付场景。
• 支持HTTP/HTTPS/HTTP2/WSS/QUIC/GRPC等众多协议，单实例高达百万QPS、百Gbps带宽、千万级并发连接，业界性能遥遥领先。
• 云原生产品，无缝对接 VPC、私网连接PrivateLink、网关型负载均衡GWLB、流量镜像、转发路由器等云网络产品，WAF、证书管理、访问控制等云原生安全能力，以及函数计算FC、容器服务ACK/ACS/ASK、SAE、EDAS、ASM等PaaS服务。

ALB Ingress：生产级的平替方案

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的未来展望

ALB Ingress 的未来，将坚定地融入 Kubernetes 流量治理的标准化演进路径——Gateway API。作为阿里云官方打造的云原生入口网关，ALB Ingress 当前以对 Ingress 资源的深度支持和卓越的免运维体验赢得了广泛采用。然而，社区共识已明确：Gateway API 是 Kubernetes 南北向流量管理的未来标准，它通过角色分离、可组合资源模型和跨实现兼容性，解决了传统 Ingress 注解碎片化、能力受限等根本问题。阿里云已积极投入 Gateway API 生态，ALB Ingress 正在加速对 Gateway API 的全面支持，未来将同时兼容 Ingress 与 Gateway 两种模型，并逐步引导用户向后者迁移。这一演进不仅确保现有业务平滑过渡，更使 ALB 能够原生支持 HTTPRoute、TLSRoute、ReferenceGrant 等高级能力，实现精细化流量治理、多租户隔离与统一策略管控。

立即行动：安全高效迁移至 ALB Ingress

为帮助您顺利告别 Ingress NGINX，阿里云提供了完整的迁移路径与实操指南。请参阅官方文档：《自建 Nginx Ingress 迁移 ALB Ingress 最佳实践》。该指南涵盖迁移评估、ALB Ingress 部署配置、注解兼容性对照、基于 DNS 的灰度切换方案及回滚策略，并提供自动化转换工具，确保业务零中断、安全无风险地完成升级。如需专家支持，您可随时通过工单系统、7×24 服务热线或专属客户经理联系我们，我们将全程协助您高效完成迁移。

More...

更多更详尽的分析和实践指导，请扫码预约3月19日14:00-16:00阿里云开发者社区直播平台举办的线上直播活动：「洛神实战营」第一期《Nginx Ingress升级ALB Ingress：分析和实操》