Gateway API,作为 Kubernetes 入口网关的最新成果,通过角色划分来分离关注点,并支持跨 namespace,更适合多云环境。它整合了入口网关(南北向)与服务网格(东西向,集群内路由)的重叠功能,为云原生时代的统一流量管理提供了新的参考模型。
Ingress API、Gateway API 与 Istio API 都能实现网关功能,它们之间具体有何联系与区别?本文将为你揭晓这一迷题,并提供 Kubernetes 环境中网关的选择和迁移策略。
随着微服务架构的广泛应用和日益增长的复杂性,Kubernetes 的流量管理工具也在不断演进以适应各种技术需求。Ingress API、Istio API 与 Kubernetes Gateway API 分别标志着这一演变的不同阶段。
Ingress API 提供了 Kubernetes 的基本流量管理功能,允许用户通过定义简单的路由规则(例如 HTTP 和 HTTPS)来管理外部访问集群内服务的流量。其设计虽简洁,但功能有限,主要适用于规模较小、结构较简单的应用场景。
相比之下,Istio API 作为服务网格的一部分,提供了一系列高级流量管理功能,如流量镜像、金丝雀发布和断路器,适合于需要复杂流量管理的大规模微服务架构。
为了克服 Ingress API 的局限性并集成类似 Istio 的高级功能,Kubernetes Gateway API 因应而生。它不仅在设计上提供了更高的灵活性和扩展性,还通过社区的广泛支持,成为连接传统 Ingress 实现和现代服务网格技术如 Istio 的桥梁,目前主流的开源网关都是基于 Gateway API 或已进行适配。
以下表格概述了这三者的核心特点和推荐使用场景:
API 名称 | 对象类型 | 状态 | 推荐使用场景 |
Ingress API | Ingress | 稳定 (Kubernetes v1.19) | 适用于小规模和简单的应用场景,主要用于基本的路由配置 |
Istio API | VirtualService 、Gateway | 稳定 (Istio 1.22) | 适用于高度复杂的微服务架构,需细粒度控制和高级流量管理特性的场景 |
Gateway API | HTTPRoute 、Gateway | 稳定 (Gateway API v1.1) | 适用于新部署或现有部署,需提高灵活性和可扩展性的场景,特别是结合 Istio 使用 |
Gateway API v1.1[4] 的推出,特别是其在提升与现有 Ingress 配置兼容性方面的改进,为用户提供了一个平稳的迁移途径,使从传统的 Ingress 解决方案向更现代的、功能更全面的 Gateway API 的过渡变得更为顺畅。
从 Ingress 迁移到 Kubernetes Gateway API
若想从 Ingress 迁移到 Gateway API,请按以下步骤操作:
-
1. 理解关键差异:与 Ingress 相比,Gateway API 引入了多种新的概念和资源类型,如
Gateway
、HTTPRoute
和TLSRoute
。这些资源提供了更多的配置选项和灵活性,请参阅 Gateway API 文档[5]以了解其配置。 -
2. 配置入口点:创建
Gateway
资源配置,明确定义如何接收外部流量,包括配置协议、端口和 TLS 终端。 -
3. 映射旧资源:将现有的 Ingress 资源映射到对应的 Gateway API 资源。例如,Ingress 中的 host 和 path 规则需要转换为 HTTPRoute 中的路由规则。
-
4. 测试与部署:在正式迁移之前,在测试环境中验证新的 Gateway API 配置,确保所有流量路由正常,无安全漏洞。
为了简化迁移过程,你可以使用工具如 ingress2gateway[6],该工具能自动将 Ingress 配置转换为 Gateway API 格式。
实际迁移示例
以下是一个简单的 HTTP 网关配置示例,展示了如何将 Ingress 迁移到 Gateway API。
假设现有一个 Ingress 配置如下:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: example-service port: number: 80
要将其迁移到 Gateway API,首先需要创建一个 Gateway 对象:
apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: example-gateway spec: gatewayClassName: example-gateway-class listeners: - name: http protocol: HTTP port: 80 allowedRoutes: kinds - kind: HTTPRoute
请确保 gatewayClassName
指向你集群中配置的有效 GatewayClass。GatewayClass 通常由集群管理员设置,是一个为 Gateway 提供配置的资源。
接下来,创建 HTTPRoute 资源来定义路由规则,将流量路由到后端服务:
apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: example-httproute spec: parentRefs: - name: example-gateway hostnames: - "example.com" rules: - matches: - path: type: PathPrefix value: "/" backendRefs: - name: example-service port: 80
在此示例中,我们看到:
-
•
Ingress
对象中的规则被直接映射到HTTPRoute
对象中。 -
• 路由规则中的主机名匹配、路径匹配以及后端服务配置保持不变,只是对象和字段名称有所不同。
考虑的挑战
虽然可以将 Ingress 迁移到 Gateway API,并可能同时运行它们,但需要考虑以下挑战和迁移的必要性:
-
• 功能差异:某些 Ingress 控制器的特定功能可能在 Gateway API 中没有直接对应,可能需要通过额外的配置或自定义资源来实现。
-
• 多资源管理:Gateway API 的使用可能涉及比 Ingress 更多的资源类型和更复杂的配置,这可能增加管理的复杂性。
对于现有的 Ingress 和 Istio API 用户,是否需要迁移到 Gateway API 取决于具体情况。以下是一些迁移建议:
-
• 新部署:建议直接采用 Gateway API,以便利用其先进特性和预见未来的发展。
-
• 现有部署:如果现有系统运行稳定且无需高级特性,可以继续使用现有 API;如果希望利用 Gateway API 的新特性或计划未来长期发展,逐步迁移则是一个理智的选择。
对于不同网关对 Gateway API 的支持情况,可以参考 Gateway API 实现项目的一致性报告[7]了解详细信息。
总结
Ingress API、Istio API 和 Kubernetes Gateway API 各具特色,适应不同的应用场景和需求。选择合适的 API,进行合理的规划和管理,可以显著提高系统的灵活性和稳定性。随着 Gateway API 的持续发展和成熟,它将越来越成为未来流量管理的主流选择。
选择合适的网关技术,结合你的具体需求和现有架构,可以更好地管理和优化流量,确保应用的高效和稳定运行。随着技术的进步和社区的发展,Gateway API 提供了一个强大且灵活的框架,使得从传统的 Ingress 迁移到更现代的解决方案变得更为简单和高效。
参考
-
• Migrating from Ingress - gateway-api.sigs.k8s.io[8]
-
• Extending Gateway API support in Istio - istio.io[9]
引用链接
[1]
为何 Gateway API 是 Kubernetes 与服务网格入口中的未来方向: https://jimmysong.io/blog/why-gateway-api-is-the-future-of-ingress-and-mesh/[2]
Envoy Gateway: https://gateway.envoyproxy.io/[3]
ingress2gateway: https://github.com/kubernetes-sigs/ingress2gateway[4]
Gateway API v1.1: https://kubernetes.io/blog/2024/05/09/gateway-api-v1-1/[5]
Gateway API 文档: https://gateway-api.sigs.k8s.io/guides/[6]
ingress2gateway: https://github.com/kubernetes-sigs/ingress2gateway[7]
Gateway API 实现项目的一致性报告: https://gateway-api.sigs.k8s.io/implementations/v1.1/[8]
Migrating from Ingress - gateway-api.sigs.k8s.io: https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/[9]
Extending Gateway API support in Istio - istio.io: https://istio.io/latest/blog/2022/gateway-api-beta/