Ingress-NGINX 项目停止，是要简单平移，还是策略性重构？
原文作者：林静，黄晓芬
原文链接：Ingress-NGINX 项目停止，是要简单平移，还是策略性重构？
转载来源：NGINX 中文社区
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
Ingress-NGINX 社区项目在 2026 年 3 月后，将不再发布新版本，不再修复漏洞，也不会针对可能发现的任何安全漏洞提供更新。作为一个在大量用户默认使用的方案，突然停止研发，并且留给用户并不多的迁移时间，确实在业界引起了巨大的震动。
在本文中，我们将从事件背景、开源思考、市场分析、迁移策略与建议这几个方面与您一同探讨，是选择简单的迁移平移，还是进行策略性重构？
事件背景
“听说 F5 要停止 Ingress-NGINX 项目的研发了？”一位朋友从微信上发来消息。我告诉他“搞混了，Ingress-NGINX 不是 F5 NGINX 的项目，而是 Kubernetes 社区的项目。F5 的项目叫 NGINX Ingress Controller。你可以理解为社区强调 Ingress 并用 NGINX 做了一个入口的参考项目，所以叫 Ingress-NGINX，而 F5 强调的是基于自己的 NGINX 来实现的 Ingress，所以可以叫 NGINX-Ingress。”
Ingress 规范自 2015 年以 beta 方式引入 Kubernetes 时，Ingress-NGINX 项目就一直以 Ingress 的样例项目的姿态出现，在早期的 Kubernetes 相关官方文档中一直有这样的表述。在本次关于 Ingress-NGINX 项目退役的官方宣布文档中，依然有这样的描述：
“Ingress NGINX was an Ingress controller, developed early in the history of the Kubernetes project as an example implementation of the API. ”
Ingress 规范本身从 2015 到 2020 年 8 月，随着 Kubernetes v1.19 的发布才被正式 GA，跨越了约 5 年时间。而实际上，就在 Ingress 规范 GA 之前，2018 年 2 月社区针对 Ingress 发起过大规模的社区调查，随后在 2019 年 11 月圣地亚哥的 KubeCon 上，一个新的 API：Service API 被提出，这个 Service API 就是 Gateway API 的前身，2023 年 10 月 Ingress API 最终被社区正式冻结，推荐用户转向 Gateway API 规范。
2024 年香港 KubeCon 上，Ingress-NGINX 的 maintainer 张晋涛提到该项目在漏洞修复方面人手完全不够，近年来 Ingress-NGINX 爆出了多个重大漏洞如 CVE-2025-24514、CVE-2025-1974、CVE-2025-1097、CVE-2025-1098 等，其中 CVE-2025-1974 的 CVSS 评分达 9.8，该漏洞可以导致黑客直接接管整个 k8s 集群。很多时候会被安全响应委员会追着屁股赶活，漏洞修复速度很慢。退役官方文档中提到“多年来，该项目只有一两个人利用自己的业余时间、下班后和周末进行开发工作。”
可以看出，即便 Ingress 规范本身在社区也是命运多舛，而作为一个样例性项目的 Ingress-NGINX 被终止也自然并不出乎意外。
开源思考
并不意外，并不代表我们不去思考。Ingress-NGINX 项目作为 Kubernetes 默认的 Ingress Controller，是许多用户的默认选项，也是大量 PaaS 厂商默认打包的组件，如此重要的项目，多年来完全依赖于少量的人维护，是典型的“大量使用，少有贡献”的开源项目。在开源项目使用中，有一个根本性的风险就是：项目再重要，也没有人义务为你服务。在此次事件发生后，有人在微信群中抱怨到：“似乎事件一出，好像很多人又成了专家，重新关注了 Ingress，可是你真的愿意为这个项目做出贡献吗？”与一些开源项目一样，它被大量的关键组织、企业应用，却很少得到真正的社区贡献，即便是炙手可热的 CNCF 基金会，也一样面临这样的难题。开源的 star 不等于可持续性，开源的使用规模不等于开源的健康度，开源的免费不等于开源可以替代企业级产品。Ingress-NGINX 项目的停止，是云原生领域给我们敲响的警钟。对于生产级基础设施，我们必须重新思考项目的：
- 可持续性
- 维护者结构
- 技术路线
- 商业支持
- SLA 与合规性要求
开源不是产品形态，而是一种合作形态。在关键基础设施上，企业必须为“可持续性”和“可靠性”付费、投入或承担责任。
市场分析
上面我们提到缺乏人手是导致 Ingress-NGINX 项目停止的一个直接原因，而从另一方面，市场产品的多样性以及技术发展的走势也是一个重要因素。查看 Ingress Controller Additional Controllers 页面，我们可以看到高达 30 个 Ingress Controller 产品可供用户选择，产品提供的多样性也反向意味着上游作为参考定位的项目，其发展的情绪与意愿会降低。
这些 Ingress Controllers，从驱动类型角度看，可以分为：
- API 场景驱动型：Ambassador(已被 Gravitee 收购)，Tyk，Gloo 典型的是此类
- 企业驱动型：F5 Container Ingress Services(CIS)，F5 NGINX Ingress Controller 等是典型此类
- 副产品驱动型：Istio Ingress，Cilium Ingress Controller 等属于此
从产品技术分类看，可以分为：
- NGINX Based：例如 Azure Gateway Ingress，F5 NGINX Ingress Controller 等
- Envoy Based:例如 Contour, Emissary-Ingress, Kusk Gateway, Enroute，Gloo 等
- HAproxy Based：HAproxy Ingress Controller, Voyager
- 专用高性能硬件或软件数据面 Based：F5 BIG-IP Container Ingress Services
作为 Kubernetes 的关键入口位置，Ingress Controller 承担了两个方面的具体落地，一个是流量，一个是安全。从这些诸多的产品可以看出，不同的社区、厂商都希望在此位置抓住用户流量，有的从自己擅长的 API 领域入手，有的则是利用自身在东西向流量或 K8s 网络的优势来切入到南北向流量的管理，而像 F5 则完全是利用自身在流量管理与 API 安全方面的领先优势来进入到该领域。这里有一个很重要的思考，Kubernetes 的流量是不是只属于 k8s 平台管理员考虑的范畴，是仅考虑 k8s 所定义的这些云原生的网络流量规范，还是应该更加务实的注重企业在实际落地服务发布时的一些需求，如多端口，多 IP，更好的长连接管理等？我们是否应该站在全局基础设施流量的高度来看待 Ingress Controller 的选型？
迁移策略与建议
既然入口控制器产品如此之多，在考虑进行方案迁移之时，您需要首先从以下三个维度来判别自己要选择哪种策略：
- 继续保持 Ingress 规范
- 考虑转向新的 Gateway API 规范
- 考虑新的架构来建立更可靠与持久的入口解决方案
让我们分别分析这些策略。
01 考虑继续保持 Ingress 规范
继续保持 Ingress 规范是技术迁移上难度最小的一种模式，几乎所有的入口控制器产品都会支持 Ingress 规范。尽管是同规范平移，但是依然存在以下风险与难点：
方案自身特点导致的配置不对等：由于 Ingress 本身仅定义了少量的规范标准，导致了大量方案实现中都会存在方案本身独特的特点，如不同的启动参数，不同的全局配置项，不同的 annotations，不同的自定义 CRD，不同的片段插入，不同的插件。甚至在某些特定情况下你可能完全找不到能够对等的配置方法，此时就必须为此做出取舍或找到变通的方法。
不同的数据面，产生不同的行为：NGINX，HAproxy，Envoy 等均为不同的数据面，即便相同的功能下，可能依然会有不同的行为特点，这是较为隐藏的风险，在实际迁移中要仔细测试，以验证不同数据面产品是否对应用产生了不同的行为影响。因此从这个角度来说，依然选择 NGINX 作为数据面是较为理智的行为，此时无需考虑不同数据面产品带来的风险，且学习成本更低。
开源产品可持续性：我们不应该在同一个地方犯两次错误，建议优先考虑企业驱动型 Ingress Controller 解决方案，由于这类解决方案的背后是商业公司在支持，因此选择该类解决方案可以在产品的延续性、漏洞修复、新功能等方面得到足够的保障。F5 的 Ingress Controller 将是最佳选择，您一方面可以首先选用该解决方案的开源免费版本，在迁移成功后，再根据自己的实际需要，选择是否购买企业服务支持以获得服务以及更多商业版本功能特性，另一方面，如果您原本的配置非常复杂且工作量巨大，您还可以直接选择购买 F5 NGINX 的咨询服务以获得厂商级迁移支持。
未来技术规范的支持：尽管我们是选择 Ingress 规范的技术平移，但是我们依然也要着眼未来，即需考虑对 Gateway API 规范的支持，那么此时您就需要叠加考虑相同数据面且又能够同时支持 Gateway API 的产品或方案。F5 NGINX 的解决方案可以同时满足这些条件。
安全 WAF 能力：如果您已在 Ingress-NGINX 中使用了第三方的 ModSecurity WAF，那么您就需要注意选择的目标方案是否依然能够提供类似的 WAF 能力，这在大部分的开源 Ingress Controller 方案中都不提供，而F5 NGINX Ingress Controller 是支持部署 F5 WAF for NGINX 的。
此外，您还需要考虑在实际迁移过程中，必然是采用过渡式迁移，尽管我们可以使用 IngressClass 等技术来同时部署多种 Ingress Controller，但这些不同的控制器必须配置的是不重叠的 IP 或/和端口，这意味着在此期间应用的访问将面临不同的端口或者IP，因此用户还需考虑 DNS、应用修改配合、网络架构修改等工作，例如在 Ingress Controller 之前部署 F5 等负载均衡器（软件或硬件），来统一收口 IP 来避免 DNS 的大规模调整，并利用 F5 来将请求分发到不同的 Ingress Controller 上。如果您选择的是 F5 NGINX 解决方案，这些架构级的工作将由 F5 一并帮您解决，充分降低了迁移的实际难度。
如果您想了解迁移到 F5 NGINX Ingress Controller 中的一些关键配置与参数项映射，您可以参考本篇迁移手册。一般来说，用户的大部分配置会与以下几个功能方面有关：
- 自定义 annotations
- 速率限制，或全局速率限制
- SSL 终结-四层服务转发
- Headers 与 URL 操纵
- 安全策略或 WAF 策略
需要提醒的是，Ingress 规范已被 Kubernetes 冻结，意味着不会再有新的功能。但 F5 NGINX Ingress Controller 提供了自己的 CRD，该 CRD 下提供了大量的符合企业所需的特性功能，并保持持续发展。
02 考虑转向 Gateway API 规范
恭喜您，选择了一条新的道路，选择 Gateway API 规范意味着您的入口解决方案将与社区保持一致，并获得持续的新能力，但同时也意味着迁移的难度与工作量更大。由于这两个规范完全不同，您需要自己逐项完成从 Ingress 规范到 Gateway API 规范的配置迁移，所以您不仅要保持功能迁移的一致性，还需要理解 Gateway API 的新设计思想。Gateway API 最大的设计思想是角色分离，它解决了 Ingress 中管理角色对象不清问题，清晰的定义了 Infrastructure provider, Cluster provider 以及 Application developer 这三个角色，使得在底层数据面、中层控制面、上层应用维护面解耦，适应了企业的实际需求。对于角色分离这一点，其实即便您使用 Ingress 规范的 F5 NGINX Ingress Controller 您一样也可以通过 VS 与 VSR, Policy 这些 CRD 来获得类似的体验。整体上 Gateway API 解决了以下技术或团队协作问题：
解决 Ingress 能力不足问题(核心，扩展，自定义)
- 避免实现方案过度依赖 Annotation/启动参数
- 扩展支持更多协议（不仅仅是 http）
- 解决过于简单的资源对象表示能力（例如 Ingress 仅有 Host，path 这些）
- 解决 Ingress 默认不可以跨 NS 问题
- 解决 Ingress 可移植性差的问题
- 由于原生 Ingress 功能单一，导致不同厂家产品采用大量不可互通的自定义扩展
解决 Ingress 角色对象不清问题
基于 API 契约，减轻了应用 owner 与基础实施 owner 的沟通成本
让云原生架构与基础架构有效融合,有利于企业 SRE
- 从仅开发者视角转向关注企业 IT 架构整体
使用 Gateway API 的另一个优势是在生成式 AI 时代下的模型推理服务，利用 Gateway API的Inference extension 来实现模型路由、优先级访问控制、基于负载真实压力感知的负载均衡等能力。F5 Gateway Fabric 项目已经实现该 Inference extension，可为推理服务提供更好的入口路由方案。
F5 在统一 NGINX One的SKU 下，为用户提供了多种产品方案组合，用户可以在 Ingress 技术方向与 Gateway API 技术方向灵活切换，我们提供了从 Ingress 规范转向 Gateway API 规范的转换工具 ingress2gateway 帮助您更加简便的迁移到 Gateway API 规范。如果您想查阅 F5 NGINX 对Gateway API 规范的支持情况，可以参考此文档链接：https://docs.nginx.com/nginx-gateway-fabric/overview/gateway-api-compatibility/。
至此我们可以稍作总结下，您可以选择以下既安全又兼顾未来技术走向的迁移路径：
03 考虑新的架构来建立更可靠与持久的入口解决方案
上述迁移方案中，我们主要讨论的依然是从 PaaS 或者 Kubernetes 自身的角度来解决服务发布问题，我们一直利用的都是 Kubernetes 自身网络流量规范。这些都是纯纯的云原生思想的设计。而在实际企业生产中，很难做到如此纯净的完全面向云原生的应用设计，很多时候我们的应用是未经云原生化改造，而直接迁移到容器中的，这些应用会需要类似长连接友好、会话保持友好、SNAT 地址友好、TCP 协议微调友好、四层协议友好、同 IP 多端口服务发布、多 IP 同端口服务发布、与 DNS 发布联动等实际需求。同时，从团队的角度也需要将 PaaS 的服务流量入口与基础架构网络进行友好的对接，这就需要一个能够融合和连接两者的解决方案。
F5 Container Ingress Services（CIS）解决方案即是站在全局基础设施流量角度来考虑的一个解决方案，它兼容 Ingress 方案，同时更加强调能够解决上述提到的特殊企业级服务发布需求。这是一个企业级的商业解决方案，拥有自己的 CRD，也拥有更加符合网络人员视角的发布定义，这确保了用户并不会因上游的协议规范变化而受到影响。同时 F5 的硬件产品为大规模服务发布提供了强力的性能支撑。整体来说，F5 CIS 方案拥有以下特点：
- 更丰富的服务发布方式
- 更高性能的数据面，增强的 L4 发布能力
- 直达服务 pod，减少延迟
- 避免大 IP 承载所有业务，分散 IP 失败导致的风险
- 跨部门协同，工作边界清晰
- 支持 Hub 模式的权限隔离，确保网络人员与应用人员不打架
- 支持 Multi k8s clusters
- 支持 DNS 联动
- 支持 WAF 策略声明式定义
- 支持与 Ingress Controller 配合与联动
F5 同时还提供了支持 Gateway API 规范的 F5 BIG-IP Next For Kubernetes（BNK）方案，它与 CIS 类似，但是无需额外的 BIG-IP 设备或虚机，部署形态是以容器方式直接部署在系统中，或部署在 DPU 网卡中。
总结
通过上述分析，我们可以意识到，这将不是一个简单的平移还是战略重构的二选一，从实际安全生产运维角度，如果您当前正在使用 Ingress 规范，我们将建议您首先采用同数据面技术、同规范的平移，在应用迁移稳定后再考虑引入最新的 Gateway API 规范。F5 NGINX Ingress Controller 是 NGINX 的原厂产品，是 Ingress-NGINX 迁移的最佳同数据面方案，并可以有效保证产品的后续延续性。您可以参考上述提到的迁移路径，可以顺滑的继续采用开源免费方案，也可以通过采用商业产品方案获得更多高级特性以及服务支持。而如果您正处于没有包袱的起始阶段，我们将建议您站在全局基础架构流量的角度重新考虑 Kubernetes 入口流量的设计，将其从架构性的角度引入，而不是仅仅为了面向开发人员进行简单业务发布的方式，您可以充分评估 F5 CIS 方案以及支持 Gateway API 规范的 F5 BIG-IP Next For Kubernetes（BNK）方案。
迁移必然会以过渡的形态持续较长时间，如果您遇到任何迁移的问题，欢迎与 F5 销售代表联系，获得我们专业迁移咨询服务。
点击下方文章，阅读迁移手册
