从Ingress Controller迁移到Gateway API

作者:API传播员 · 2025-10-28 · 阅读时间:5分钟

坚持使用像 NGINX Ingress Controller 这样的经典入口控制器,还是迁移到功能更强大的 Gateway API?本文将探讨从 Ingress 到 Gateway API 的演变过程,以及为什么选择实施 Gateway API(如 NGINX Gateway Fabric)可能是值得的。


经典之选:Ingress 控制器

多年来,Kubernetes 一直依赖 Ingress 控制器来处理外部(南北)流量进入集群的需求。Ingress 的设计简单明了,它将 Ingress 规则转换为代理能够理解和执行的配置。

然而,Ingress 模型也有其局限性。它诞生于 Kubernetes 的早期阶段,难以满足现代化需求,例如金丝雀发布或蓝绿部署等高级流量管理场景。此外,过多的注释可能导致配置变得复杂且难以维护,影响了可移植性。随着 Kubernetes 逐渐成为支持复杂微服务和应用的平台,Ingress 的局限性愈发明显。


Gateway API:面向未来的网络解决方案

为了解决 Ingress 的不足,Kubernetes 推出了 Gateway API。这不仅仅是一次小幅升级,而是对 Kubernetes 网络工作方式的全新构想。Gateway API 于 2023 年底达到了 v1.0 版本,并迅速获得了广泛关注。它通过更灵活、可扩展的框架,直接解决了 Ingress 的缺点。

Gateway API 引入了模块化的设计,明确划分了基础设施提供商、集群运营商和应用开发者的角色,并新增了 GatewayClass、Gateway 和 HTTPRoute 等资源。与 Ingress 不同,Gateway API 是协议无关的,支持 HTTP、TCP、gRPC 等多种协议,同时能够处理南北流量和东西流量。此外,它内置支持蓝绿部署和金丝雀发布等高级功能,避免了过多的注释堆积,使配置更加清晰和便携。

Kubernetes 社区在设计 Gateway API 时,特别关注以下三个关键组件:

  • 面向角色的设计:将路由和网关职责分离。
  • 协议无关性:支持多种协议类型。
  • 高级流量管理:内置支持复杂的流量分发需求。

NGINX 通过实现 Gateway API 的 NGINX Gateway Fabric,推动了 Kubernetes 网络的转型。该方案以 NGINX 作为数据平面,结合了 Gateway API 的前沿功能,为用户提供了高性能和可靠性的网络解决方案。


为什么选择迁移?

迁移到 Gateway API 意味着放弃 Ingress 控制器的简单性,接受更高的复杂性。这可能需要学习新的概念、管理更多资源,并面对更陡峭的学习曲线。如果现有的 Ingress 控制器已经满足需求,迁移可能显得多余。

但复杂性往往伴随着更大的灵活性和能力。如果您的用例较为简单(例如将 HTTP 流量路由到少量服务),Ingress 和 NGINX Ingress Controller 仍然是理想选择。然而,当需求变得更复杂时,Gateway API 的优势便显现出来。

Gateway API 的优势场景

  • 高级部署:例如蓝绿部署或金丝雀发布,Gateway API 提供了内置支持,无需依赖复杂的注释配置。
  • 协议支持:支持多种协议类型,满足不同场景需求。
  • 面向角色的设计:为团队间的职责划分提供了更清晰的框架。

为什么选择 NGINX Gateway Fabric?

NGINX Gateway Fabric 将 NGINX 的性能、稳定性和可靠性与 Gateway API 的功能相结合,不仅解决了当前的网络需求,还为 Kubernetes 网络的未来做好了准备。如果您的应用正在扩展到多个命名空间,或者需要零停机部署,那么 NGINX Gateway Fabric 的复杂性是值得的。

与其他选项不同,NGINX Gateway Fabric 提供了一个围绕 Gateway API 构建的单一接口。这意味着更少的配置混乱、更少的版本同步问题,以及更清晰的意图表达。此外,NGINX 团队全力支持这一过渡,确保用户能够顺利从传统的 Ingress 控制器迁移到 Gateway API。

值得注意的是,虽然 NGINX Ingress Controller 在短期内仍将继续支持,但 NGINX Gateway Fabric 是通往下一代 Kubernetes 网络的桥梁。它结合了 NGINX 的性能优势和 Gateway API 的先进功能,有望成为 Kubernetes 流量管理的默认标准。


迁移是否值得?

在选择继续使用 NGINX Ingress Controller 还是迁移到 NGINX Gateway Fabric 时,关键在于评估团队的具体需求。如果您的团队规模较小,应用简单且没有重大变更计划,Ingress Controller 可能仍然是最佳选择。(需注意,Kubernetes Ingress 的开发已停止。)

但如果您正在为扩展而构建,或者需要解决团队间共享集群的限制,亦或是希望采用面向角色的设计,那么 NGINX Gateway Fabric 将是更明智的长期选择。

尽管迁移可能面临挑战,但回报是一个为 Kubernetes 未来做好准备的网络解决方案。请思考:您的团队当前面临的最大网络挑战是什么?这将是决定是否迁移到 NGINX Gateway Fabric 的关键。


总结

从 Ingress Controller 迁移到 Gateway API 是一个重要的决策,取决于您的团队需求和未来规划。Gateway API 提供了更强大的功能和灵活性,而 NGINX Gateway Fabric 则将其与 NGINX 的性能结合,为 Kubernetes 网络管理提供了一个强大的解决方案。

原文链接: https://blog.nginx.org/blog/kubernetes-networking-ingress-controller-to-gateway-api