从F5 NIC迁移到NGF：Kubernetes网关现代化与Gateway API实践指南

Kubernetes 生态的网络格局正在经历一场深刻的范式转移——从传统的 Ingress API 及大量定制化注解（annotation），转向更现代化、标准化的 Gateway API。这一变革的驱动力在于，现代应用的复杂度不断提升，对流量管理的精细度和可扩展性提出了更高要求。作为应用交付领域的领导者，NGINX 为不同阶段的用户提供了清晰的路径：既可以通过成熟的 F5 NGINX Ingress Controller（NIC）满足当前需求，也能通过面向未来的 F5 NGINX Gateway Fabric（NGF）拥抱更先进的 Kubernetes 网关架构。

现状基石：F5 NGINX Ingress Controller

长久以来，Kubernetes 集群依赖 Ingress Controller 来管理外部流量。其中，开源的 NGINX Ingress Controller 以其卓越的性能、稳定性和丰富的功能集，赢得了广泛认可。它在 HTTP/HTTPS 路由、SSL 终止以及负载均衡方面表现优异。

NGINX Ingress Controller 的核心优势

• 成熟与稳定：这是一个经过大规模生产环境验证的解决方案，拥有出色的性能和可靠性记录。
• 高级功能：具备完善的流量管理能力，涵盖第 4 层（TCP/UDP）和第 7 层（HTTP）负载均衡、请求限流和熔断保护。
• 安全性：能够集成 NGINX App Protect 以提供 Web 应用防火墙（WAF）能力，同时支持 DDoS 防护及强大的身份验证机制。
• 可观测性：通过详尽的访问日志和与 Prometheus、Grafana 等 云原生 监控生态的无缝集成，实现了对系统状态的高度可观测。

未来方向：Gateway API 与 F5 NGINX Gateway Fabric

Gateway API 代表了 Kubernetes 网络体系的一次重大演进。它通过一个更灵活、可扩展且功能强大的框架，解决了传统 Ingress API 的诸多局限性。顺应这一趋势，NGINX 推出了开源的 NGINX Gateway Fabric，作为对 Gateway API 的官方实现。

NGINX Gateway Fabric 架构概述
NGF 基于开源的 NGINX 数据面，完整实现了 Kubernetes Gateway API，旨在为 Kubernetes 应用提供统一、标准的连接入口。其原生基于角色的 API 模型，支持在多团队、多租户环境中实现自助式治理与基础设施层的权限隔离。

控制面是一个基于 controller-runtime 库构建的 Kubernetes 控制器，通常以 Deployment 形式运行，负责监听 Gateway API 资源（如 Gateway、HTTPRoute）、Service、Endpoint 和 Secret 的变化，并自动驱动 NGINX 数据面的配置更新。

数据面 Pod 则可以部署为独立的 Deployment 或 DaemonSet。每个 Pod 内运行着一个 NGINX 容器，该容器同时承载了 NGINX 进程以及用于与控制面通信的开源 NGINX Agent。

下图清晰地展示了 NGINX Gateway Fabric 的设计架构与数据流。

采用 NGINX Gateway Fabric 的五大优势

1. 灵活性与可扩展性：原生支持 HTTP、TCP、gRPC 等多种协议，并内置对蓝绿部署、金丝雀发布等高级部署模式的支持。
2. 面向角色的设计：清晰划分了基础设施提供者、集群管理员和应用开发者的职责，提升了管理的规范性和安全性。
3. 前瞻性布局：随着 Kubernetes 社区将重心转向 Gateway API，现在采用 NGF 是为组织赢得长期技术优势的战略选择。
4. 可移植性与标准化：作为标准化 API 的实现，NGF 提升了在不同 Gateway API 实现之间迁移的可移植性，减少了供应商锁定的风险。
5. 表达能力增强：API 本身具备更强的流量路由表达能力，原生支持基于请求头匹配、流量权重分配等复杂规则，减少了对供应商特定注解的依赖。

迁移利器：ingress2gateway 工具

