随着 Istio 1.22 版本的发布,Istio API 已正式升级至 v1 版本,同期,Kubernetes Gateway API 也更新至 v1.1 版本。本篇文章旨在深入探索 Ingress API、Istio API 与 Kubernetes Gateway API 之间的联系与区别,并详述它们在现实应用中的选择及迁移策略。
之前,我曾撰写一篇文章,讨论了 为何 Gateway API 是 Kubernetes 与服务网格入口中的未来方向。文章中指出,作为 Kubernetes 的初始入口网关,Ingress 的资源模型由于过于简单,难以满足当下的可编程网络需求。作为其接班人,Gateway API 近年来发展迅速,获得了广泛支持,包括众多新兴的开源网关项目如 Envoy Gateway 也选择基于 Gateway API 开发。此外,一些传统网关项目也开始适配 Gateway API,或通过 ingress2gateway 这样的工具进行迁移。
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 的推出,特别是其在提升与现有 Ingress 配置兼容性方面的改进,为用户提供了一个平稳的迁移途径,使从传统的 Ingress 解决方案向更现代的、功能更全面的 Gateway API 的过渡变得更为顺畅。
若想从 Ingress 迁移到 Gateway API,请按以下步骤操作:
Gateway
、HTTPRoute
和 TLSRoute
。这些资源提供了更多的配置选项和灵活性,请参阅 Gateway API 文档以了解其配置。Gateway
资源配置,明确定义如何接收外部流量,包括配置协议、端口和 TLS 终端。为了简化迁移过程,你可以使用工具如 ingress2gateway,该工具能自动将 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 和 Istio API 用户,是否需要迁移到 Gateway API 取决于具体情况。以下是一些迁移建议:
对于不同网关对 Gateway API 的支持情况,可以参考 Gateway API 实现项目的一致性报告了解详细信息。
Ingress API、Istio API 和 Kubernetes Gateway API 各具特色,适应不同的应用场景和需求。选择合适的 API,进行合理的规划和管理,可以显著提高系统的灵活性和稳定性。随着 Gateway API 的持续发展和成熟,它将越来越成为未来流量管理的主流选择。
选择合适的网关技术,结合你的具体需求和现有架构,可以更好地管理和优化流量,确保应用的高效和稳定运行。随着技术的进步和社区的发展,Gateway API 提供了一个强大且灵活的框架,使得从传统的 Ingress 迁移到更现代的解决方案变得更为简单和高效。
最后更新于 2024/11/27