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 销售代表联系，获得我们专业迁移咨询服务。

点击下方文章，阅读迁移手册

01从 Ingress-NGINX Controller 迁移至 NGINX Ingress Controller

02将部署从 NGINX Ingress Controller 迁移至 NGINX Gateway Fabric