原文作者：Dave McAllister - OSS Technologist
原文链接：从 F5 NGINX Ingress Controller 迁移到 F5 NGINX Gateway Fabric
转载来源：NGINX 中文社区
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
Kubernetes 生态系统正在网络处理方式上经历一次重大变革：从传统的 Ingress API 及 annotation，转向更先进的 Gateway API。这一转变源于现代应用复杂性的持续提升，以及对更精细化流量管理能力的需求。作为应用交付领域的领先者，NGINX 站在这一变革的前沿，同时提供面向当前与未来需求的 F5 NGINX Ingress Controller（NIC），以及面向高级部署的 F5 NGINX Gateway Fabric（NGF）。
现状：F5 NGINX Ingress Controller
多年来，Kubernetes 一直依赖 Ingress controller 来管理外部流量。开源的 NGINX Ingress Controller 因其高性能、可靠性以及丰富的功能集而备受青睐。它在 HTTP/HTTPS 路由、SSL 终止和负载均衡方面表现出色。尽管 NGINX Ingress Controller 持续创新和发展，但 Kubernetes 部署面对日益复杂的流量管理需求，需要新的解决方案。
NGINX Ingress Controller 的优势
•成熟与稳定性：NGINX Ingress Controller 是一个成熟的解决方案，在性能和可靠性方面有着良好的记录。
•高级功能：它具备完善的流量管理能力，包括第 4 层和第 7 层负载均衡、限流和熔断机制。
•安全性：集成了 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 概述
基于开源 NGINX 数据面，NGINX Gateway Fabric 实现了 Kubernetes Gateway API，为 Kubernetes 应用提供统一的连接能力。其原生的基于角色的 API 模型，支持在多租户团队之间实现自助式治理与基础设施层面的权限划分。同时，它允许在混合云或多云 Kubernetes 环境中复用同一套数据面和控制面，并保持两者的逻辑分离，从而提升安全性、灵活性和可靠性。
控制面是基于 controller-runtime 库构建的 Kubernetes 控制器，以 Deployment 的形式运行，用于管理 NGINX 数据面资源。通过监听 Gateway API resource、Service、Endpoint 和 Secret 的变更，它能够自动完成相关资源的创建和配置工作。
NGINX 数据面 Pod 可以以独立的 Deployment 或 DaemonSet 的形式进行部署。每个 Pod 都包含一个 NGINX 容器，该容器同时运行 NGINX 进程以及开源的 NGINX Agent。
下图展示了 NGINX Gateway Fabric 的设计和结构。
使用 NGINX Gateway Fabric 的关键优势
•灵活性与可扩展性：NGINX Gateway Fabric 支持多种协议（HTTP、TCP、gRPC 等），并内置对蓝绿部署和金丝雀部署等高级部署模式的支持。
•面向角色的设计：为基础设施提供者、集群运维人员和应用开发者提供不同角色，有助于提升管理性和安全性。
•前瞻性布局：随着 Kubernetes 社区聚焦于 Gateway API，现在采用 NGINX Gateway Fabric 是为组织赢得长期优势的关键举措。
•可移植性与标准化：作为标准化 API，NGINX Gateway Fabric 提升了不同 Gateway API 实现与供应商间的可移植性，由于配置大体相同，从而减少了供应商锁定，并简化了控制器间的配置迁移。
•表达能力增强与高级功能：该 API 在流量路由与管理方面具备更强的表达能力，原生支持基于请求头的匹配、流量权重分配及更复杂的路由规则，减少对供应商特定 annotation 的依赖。
迁移辅助工具
不同厂商使用的 annotation 各不相同，因此在 Ingress Controller之间进行迁移具有挑战性。将 Ingress Controller 迁移到类似 NGF 的 Gateway API 也可能面临类似挑战，不过在不同的 Gateway API 实现之间进行迁移则相对容易。
一个很好的起点是 ingress2gateway，这是由 Kubernetes 社区开发的开源项目。作为 Gateway API SIG-Network 的子项目，ingress2gateway 旨在简化从 Kubernetes Ingress 迁移到更灵活的 Kubernetes Gateway API 的过程。该工具能够自动将现有的 Ingress resource（包括许多供应商特定的 annotation 和配置）转换为相应的 Gateway API resource，如 Gateway、GRPCRoute、HTTPRoute 和 BackendTLSPolicy。
F5 NGINX 为 NGINX Kubernetes 项目（NGINX Ingress Controller 和 NGINX Gateway Fabric）创建了一个 provider。具体来说，ingress2gateway 中的 NGINX provider 使得 NGINX Ingress Controller resource 可以转换为 Gateway API resource，以便在 NGINX Gateway Fabric 中部署。
即使您正在使用社区项目 ingress-nginx，一旦通过特定的 provider 完成了向 Gateway API 的迁移，就可以迁移到 NGINX Gateway Fabric。毕竟，Gateway API 的目标之一就是可移植性。
这并不是一个完整的端到端迁移解决方案。您需要手动审核已转换的资源，测试功能，并根据您的具体环境进行必要的额外配置更改。
ingress2gateway 的关键功能与能力
•资源转换：ingress2gateway 可以将核心 Kubernetes Ingress resource 及其关联的 Service 转换为对应的 Gateway API resource。
•Annotation 支持：该工具支持各种 NGINX-specific annotation，并将其转换为相应的 Gateway API resource。
目前 ingress2gateway 支持的 annotation 包括：
•nginx.org/ssl-services：用于 SSL/TLS 后端连接，对应映射到 BackendTLSPolicy。
•nginx.org/grpc-services：用于 gRPC 后端连接，对应映射到 GRPCRoute。
•nginx.org/websocket-services：用于 WebSocket 后端连接，提供信息通知。
•nginx.org/proxy-hide-headers 和 nginx.org/proxy-set-headers：用于修改 headers，分别映射到 HTTPRoute 的 ResponseHeaderModifier 和 RequestHeaderModifier。
•nginx.org/rewrites：用于 URL 重写，映射到 HTTPRoute 的 URLRewrite filter。
•nginx.org/redirect-to-https 和 ingress.kubernetes.io/ssl-redirect：用于 SSL/HTTPS 重定向，映射到 HTTPRoute 的 RequestRedirect filter。
您可以在 GitHub 上的 NGINX provider 仓库中找到更详细的 annotation 列表及其与 Gateway API 的映射。目前一些资源尚不可用，如 virtualServer、VirtualServerRoute 和 transport server，但计划在未来提供支持。
使用方法与优势
使用带有 NGINX provider 的 ingress2gateway 主要包括两个部分：
•从 Cluster 转换：运行 ingress2gateway print --providers=nginx，直接从 Kubernetes cluster中转换 NGINX Ingress Controller resource。
•从文件转换：使用 ingress2gateway print --providers=nginx --input-file=nginx-ingress.yaml，从 YAML 文件中转换资源。
使用 ingress2gateway 的优势包括：
•简化迁移：通过自动化转换过程，ingress2gateway 降低了迁移到 Gateway API 所需的复杂性和工作量。
•一致性与准确性：该工具确保转换过程一致且准确，减少人工错误。
•支持高级功能：ingress2gateway 能将高级 NGINX Ingress Controller 功能（如 SSL/TLS 配置和 header 修改）转换为对应的 Gateway API resource。
从 Ingress Controller 迁移到 Gateway API
即使使用 ingress2gateway 搭配 NGINX provider，迁移到 Gateway API 仍需要谨慎规划。该过程包括以下几个步骤：
1.迁移前规划：记录当前设置，包括 Ingress object及 annotation。定义迁移目标和成功标准。
2.安装与配置：在现有 Ingress Controller 旁部署 NGINX Gateway Fabric。将 Ingress 配置转换为 Gateway API resource。
3.测试与验证：进行全面的功能和性能测试。验证安全性并监控性能指标。
4.流量切换：使用金丝雀部署等策略逐步将流量切换到 NGINX Gateway Fabric。
5.迁移后清理：在确认稳定运行后，退役旧的 Ingress Controller。
贡献与可扩展性
ingress2gateway 是一个欢迎贡献的开源项目，尤其是为新的 NGINX Ingress Controller annotation 添加支持。贡献者可以按照仓库提供的指南实现转换逻辑、添加测试并更新文档。
借助 ingress2gateway，组织可以简化向 Gateway API 的过渡，充分利用其灵活性、可扩展性以及高级流量管理能力。对于希望使用 NGINX Ingress Controller 和 NGINX Gateway Fabric 现代化 Kubernetes 网络基础设施的用户而言，该工具是一项重要资产。
结论
从 Ingress Controller 转向 Gateway API 是 Kubernetes 网络演进中的重要一步。NGINX 致力于支持这一过渡，既通过 NGINX Ingress Controller 满足当前需求，也通过 NGINX Gateway Fabric 应对未来需求。借助 ingress2gateway，组织可以简化向 Gateway API 的迁移，充分利用其灵活性、可扩展性以及高级流量管理能力。对于希望使用 NGINX Ingress Controller 和 NGINX Gateway Fabric 现代化 Kubernetes 网络基础设施的用户而言，该工具是一项重要资产。
无论您当前正在使用 NGINX Ingress Controller，还是计划采用 Gateway API，NGINX 都提供所需的工具、支持与创新，帮助您应对这一不断发展的网络环境。随着 Kubernetes 的不断成熟，NGINX 始终是稳健、安全且可扩展应用交付解决方案的可信合作伙伴。