Kubernetes 社区网络工作组SIG Network已发布官方公告长期作为云原生网关“事实标准”的ingress-nginx项目将于 2026 年 3 月正式退役并停止全部安全更新与日常维护。对于绝大多数 Kubernetes 运维与架构师而言第一反应往往是困惑“集群里跑得好好的ingressClassName: nginx难道不能用了生产环境全要重构吗”答案是既不需要恐慌也不能坐视不管。关键是要搞清楚退役的真实对象、背后深刻的架构原因以及社区官方指定的正统继承方向。澄清误区退役的到底是什么很多团队容易把市场上几种不同的 NGINX 控制器混为一谈。我们必须首先划清界限退役的项目Kubernetes 社区 SIG Network 维护的开源ingress-nginx控制器即 GitHub 仓库kubernetes/ingress-nginx。这个项目是社区为了早期让 K8s 具备南北向 HTTP 路由能力而建立的。不受影响的项目F5 / NGINX 官方商业与开源团队维护的独立控制器如 NGINX Ingress Controller、商业版 NGINX Plus以及其他第三方扩展。换句话说退役的是 Kubernetes 社区维护的那套“基于注解拼接 NGINX 配置”的旧 Controller而不是 NGINX 这款高性能数据面本身。致命硬伤社区为何不得不放弃 ingress-nginx为什么跑了数年、接入数百万集群的ingress-nginx会走到退役这一步原因不在于 NGINX 转发性能不够而在于经典的 Ingress API 与社区实现架构存在先天性缺陷。架构死结注解Annotation拼接黑魔法经典的 KubernetesIngressAPI 定义非常简陋仅仅支持路径映射和 TLS 绑定。一旦遇到黑白名单、Header 重写、跨域 CORS、Lua 动态脚本等复杂需求就只能依赖各种自定义注解。在ingress-nginx的实现里这些注解例如nginx.ingress.kubernetes.io/configuration-snippet在后台会被 controller 提取并强行拼接到全局nginx.conf文本模板中。这种设计带来了两大致命问题CVE 漏洞频发过去几年中CVE-2021-25742、CVE-2023-5043 等高危漏洞屡屡曝出。攻击者只需在一个看似普通的 Ingress 资源中注入恶意 Lua 或配置片段就能直接越权控制整个 Ingress 控制器甚至窃取集群 Secret。多租户职责不清集群管理员、网络运维与业务开发团队共用同一个Ingress资源。开发人员随便修改一个注解就可能导致整个集群的nginx.conf语法报错并引发全站瘫痪。正如上图所示旧模式下所有控制逻辑、黑魔法注解与数据面高度耦合在一个单体模板中而新一代架构通过标准 API 实现了控制平面与职责角色的彻底解耦。官方继承者Kubernetes Gateway APIKubernetes 官方早在几年前就已经意识到了 Ingress API 的破局瓶颈并推出了下一代南北向流量标准Gateway API。Gateway API 并不是某一个具体的控制器代码而是一组面向多租户设计的通用资源规范CRDGatewayClass基础设施管理者定义声明底层的流量网关控制器类型与资源池。Gateway平台/网络运维定义声明监听端口、TLS 证书、VIP 与授权范围。HTTPRoute / GRPCRoute业务开发团队定义仅专注于各自应用的路由规则、权重切流与服务绑定。通过强类型、结构化的 CRDGateway API 彻底废除了“注解拼接配置”的黑魔法将跨团队自治与安全性做到了极致。主流替代产品选型指南既然 Gateway API 是官方指定的继承方向我们目前在生产环境中有哪些成熟的落地实现可选针对社区主流产品我们梳理出了以下选型矩阵具体到实际生产场景我们可以结合团队的技术栈习惯进行针对性选型NGINX Gateway Fabric传统选型的平滑过渡背景F5 / NGINX 官方专门为 Gateway API 开发的新一代控制器。优势继承了 NGINX 极高的稳定性和熟悉的性能特征同时控制面全面拥抱 Gateway API CRD彻底废除了传统注解注入的安全风险。适用希望继续保留 NGINX 数据面特性的团队这是最平滑的正统迁移路径。Envoy GatewayCNCF 主导的标准实现背景CNCF 社区主导并推荐的 Gateway API 标准实现。优势基于 Envoy 代理具备强大的动态 xDS 配置推送、丰富且开箱即用的可观测性、高级限流与安全防护。适用全面拥抱现代云原生技术栈、追求强可观测性与复杂流量治理的团队。Cilium GatewayeBPF 内核级网络加速背景Cilium CNI 内置的 Gateway API 实现。优势结合 Linux eBPF 技术在内核层实现高性能 Socket 转发与网络安全同时嵌入 Envoy 处理七层复杂路由实现 CNI 与 Ingress 的统一管理。适用集群内部已经全面采用 Cilium 作为 CNI 的企业。Istio Gateway服务网格南北向统一背景Istio 社区直接支持将 Gateway API 作为其入口网关的标准声明。优势使南北向入口流量与东西向服务网格Mesh采用一致的控制 API大幅降低统一治理成本。适用生产环境已深度部署 Istio Service Mesh 的团队。Kong Gateway OperatorAPI 网关扩展能力背景Kong 官方打造的 Gateway API 控制器。优势完全兼容 Gateway API 标准同时能直接无缝接入 Kong 丰富的插件生态认证鉴权、计费、速率限制等。适用除了基础南北向分流外还需要大量 API 网关高级能力的企业。迁移落地建议离 2026 年 3 月的最后期限尚有时间但流量入口的迁移涉及生产环境的稳定性建议按以下步骤节奏推进盘点依赖清理当前集群所有 Ingress 资源重点评估使用了哪些nginx.ingress.kubernetes.io特殊注解找出无法直接映射到标准 HTTPRoute 的黑魔法配置。技术选型如果追求简单稳定性与传统 NGINX 语义优先验证NGINX Gateway Fabric如果是全新集群或准备拥抱云原生全家桶推荐评估Envoy Gateway或Cilium Gateway。双网关并行灰度在集群中按 Gateway API 规范部署新控制器通过 DNS / ELB 权重分流进行南北向流量的无缝切换与生产验证。逐步完成现存注解的梳理与规范化抽象是避开 2026 年 3 月维护截止期、平滑过渡至 Gateway API 架构的底线保障。