Ingress2Gateway 与 Gateway API 版本兼容性：从 v1.0 到 v1.5 的演进指南

Ingress2Gateway 与 Gateway API 版本兼容性：从 v1.0 到 v1.5 的演进指南

【免费下载链接】ingress2gatewayConvert Ingress resources to Gateway API resources项目地址: https://gitcode.com/gh_mirrors/in/ingress2gateway

Ingress2Gateway 是一个强大的 Kubernetes 工具，专门用于将传统的 Ingress 资源和供应商特定的 CRD 转换为现代化的 Gateway API 资源。随着 Kubernetes 生态系统的不断发展，Gateway API 已经从 v1.0 演进到 v1.5，而 Ingress2Gateway 也同步更新，确保用户能够平滑迁移。本文将深入解析 Ingress2Gateway 与 Gateway API 的版本兼容性演进，帮助您理解从 v1.0 到 v1.5 的关键变化和迁移策略。🚀

为什么需要关注版本兼容性？

随着 Kubernetes SIG-Network 宣布 Ingress NGINX 即将退役，迁移到 Gateway API 已成为 Kubernetes 用户的必然选择。Ingress2Gateway 作为官方推荐的迁移工具，其版本兼容性直接影响迁移的成功率和效率。了解不同版本的特性支持，可以帮助您：

• 选择合适的 Ingress2Gateway 版本进行迁移
• 避免因版本不匹配导致的转换错误
• 充分利用 Gateway API 的最新功能
• 规划平滑的升级路径

Gateway API 版本演进概览

v1.0 版本：奠定基础

Gateway API v1.0 是第一个稳定版本，为 Kubernetes 网络提供了标准化的 API 接口。在这个阶段，Ingress2Gateway 开始支持基本的 Ingress 到 Gateway API 的转换功能，包括：

• 基本的 HTTPRoute 转换
• 简单的 TLS 配置支持
• 基础的路由规则映射

v1.4 版本：功能扩展

Gateway API v1.4 引入了更多高级功能，Ingress2Gateway v0.5.0 开始支持这个版本，带来了：

• 更完善的路由匹配规则
• 增强的 TLS 配置选项
• 改进的跨命名空间引用支持

v1.5 版本：成熟稳定

Gateway API v1.5 是目前的最新稳定版本，Ingress2Gateway v1.0 完全支持这一版本。这个版本包含了：

• 完整的 CORS 配置支持
• 增强的路径重写功能
• 改进的负载均衡策略
• 更细粒度的流量管理

Ingress2Gateway 版本与 Gateway API 兼容性对照表

核心架构演进：从提供程序到发射器

传统架构（v1.0 之前）

在早期版本中，Ingress2Gateway 主要依赖提供程序（Providers）直接转换资源：

Ingress资源 → 提供程序 → Gateway API资源

现代架构（v1.0+）

v1.0 版本引入了创新的发射器（Emitters）架构，实现了更灵活的转换流程：

Ingress资源 → 提供程序 → 中间表示（IR） → 通用发射器 → 中间表示（IR） → 特定发射器 → Gateway API资源 + 供应商特定资源

这种架构的优势在于：

• 更好的代码复用和模块化
• 支持供应商特定的扩展
• 更容易添加新的转换功能

关键版本升级指南

从 v0.x 升级到 v1.0

这是最重要的版本升级，涉及架构的重大变化：

1. 发射器框架集成：新的插件式发射器架构分离了提供程序（Ingress → IR）和发射器（IR → Gateway API 资源）

2. 扩展的 ingress-nginx 注解支持：显著增加了注解覆盖范围，包括：

   • 头部操作（upstream-vhost,x-forwarded-prefix）
   • GRPC 支持注解
   • 金丝雀路由（canary-by-header,canary-by-header-value）
   • 路径重写（rewrite-target）
   • 超时配置（proxy-connect-timeout,proxy-send-timeout）
   • 永久/临时重定向（permanent-redirect,temporal-redirect）
   • 完整的 CORS 配置

3. E2E 测试框架：全面的端到端测试套件，支持 Ingress NGINX 和 Envoy Gateway 提供程序的真实集群测试

从 v1.0 升级到 v1.1

v1.1.0 版本带来了重要的功能增强：

1. Traefik 提供程序支持：新增 Traefik Ingress 资源和部分注解的转换支持

