📚 课程目录第3章 Envoy xDS协议详解

3. Envoy xDS 协议详解：CDS、EDS、LDS、RDS、SDS 的配置发现机制与数据流

xDS（Discovery Service）是 Envoy 与控制平面（如 Istio Pilot）之间的核心通信协议，它实现了控制面与数据面的解耦。Envoy 通过 xDS 协议动态获取配置，无需重启即可完成路由、监听器、集群和端点的变更。本章将深入剖析 CDS、EDS、LDS、RDS、SDS 五大发现服务的职责、数据流与交互机制。

3.1 xDS 协议概述与资源类型

xDS 基于 gRPC 流式通信或 REST-JSON 轮询，Envoy 作为客户端主动向控制平面发起订阅请求。每个 xDS 服务负责发现一类配置资源：

服务缩写	全称	发现资源	核心作用
CDS	Cluster Discovery Service	Cluster（集群）	定义上游服务的主机、连接池、负载均衡策略、健康检查等
EDS	Endpoint Discovery Service	ClusterLoadAssignment（端点）	提供集群中具体的端点 IP:Port 列表及权重、健康状态
LDS	Listener Discovery Service	Listener（监听器）	定义 Envoy 监听的端口、协议、过滤器链（FilterChain）
RDS	Route Discovery Service	RouteConfiguration（路由）	定义虚拟主机（VirtualHost）与路由规则，决定请求转发目标集群
SDS	Secret Discovery Service	Secret（证书/密钥）	动态分发 TLS 证书、私钥和验证上下文，实现 mTLS 热更新

关键认知： xDS 采用“最终一致性”模型。Envoy 在收到新配置后，会先进行校验（Schema Validation），再通过“热重启”或“原地更新”机制平滑切换，确保流量不中断。

3.2 五大 xDS 的配置发现机制

3.2.1 CDS：集群发现

CDS 是 Envoy 获取上游集群定义的入口。控制平面通过 CDS 下发集群名称、连接超时、断路器阈值、负载均衡算法（如 RING_HASH、LEAST_REQUEST）以及是否启用 EDS 等元信息。

订阅模式： Envoy 启动时订阅 /v3/discovery:clusters 资源。
关键字段： type（STRICT_DNS/EDS/STATIC）、connect_timeout、circuit_breakers。
典型场景： 新增微服务版本时，控制平面下发新的 Cluster 配置，Envoy 自动建立连接池。

3.2.2 EDS：端点发现

EDS 是动态端点管理的核心。当 Cluster 的 type 设置为 EDS 时，Envoy 会通过 EDS 获取该集群的端点列表。每个端点包含 IP、端口、健康状态（HEALTHY/UNHEALTHY）和权重。

细粒度控制： 支持按区域（Locality）划分端点，实现优先级路由和本地优先负载均衡。
健康反馈： Envoy 可将主动健康检查结果上报给控制平面，控制平面据此调整 EDS 响应。

3.2.3 LDS：监听器发现

LDS 定义了 Envoy 如何接收入站流量。每个 Listener 包含监听地址、协议（TCP/HTTP/HTTPS）、以及过滤器链（FilterChain）。过滤器链是 Envoy 处理流量的核心管道。

动态端口： 控制平面可以动态下发新的监听端口，例如为金丝雀发布创建临时监听器。
过滤器链匹配： 基于 SNI（Server Name Indication）或源 IP 选择不同的过滤器链，实现多租户隔离。

3.2.4 RDS：路由发现

RDS 负责将 HTTP 请求映射到目标集群。它定义虚拟主机（VirtualHost）、域名匹配规则、路径前缀/正则匹配、请求头修改、重定向和直接响应等策略。

层级关系： Listener 通过 route_config_name 引用 RDS 资源。
高级路由： 支持基于权重（Weighted Clusters）、请求头、Cookie 和查询参数的路由。

3.2.5 SDS：密钥发现

SDS 解决了证书轮换的难题。Envoy 通过 SDS 动态获取 TLS 证书和私钥，无需重启进程即可完成证书更新。Istio 中，SDS 由 istio-agent 或 node-agent 实现。

安全优势： 私钥仅存在于 Envoy 进程内存中，不落盘，降低泄露风险。
验证上下文： 同时下发 ValidationContext，包含受信任的 CA 证书，用于验证对端身份。

3.3 xDS 数据流与交互时序

Envoy 启动后，按照固定的依赖顺序发起 xDS 订阅。下图展示了完整的配置发现数据流：

3.4 增量 xDS 与最终一致性

Envoy 3.0 版本后，增量 xDS（Delta xDS）成为主流。相比全量推送（SotW，State of the World），增量推送只传递变更的资源，大幅降低控制平面和数据平面的 CPU/内存开销。

  增量 xDS 核心机制：
  资源版本号： 每个资源携带 version_info，Envoy 通过比对版本号决定是否更新。
订阅列表： Envoy 在请求中携带 resource_names_subscribe 和 resource_names_unsubscribe，实现按需订阅。
空响应： 当资源无变化时，控制平面返回空响应，Envoy 保持现有配置。

3.5 故障排查要点

在 xDS 配置发现过程中，常见故障包括配置版本不一致、端点未更新、证书过期等。以下是关键排查步骤：

检查 xDS 订阅状态： 使用 curl localhost:15000/config_dump 导出 Envoy 当前配置，对比控制平面预期配置。
验证版本号： 查看 Envoy 日志中的 version_info，确认是否与控制平面推送的版本一致。
EDS 端点健康： 通过 /clusters 管理端点查看端点状态，确认是否为 healthy。
SDS 证书轮换： 检查 /certs 管理端点，确认证书过期时间是否在合理范围内。
网络连通性： 确保 Envoy 与控制平面之间的 gRPC 连接未中断，且无防火墙拦截。

常见陷阱： 当 LDS 或 CDS 配置变更时，如果引用的 RDS 或 EDS 资源尚未更新，Envoy 会保留旧的路由或端点，导致“配置漂移”。建议控制平面按 LDS → RDS → CDS → EDS 的顺序推送更新，或使用 warm-up 机制平滑过渡。

3.6 小结

xDS 协议是 Envoy 动态配置的基石。CDS 定义集群拓扑，EDS 提供端点列表，LDS 控制流量入口，RDS 决定请求转发路径，SDS 保障通信安全。理解这五大服务的职责与数据流，是进行 Envoy 故障排查和策略即代码（Policy as Code）实现的前提。在生产环境中，建议启用增量 xDS 并监控配置版本一致性，以保障服务网格的稳定运行。