Kubernetes Ingress Gateway API Istio API 应用场景

        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 APIIngress稳定 (Kubernetes v1.19)适用于小规模和简单的应用场景,主要用于基本的路由配置
Istio APIVirtualServiceGateway稳定 (Istio 1.22)适用于高度复杂的微服务架构,需细粒度控制和高级流量管理特性的场景
Gateway APIHTTPRouteGateway稳定 (Gateway API v1.1)适用于新部署或现有部署,需提高灵活性和可扩展性的场景,特别是结合 Istio 使用

Gateway API v1.1[4] 的推出,特别是其在提升与现有 Ingress 配置兼容性方面的改进,为用户提供了一个平稳的迁移途径,使从传统的 Ingress 解决方案向更现代的、功能更全面的 Gateway API 的过渡变得更为顺畅。

从 Ingress 迁移到 Kubernetes Gateway API

若想从 Ingress 迁移到 Gateway API,请按以下步骤操作:

  1. 1. 理解关键差异:与 Ingress 相比,Gateway API 引入了多种新的概念和资源类型,如 GatewayHTTPRoute 和 TLSRoute。这些资源提供了更多的配置选项和灵活性,请参阅 Gateway API 文档[5]以了解其配置。

  2. 2. 配置入口点:创建 Gateway 资源配置,明确定义如何接收外部流量,包括配置协议、端口和 TLS 终端。

  3. 3. 映射旧资源:将现有的 Ingress 资源映射到对应的 Gateway API 资源。例如,Ingress 中的 host 和 path 规则需要转换为 HTTPRoute 中的路由规则。

  4. 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/

引用:探索 Kubernetes Ingress、Gateway API 与 Istio 的演进和转型

  • 15
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值