由于不同厂商的 Ingress Controller 使用了各不相同的注解，迁移工作历来充满挑战。而从 Ingress 迁移到类似 NGF 这样的 Gateway API 实现，同样可能面临配置转换的难题。幸运的是，Kubernetes 社区提供了开源工具 ingress2gateway，它隶属于 Gateway API SIG-Network，专门用于简化从 Kubernetes Ingress 到 Gateway API 的迁移过程。

该工具能够自动将现有的 Ingress 资源（包括许多供应商特定的注解和配置）转换为对应的 Gateway API 资源，如 Gateway、HTTPRoute、GRPCRoute 和 BackendTLSPolicy。

F5 NGINX 的专属支持
F5 NGINX 为 ingress2gateway 工具创建了专用的 NGINX provider。这意味着，使用此 provider，可以将 NGINX Ingress Controller 的资源配置转换为适用于 NGINX Gateway Fabric 的 Gateway API 资源配置。即使你目前使用的是社区版的 ingress-nginx，一旦通过工具转换为 Gateway API 配置，未来也可以相对平滑地迁移到 NGF，这正是 Gateway API 强调的可移植性价值所在。

ingress2gateway 的核心功能

• 资源转换：将核心的 Kubernetes Ingress 资源及其关联的 Service 转换为对应的 Gateway API 资源。
• 注解支持：支持转换一系列 NGINX 特有的注解，例如：
  • nginx.org/ssl-services -> 映射为 BackendTLSPolicy
  • nginx.org/grpc-services -> 映射为 GRPCRoute
  • nginx.org/rewrites -> 映射为 HTTPRoute 的 URLRewrite 过滤器
  • nginx.org/proxy-hide-headers 和 nginx.org/proxy-set-headers -> 映射为 HTTPRoute 的 ResponseHeaderModifier 和 RequestHeaderModifier
  • nginx.org/redirect-to-https -> 映射为 HTTPRoute 的 RequestRedirect 过滤器

使用方法简述
使用带 NGINX provider 的 ingress2gateway 主要有两种方式：

1. 从集群直接转换：运行 ingress2gateway print --providers=nginx，工具会直接读取当前 Kubernetes 集群中的 NGINX Ingress 资源进行转换。
2. 从 YAML 文件转换：运行 ingress2gateway print --providers=nginx --input-file=nginx-ingress.yaml，对本地存储的 YAML 配置文件进行转换。

重要提示：ingress2gateway 是一个强大的辅助工具，但并非全自动的端到端迁移方案。转换后的资源需要经过人工审核、功能测试，并根据具体环境进行必要的调整和验证。

从 Ingress Controller 到 Gateway API 的迁移步骤

即使借助了 ingress2gateway 工具，迁移过程仍需周密计划。一个典型的迁移流程包含以下关键步骤：

1. 迁移前规划：详细记录当前的 Ingress 配置和所有注解，明确迁移的目标和成功验收标准。
2. 安装与配置：在现有 Ingress Controller 旁并行部署 NGINX Gateway Fabric。使用工具将 Ingress 配置转换为 Gateway API 资源配置，并应用到新环境。
3. 测试与验证：进行全面的功能测试、集成测试和性能基准测试。验证所有安全策略是否生效，并监控关键性能指标。
4. 流量切换：采用金丝雀发布等策略，逐步将生产流量从旧的 Ingress Controller 切换到新的 NGINX Gateway Fabric。
5. 迁移后清理：在确认 NGF 稳定运行并承载全部流量后，安全地退役旧的 Ingress Controller 及相关资源。

结论

从 Ingress Controller 转向 Gateway API 是 Kubernetes 网络 演进中的关键一步。NGINX 通过提供 NGINX Ingress Controller（NIC）和 NGINX Gateway Fabric（NGF），为用户架起了从当下通往未来的桥梁。借助 ingress2gateway 这样的社区工具，可以显著降低迁移到 Gateway API 的复杂性和风险，让组织能够充分利用新标准带来的灵活性、强大表达力与生态兼容性。

无论你是希望巩固现有的 Nginx Ingress 部署，还是计划率先采用 Gateway API 来构建更现代化的应用流量入口，NGINX 都提供了相应的工具、专业支持与持续创新，帮助你在快速变化的云原生环境中保持竞争力。

本文由 云栈社区 整理发布，旨在为开发者提供清晰的 Kubernetes 网关技术演进路径与实践参考。