Ingress2Gateway 核心架构解析Provider 与 Emitter 的设计哲学【免费下载链接】ingress2gatewayConvert Ingress resources to Gateway API resources项目地址: https://gitcode.com/gh_mirrors/in/ingress2gateway在现代 Kubernetes 生态系统中Ingress2Gateway 作为一个革命性的迁移工具为开发者提供了从传统 Ingress 到现代化 Gateway API 的无缝转换方案。这个开源项目不仅简化了 Kubernetes 网络配置的升级路径更通过其精妙的 Provider 与 Emitter 架构设计展现了模块化、可扩展的软件工程哲学。 Ingress2Gateway 项目概述Kubernetes 网络演进的关键桥梁Ingress2Gateway 是 Kubernetes SIG-Network 子项目的重要组成部分专注于将传统的 Ingress 资源和供应商特定的 CRDCustom Resource Definitions转换为现代化的 Gateway API 资源。随着 Kubernetes 社区在 2025 年宣布 Ingress NGINX 的退役计划这个工具变得尤为重要——它帮助用户平滑迁移到更强大、更标准的 Gateway API 生态系统。项目的核心价值在于解决了一个关键问题Ingress NGINX 拥有约 100 个自定义注解这些注解没有直接的 Gateway API 映射。Ingress2Gateway 通过其精巧的架构设计能够将这些供应商特定的扩展功能转换为标准的 Gateway API 资源同时保持功能的完整性和一致性。️ 核心架构设计分层解耦的智慧Provider 层多样化的输入适配器Provider 是 Ingress2Gateway 架构中的输入层负责读取和理解不同供应商的 Ingress 配置。每个 Provider 都专门处理特定供应商的注解和 CRD将它们转换为统一的中间表示Intermediate Representation简称 IR。Provider 的核心职责包括从 Kubernetes 集群或文件中读取 Ingress 资源解析供应商特定的注解和 CRD将异构的配置转换为标准化的中间表示Provider 接口定义pkg/i2gw/provider.gotype Provider interface { CustomResourceReader ResourcesToIRConverter }当前支持的 Provider 包括ingress-nginx处理 NGINX Ingress Controller 的 100 注解traefik支持 Traefik 代理的特定配置kong处理 Kong Gateway 的扩展功能istio支持 Istio 服务网格的配置apisixApache APISIX 网关的配置转换ciliumCilium 服务网格的特定功能中间表示层统一的数据模型中间表示IR是整个架构的核心抽象层它作为一个通用数据模型连接了 Provider 和 Emitter。IR 包含了所有必要的信息既能够表达标准的 Gateway API 功能也能够捕获那些暂时无法用标准 Gateway API 表达的供应商特定功能。IR 的关键设计原则中立性不偏向任何特定供应商完整性保留所有原始配置信息可扩展性支持新的供应商特定功能ProviderIR 结构定义pkg/i2gw/provider_intermediate/intermediate_representation.gotype ProviderIR struct { Gateways map[types.NamespacedName]GatewayContext HTTPRoutes map[types.NamespacedName]HTTPRouteContext Services map[types.NamespacedName]ProviderSpecificServiceIR GatewayClasses map[types.NamespacedName]gatewayv1.GatewayClass TLSRoutes map[types.NamespacedName]gatewayv1.TLSRoute // ... 其他资源类型 }Emitter 层灵活的输出生成器Emitter 是架构的输出层负责将中间表示转换为最终的 Gateway API 资源。Ingress2Gateway 支持多种 Emitter每种 Emitter 可以生成针对特定 Gateway API 实现优化的输出。Emitter 的主要类型standard生成标准的 Gateway API 核心资源默认envoy-gateway生成 Envoy Gateway 特定的扩展资源agentgateway输出 Agent Gateway 兼容的配置gce生成 Google Cloud Engine 特定的策略资源Emitter 接口定义pkg/i2gw/emitter.gotype Emitter interface { // Emit converts stored IR with the Provider into // Gateway API resources and extensions Emit(emitterir.EmitterIR) (GatewayResources, field.ErrorList) } 数据处理流程三阶段转换的优雅实现第一阶段Provider 到中间表示当用户运行ingress2gateway print --providersingress-nginx命令时系统会资源读取Provider 从 Kubernetes 集群或文件中读取 Ingress 资源注解解析解析供应商特定的注解如 NGINX 的nginx.ingress.kubernetes.io/rewrite-target中间表示生成将所有配置转换为统一的 ProviderIR转换示例Ingress 的nginx.ingress.kubernetes.io/cors-allow-origin注解转换为 IR 中的 CORS 配置信息保留所有原始语义但不绑定到任何特定实现第二阶段公共 Emitter 处理公共 Emitterpkg/i2gw/emitters/common_emitter/emitter.go作为中间层执行以下关键操作标准化处理将 IR 中的通用功能映射到标准 Gateway API实验性功能控制根据配置决定是否包含实验性 Gateway API 功能错误报告记录任何在转换过程中丢失的信息第三阶段特定 Emitter 输出最终特定的 Emitter 接收经过公共 Emitter 处理后的 IR并生成最终的输出标准资源生成创建 Gateway、HTTPRoute、GatewayClass 等核心资源扩展资源创建生成供应商特定的扩展资源如 Envoy Gateway 的 BackendTrafficPolicy格式序列化输出为 YAML、JSON 或 KYAML 格式 设计哲学模块化与可扩展性的完美平衡1. 关注点分离原则Ingress2Gateway 的架构严格遵循关注点分离Separation of Concerns原则Provider只关心如何理解特定供应商的配置Emitter只关心如何生成特定实现的输出中间表示作为通用语言连接两者而不耦合这种设计使得添加新的供应商支持变得异常简单——只需实现一个新的 Provider无需修改现有代码。2. 插件化架构项目的插件化设计体现在以下几个方面Provider 注册机制pkg/i2gw/provider.govar ProviderConstructorByName map[ProviderName]ProviderConstructor{} type ProviderConstructor func(conf *ProviderConf) ProviderEmitter 注册机制pkg/i2gw/emitter.govar EmitterConstructorByName map[EmitterName]EmitterConstructor{} type EmitterConstructor func(conf *EmitterConf) Emitter这种设计允许第三方供应商轻松集成自己的 Provider 和 Emitter促进了生态系统的繁荣发展。3. 渐进式迁移支持Ingress2Gateway 的设计考虑到了实际迁移场景的复杂性部分支持即使某些注解没有直接的 Gateway API 对应物工具也会生成警告而不是失败向后兼容确保生成的 Gateway API 配置与原始 Ingress 行为一致可验证性提供详细的转换报告帮助用户验证转换的正确性 实际应用从 Ingress 到 Gateway API 的完整转换转换示例NGINX Ingress 到标准 Gateway API考虑一个典型的 NGINX Ingress 配置apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/cors-allow-origin: * spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80经过 Ingress2Gateway 处理后会生成apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: example-gateway spec: gatewayClassName: nginx listeners: - name: http port: 80 protocol: HTTP hostname: example.com apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: example-route spec: parentRefs: - name: example-gateway hostnames: - example.com rules: - matches: - path: type: PathPrefix value: /api backendRefs: - name: api-service port: 80供应商特定功能的处理对于供应商特定的功能如 Envoy Gateway 的 CORS 支持Ingress2Gateway 会生成相应的扩展资源apiVersion: gateway.envoyproxy.io/v1alpha1 kind: HTTPRouteFilter metadata: name: cors-filter spec: cors: allowOrigins: - *️ 治理与维护确保长期稳定性第三方代码管理策略为了确保项目的长期稳定性Ingress2Gateway 制定了严格的第三方代码管理策略责任明确每个第三方 Provider/Emitter 必须有指定的维护者响应时间安全问题的响应时间不超过 3 个工作日更新承诺在 Gateway API 新版本发布后 60 天内完成适配代码组织规范所有第三方代码必须遵循以下组织规范独立目录每个供应商的代码位于独立的目录中CODEOWNERS 文件明确指定代码审查负责人模块化设计避免与其他供应商代码耦合 未来展望Gateway API 生态系统的催化剂Ingress2Gateway 不仅仅是一个迁移工具更是 Gateway API 生态系统发展的重要催化剂。通过降低迁移门槛它加速采用让更多用户能够轻松迁移到 Gateway API促进标准化推动供应商特定功能向标准 API 演进生态繁荣鼓励更多 Gateway API 实现的出现架构演进方向随着 Gateway API 的不断发展Ingress2Gateway 的架构也在持续演进更多 Provider 支持覆盖更广泛的 Ingress 控制器智能转换基于上下文的智能配置转换验证工具集成更强大的配置验证功能 最佳实践高效使用 Ingress2Gateway1. 渐进式迁移策略# 第一步分析现有配置 ingress2gateway print --providersingress-nginx --outputyaml analysis.yaml # 第二步小范围测试 kubectl apply -f generated-gateway-api.yaml --dry-runserver # 第三步分阶段迁移 # 先迁移非关键服务验证功能后再迁移核心服务2. 转换验证要点检查警告信息关注任何未完全转换的注解对比行为确保 Gateway API 配置与原始 Ingress 行为一致性能测试验证新配置的性能表现3. 持续集成集成将 Ingress2Gateway 集成到 CI/CD 流水线中# GitHub Actions 示例 - name: Convert Ingress to Gateway API run: | ingress2gateway print --providersingress-nginx \ --input-filemanifests/ingress.yaml \ --outputyaml manifests/gateway-api.yaml # 验证生成的配置 kubectl apply --dry-runserver -f manifests/gateway-api.yaml 总结架构设计的艺术Ingress2Gateway 的 Provider 与 Emitter 架构展现了现代软件设计的精髓模块化清晰的职责边界易于理解和维护可扩展性插件化设计支持无限扩展实用性解决真实世界的迁移问题前瞻性为 Gateway API 生态系统的未来铺平道路通过这种精心设计的架构Ingress2Gateway 不仅解决了当前的技术挑战更为 Kubernetes 网络配置的未来发展奠定了坚实的基础。无论是对于正在考虑迁移到 Gateway API 的团队还是对于希望理解现代云原生架构设计的开发者这个项目都提供了宝贵的参考和启示。核心文件路径参考主入口文件main.goProvider 接口定义pkg/i2gw/provider.goEmitter 接口定义pkg/i2gw/emitter.go中间表示结构pkg/i2gw/provider_intermediate/intermediate_representation.go公共 Emitter 实现pkg/i2gw/emitters/common_emitter/emitter.go命令行实现cmd/print.go【免费下载链接】ingress2gatewayConvert Ingress resources to Gateway API resources项目地址: https://gitcode.com/gh_mirrors/in/ingress2gateway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考