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 API
Kubernetes 官方早在几年前就已经意识到了 Ingress API 的破局瓶颈，并推出了下一代南北向流量标准：Gateway API。
Gateway API 并不是某一个具体的控制器代码，而是一组面向多租户设计的通用资源规范（CRD）：
- GatewayClass：基础设施管理者定义，声明底层的流量网关控制器类型与资源池。
- Gateway：平台/网络运维定义，声明监听端口、TLS 证书、VIP 与授权范围。
- HTTPRoute / GRPCRoute：业务开发团队定义，仅专注于各自应用的路由规则、权重切流与服务绑定。
通过强类型、结构化的 CRD，Gateway API 彻底废除了“注解拼接配置”的黑魔法，将跨团队自治与安全性做到了极致。
主流替代产品选型指南
既然 Gateway API 是官方指定的继承方向，我们目前在生产环境中有哪些成熟的落地实现可选？
针对社区主流产品，我们梳理出了以下选型矩阵：
具体到实际生产场景，我们可以结合团队的技术栈习惯进行针对性选型：
NGINX Gateway Fabric：传统选型的平滑过渡
- 背景：F5 / NGINX 官方专门为 Gateway API 开发的新一代控制器。
- 优势：继承了 NGINX 极高的稳定性和熟悉的性能特征，同时控制面全面拥抱 Gateway API CRD，彻底废除了传统注解注入的安全风险。
- 适用：希望继续保留 NGINX 数据面特性的团队，这是最平滑的正统迁移路径。
Envoy Gateway：CNCF 主导的标准实现
- 背景：CNCF 社区主导并推荐的 Gateway API 标准实现。
- 优势：基于 Envoy 代理，具备强大的动态 xDS 配置推送、丰富且开箱即用的可观测性、高级限流与安全防护。
- 适用：全面拥抱现代云原生技术栈、追求强可观测性与复杂流量治理的团队。
Cilium Gateway：eBPF 内核级网络加速
- 背景：Cilium CNI 内置的 Gateway API 实现。
- 优势：结合 Linux eBPF 技术，在内核层实现高性能 Socket 转发与网络安全，同时嵌入 Envoy 处理七层复杂路由，实现 CNI 与 Ingress 的统一管理。
- 适用：集群内部已经全面采用 Cilium 作为 CNI 的企业。
Istio Gateway：服务网格南北向统一
- 背景：Istio 社区直接支持将 Gateway API 作为其入口网关的标准声明。
- 优势：使南北向入口流量与东西向服务网格（Mesh）采用一致的控制 API，大幅降低统一治理成本。
- 适用：生产环境已深度部署 Istio Service Mesh 的团队。
Kong Gateway Operator：API 网关扩展能力
- 背景：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 架构的底线保障。