2. GCE Cloud CDN 支持：通过 GCPHTTPFilter 添加了 Cloud CDN 支持

3. ingress-nginx 功能扩展：

   • from-to-www-redirect支持
   • app-root支持
   • ssl-passthrough使用标准通道 TLSRoute 资源

从 v1.1 升级到 v1.2

v1.2.0 版本继续扩展发射器生态系统：

1. airlock-microgateway 发射器支持：新增对 airlock-microgateway 的支持

2. Bug 修复和改进：

   • 修复了正则表达式重写的警告问题
   • 改进了通知系统的报告分组

实际迁移示例

基本 Ingress 转换

假设您有一个简单的 Ingress 资源：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80

使用 Ingress2Gateway v1.2.0 转换为 Gateway API v1.5：

ingress2gateway print --providers=ingress-nginx --emitter=standard

转换后的 Gateway API 资源将包含符合 v1.5 规范的 Gateway 和 HTTPRoute 资源。

高级功能转换

对于使用高级 ingress-nginx 注解的配置：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: advanced-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 nginx.ingress.kubernetes.io/cors-allow-origin: "*" nginx.ingress.kubernetes.io/proxy-connect-timeout: "30" spec: # ... 其他配置

Ingress2Gateway v1.0+ 能够将这些注解转换为相应的 Gateway API 扩展策略。

版本兼容性最佳实践

1. 测试先行

在升级 Ingress2Gateway 版本前，始终在测试环境中验证转换结果：

# 使用特定版本进行测试 ingress2gateway print --providers=ingress-nginx --input-file=test-ingress.yaml --output=yaml > test-output.yaml kubectl apply --dry-run=client -f test-output.yaml

2. 逐步升级

不要一次性升级所有集群，采用渐进式升级策略：

1. 先升级开发环境的 Ingress2Gateway
2. 验证转换结果和应用程序功能
3. 逐步扩展到预生产和生产环境

3. 监控和通知

利用 Ingress2Gateway 的通知系统监控转换过程中的问题：

# 查看转换过程中的警告和通知 ingress2gateway print --providers=ingress-nginx --no-color 2>&1 | grep -i "warning\|notification"

4. 版本回滚计划

始终准备版本回滚计划，特别是在生产环境中：

• 备份当前的 Ingress 配置
• 记录当前的 Ingress2Gateway 版本
• 准备快速回滚到之前版本的脚本

常见问题与解决方案

Q: 升级后转换失败怎么办？

A: 首先检查 Ingress2Gateway 的版本与 Gateway API CRD 版本的兼容性。确保集群中安装的 Gateway API CRD 版本与工具支持的版本匹配。

Q: 如何知道哪些注解被支持？

A: 使用 Ingress2Gateway 的注解跟踪功能，它会报告哪些注解被解析、哪些不被支持、哪些无法识别：

ingress2gateway print --providers=ingress-nginx

Q: 如何处理供应商特定的扩展？

A: 使用相应的发射器（Emitter）来处理供应商特定的功能。例如，对于 Envoy Gateway 特定的功能，使用--emitter=envoy-gateway参数。

未来展望

随着 Gateway API 的持续发展，Ingress2Gateway 将继续保持同步更新。未来的版本可能会包括：

• 对 Gateway API 实验性功能的支持
• 更多供应商特定发射器的集成
• 改进的性能和扩展性
• 更智能的转换建议和优化

总结

Ingress2Gateway 与 Gateway API 的版本兼容性演进展示了 Kubernetes 网络生态系统的成熟过程。从 v1.0 的基础功能到 v1.5 的完整特性支持，Ingress2Gateway 已经成为从传统 Ingress 迁移到现代 Gateway API 的必备工具。

通过理解版本兼容性、采用最佳实践，并利用 Ingress2Gateway 的强大功能，您可以确保平滑、高效的迁移体验。无论是简单的路由规则还是复杂的供应商特定配置，Ingress2Gateway 都提供了可靠的转换解决方案。

记住，成功的迁移不仅仅是技术转换，更是架构现代化的机会。利用 Gateway API 的强大功能，构建更灵活、更可扩展的 Kubernetes 网络架构！🎯

【免费下载链接】ingress2gatewayConvert Ingress resources to Gateway API resources项目地址: https://gitcode.com/gh_mirrors/in/ingress2gateway