在 Istio 项目的早期采用全局状态(State of the World,简称 SotW)的方式推送配置给 Envoy 代理。一旦有一个服务变更,就要将全局配置推送给所有 Sidecar,造成巨大的网络负担及控制平面的性能损耗。Istio 社区从几年前就开始开发增量 xDS 以解决此问题,并在最近几个 Istio 版本中支持了增量 xDS。在最近的 Istio 1.22 发布中,增量 xDS 成为默认开启的功能。本文将为你介绍 xDS、增量 xDS 及 Istio 的配置分发方式。
xDS(Extensible Discovery Service)是一种通信协议,用于在微服务架构中管理服务发现和动态配置。这种机制被广泛用于 Envoy 代理和 Istio 服务网格中,以管理各种类型的资源配置,如路由、服务发现、负载均衡设置等。
xDS 包括以下主要的发现服务,每种服务都负责不同类型的网络资源配置:
这些服务共同支持动态配置的分发和更新,使得基于 Envoy 的应用架构能够实时适应变化,提高可扩展性和灵活性。每种服务的实现可以独立进行,也可以通过聚合方式(如 ADS)进行统一管理。CNCF 也成立了 xDS API 工作组来推动 xDS API 为 L4/L7 数据平面配置提供事实上的标准,类似于 SDN 中 OpenFlow 在 L2/L3/L4 中所扮演的角色。
xDS 协议主要包括以下变体:
下表概述了 xDS 协议的四种变体,包括对每个变体的解释、使用场景以及优缺点的对比。这些变体为不同的网络环境和服务需求提供了多种选择,可以根据具体情况选择最合适的协议变体以优化服务的性能和资源使用。
变体类型 | 解释 | 使用场景 | 优点 | 缺点 |
---|---|---|---|---|
SotW | 每次都发送所有配置数据,不论是否有变化。 | 适用于配置较少变化的稳定环境。 | 简单易实现,易于理解和维护。 | 数据传输量大,不适合频繁更新配置的环境。 |
Delta xDS | 只传输变更的配置数据,而不是全部数据。 | 适用于配置频繁变化,需要快速响应变更的环境。 | 减少了不必要的数据传输,提高了效率。 | 实现复杂,需要客户端和服务端管理配置状态。 |
ADS | 通过单一的 gRPC 流来管理所有配置数据,无需为每种资源类型建立独立的连接。 | 适用于需要同时管理多种类型资源的复杂服务架构。 | 减少了网络连接数,简化了资源管理。 | 对于网络或服务质量差的情况,单点故障可能导致所有配置更新失败。 |
Delta ADS | 结合了 ADS 和增量 xDS 的优点,通过一个 gRPC 流聚合并且只传输变化部分的资源。 | 适用于既需要管理多种资源类型,又需要频繁更新配置的极其动态的环境。 | 提供了最大的灵活性和效率,适合大规模和高动态的服务架构。 | 实现最为复杂,对于配置管理的逻辑要求高,需要精确控制资源的变更和传输。 |
使用 xDS 协议的服务网格可以更灵活地管理微服务之间的通信和配置,减少了配置变更的延迟,提高了系统的响应速度和可靠性。
在 Istio 中,DiscoveryServer 作为 Envoy 的 xDS API 的实现,负责监听 gRPC 接口并根据 Envoy 的需求动态推送配置。它能够处理各种资源类型的请求,并根据服务的变更实时更新 Envoy 配置。此外,它还支持安全特性,如验证客户端证书,确保只有合法的服务实例可以接收配置数据。
使用 xDS 协议的变体通常涉及在 Envoy 代理或与之类似的服务网格配置中指定 xDS 服务器的详细信息。虽然不同的服务网格和代理服务器的配置细节可能有所不同,下面是一些通用的 YAML 配置示例,说明如何指定 xDS 服务器以及如何使用这些协议变体。
在 Envoy 的配置中,你可以通过静态资源或通过 API 动态获取资源的方式来使用 SotW。这里是一个简单的 Envoy 配置示例,显示了如何静态定义集群和监听器:
|
|
增量 xDS 的配置需要在 xDS 服务端支持增量协议,并在客户端配置中指定使用增量 xDS。Envoy 启动配置中需要添加 API 版本来启用增量 xDS:
|
|
使用 ADS 时,所有资源类型的配置通过一个单一的 API 端点聚合。这在 Envoy 配置中指定:
|
|
增量 ADS 通过在 ADS 配置中指定增量 API 类型,可以实现更为细粒度的更新:
|
|
这些配置示例需要根据你的具体环境和需求进行调整。更多细节和高级配置,你可以参考 Envoy 文档。
得益于 xDS 协议,如 Istio、Envoy Gateway 等可以通过 API 远程动态分发配置到 Envoy 代理。下图展示了 Istio 的配置分发流程(Sidecar 模式)。
Istio 中配置分发的主要流程说明:
kubectl apply
命令或其他 CI/CD 工具。Kubernetes 接收到配置文件并将其存储在 etcd 数据库中。这个配置分发流程确保了 Istio 能够动态管理和配置服务网格中的所有服务实例,提供一致的流量管理和策略执行。
起初,xDS 采用了“全局状态”(State of the World,简称 SotW)的设计,这意味着任何一个配置的更改都需要向 Envoy 发送所有配置的完整状态。这种方法在网络和控制平面上造成了巨大的负担,尤其是在大规模服务部署时。
在 2021 年的 EnvoyCon 上,Aditya Prerepa 和 John Howard 分享了 Istio 如何实现 Delta xDS,这是一种增量式的 xDS 实现。与传统的 SotW xDS 相比,Delta xDS 只发送变更的配置,显著减少了需要通过网络发送的配置数据量,从而提高了效率和性能。这种方法特别适用于那些配置频繁变更的环境,因为它只更新变化的部分而不是整个配置。
在实现 Delta xDS 的过程中,Istio 团队面临了多个挑战,包括如何确保配置更新的正确性以及避免潜在的资源泄漏。他们通过采用干运行(Dry-run)模式来并行运行 SotW 和 Delta 生成器,逐步发现并修复了实现中的缺陷。此外,他们还引入了新的 Envoy 类型,如虚拟主机发现服务(Virtual Host Discovery Service),以支持更细粒度的配置分发。
下图展示了 Delta xDS 增量配置的流程。
Delta xDS 配置流程如下:
该流程确保只有必要的变更被传输和应用,提高了效率并减少了网络和代理资源的负载。
虽然 Delta xDS 解决了在大规模网络下的配置分发的性能问题,但是 SotW 模式依然有它存在的意义,比如在初次下发配置的情况下。下表对比了 Istio 中的两种配置分发方式:SotW (State of the World) 和 Delta xDS。
对比项 | SotW | Delta XDS |
---|---|---|
数据传输量 | 每次传输完整的配置数据,不管配置是否有变更。 | 仅传输发生变化的配置数据,减少了数据传输量。 |
效率 | 在小型或变更少的环境中效率可接受。 | 在大型环境或频繁变更的环境中更高效。 |
复杂性 | 实现简单,易于理解和维护。 | 实现较为复杂,需要精细的变更跟踪和管理。 |
资源消耗 | 可能因为重复发送大量未变更的数据而增加服务器和网络负载。 | 更低的资源消耗,因为只处理变更的部分。 |
实时性 | 配置更新后立即发送全量配置,实时性高。 | 只发送变更部分,响应更快,减少处理时间。 |
适用场景 | 适合配置变动不频繁的小型至中型部署。 | 适合配置频繁变更或大规模部署的场景。 |
这个表格从数据传输量、效率、复杂性、资源消耗、实时性以及适用场景等多个角度对 SotW 和 Delta XDS 进行了对比,有助于在不同的使用环境中做出合适的选择。
在这篇文章中我分享了 xDS 的组成及 Istio 中配置分发的流程,还有 xDS 的两种模式 SotW 和 Delta xDS。随着 Delta xDS 在 Istio 1.22 版本中成为默认配置,这将有助于用户在大规模网络环境下轻松使用 Istio。
最后更新于 2024/10/08