3. xDS协议与控制平面交互:CDS、EDS、LDS、RDS、SDS协议详解,控制平面(如Istiod)下发配置流程

xDS(Discovery Service)是Envoy与控制平面(如Istiod)之间通信的核心协议族。Envoy通过xDS API从控制平面动态获取各类配置资源,实现服务网格中的流量管理、安全策略和可观测性。本章深入解析五大核心xDS协议——CDS、EDS、LDS、RDS、SDS,并完整呈现Istiod下发配置的端到端流程。

3.1 xDS协议族概览

xDS协议采用客户端-服务器模型:Envoy作为xDS客户端,向控制平面发起订阅请求;控制平面作为xDS服务器,根据服务注册信息和配置规则生成响应。每个xDS协议负责一类特定的配置资源。

协议 全称 资源类型 核心作用
CDS Cluster Discovery Service envoy.config.cluster.v3.Cluster 定义上游服务集群(端点集合、负载均衡策略、连接池配置)
EDS Endpoint Discovery Service envoy.config.endpoint.v3.ClusterLoadAssignment 提供集群中具体的端点(IP:Port)列表及健康状态
LDS Listener Discovery Service envoy.config.listener.v3.Listener 定义Envoy监听的端口、协议、过滤器链
RDS Route Discovery Service envoy.config.route.v3.RouteConfiguration 定义虚拟主机和路由规则(流量匹配、转发目标、重试/超时策略)
SDS Secret Discovery Service envoy.extensions.transport_sockets.tls.v3.Secret 分发TLS证书、私钥、验证上下文,实现mTLS通信
关键理解:xDS协议之间并非独立工作,而是存在明确的依赖关系。LDS引用的路由名称需要RDS提供;RDS中指定的集群名称需要CDS定义;CDS中引用的端点名称需要EDS解析;而SDS则为LDS中的TLS传输套接字提供证书。这种层级依赖构成了Envoy配置的资源拓扑。

3.2 五大xDS协议详解

3.2.1 CDS — 集群发现服务

CDS定义了Envoy将流量转发到的上游集群。每个Cluster包含:

  • 名称:集群唯一标识,被RDS路由规则引用。
  • 连接类型:STRICT_DNS、LOGICAL_DNS、STATIC、EDS(动态端点发现)。
  • 负载均衡策略:ROUND_ROBIN、LEAST_REQUEST、RING_HASH、RANDOM。
  • 连接池配置:最大连接数、超时时间、健康检查参数。
  • 断路器设置:熔断阈值(最大连接数、最大请求数、最大重试数等)。
# CDS资源示例(简化)
name: "reviews.default.svc.cluster.local"
type: EDS
eds_cluster_config:
  eds_config:
    resource_api_version: V3
    api_config_source:
      api_type: GRPC
      transport_api_version: V3
      grpc_services:
        - envoy_grpc:
            cluster_name: "xds-grpc-cluster"
connect_timeout: 5s
lb_policy: LEAST_REQUEST
circuit_breakers:
  thresholds:
    - priority: DEFAULT
      max_connections: 1000
      max_pending_requests: 100
      max_requests: 2000

3.2.2 EDS — 端点发现服务

EDS是CDS的数据补充,为每个EDS类型的集群提供实时的端点列表。端点信息包括:

  • 地址:IP:Port。
  • 健康状态:UNKNOWN、HEALTHY、UNHEALTHY、DRAINING、TIMEOUT。
  • 权重:用于加权负载均衡。
  • 元数据:可用于区域感知路由或自定义筛选。
生产实践:EDS是服务网格实现动态端点感知的关键。当Pod滚动更新、扩缩容或出现故障时,Kubernetes EndpointSlice的变化会通过Istiod实时推送给Envoy,确保流量只发往健康的Pod实例。

3.2.3 LDS — 监听器发现服务

LDS定义了Envoy在哪个端口监听入站流量,以及如何处理这些流量。核心配置项:

  • 监听地址:IP:Port(如0.0.0.0:8080)。
  • 过滤器链:按协议(HTTP、TCP、TLS)匹配的过滤器列表。
  • 传输套接字:是否启用TLS/mTLS(引用SDS提供的证书)。
  • 流量方向:入站(Ingress)或出站(Egress)。

3.2.4 RDS — 路由发现服务

RDS定义了HTTP流量如何被匹配和转发。每个RouteConfiguration包含:

  • 虚拟主机:按域名(如reviews.default.svc.cluster.local)分组。
  • 路由规则:匹配条件(路径、Header、Query参数)+ 转发动作(路由到集群、重定向、直接响应)。
  • 高级策略:重试、超时、流量镜像、故障注入、CORS。
# RDS路由规则示例
virtual_hosts:
  - name: "reviews-vhost"
    domains: ["*"]
    routes:
      - match:
          prefix: "/reviews"
        route:
          cluster: "reviews.default.svc.cluster.local"
          timeout: 3s
          retry_policy:
            retry_on: "5xx"
            num_retries: 3
      - match:
          prefix: "/ratings"
        route:
          cluster: "ratings.default.svc.cluster.local"

3.2.5 SDS — 秘密发现服务

SDS负责分发TLS相关的敏感材料,避免证书和私钥以静态文件方式挂载到Envoy容器。SDS资源类型:

  • TLS证书:服务端/客户端证书 + 私钥。
  • 验证上下文:CA证书、SAN验证规则、证书吊销列表。
  • 会话票据密钥:用于TLS会话恢复。
安全注意:SDS是服务网格安全的基础。Istiod通过SDS为每个Sidecar动态下发mTLS证书,证书轮换周期通常为24小时。Envoy通过SDS流式API实时接收新证书,实现零停机证书轮换。

3.3 xDS协议交互流程

Envoy与控制平面之间的xDS交互遵循订阅-推送模式。Envoy启动后,按依赖顺序依次订阅各xDS资源。下图展示了完整的交互流程:

xDS协议交互流程 xDS协议交互流程 — Envoy ↔ Istiod Envoy Sidecar Istiod 控制平面 ① LDS 订阅 ② LDS 响应(监听器+路由引用) ③ RDS 订阅(基于LDS路由名) ④ RDS 响应(路由规则+集群引用) ⑤ CDS 订阅(基于RDS集群名) ⑥ CDS 响应(集群配置+EDS引用) ⑦ EDS 订阅(端点列表) SDS 订阅与LDS并行,为TLS监听器提供证书;所有xDS均采用流式gRPC,支持增量更新

3.4 Istiod配置下发完整流程

在Istio服务网格中,Istiod作为控制平面,将用户定义的VirtualService、DestinationRule、ServiceEntry等CRD转换为Envoy可理解的xDS资源。下发流程分为以下阶段:

  1. 配置监听:Istiod通过Kubernetes Informer监听Service、Pod、EndpointSlice、ConfigMap以及Istio CRD的变化。
  2. 模型转换:Istiod将CRD转换为内部模型(抽象语法树),合并全局配置和命名空间级别的覆盖规则。
  3. xDS生成:根据Envoy的订阅请求,Istiod将内部模型序列化为对应的xDS资源(LDS/RDS/CDS/EDS/SDS)。
  4. 增量推送:Istiod通过gRPC流式API将变更推送给所有订阅的Envoy实例,仅发送变化的部分(Delta xDS)。
  5. Envoy热加载:Envoy收到新配置后,在不中断现有连接的前提下,将新配置应用到监听器、集群和路由表。
性能关键点:Istiod的配置下发性能直接影响网格的收敛时间。在大规模集群(数千Pod)中,Istiod需要处理:
• 全量推送:首次连接或重连时发送完整配置。
• 增量推送:后续变更仅发送差异部分,减少网络开销和Envoy的CPU消耗。
• 缓存与去重:Istiod对相同配置进行缓存,避免重复计算。

3.5 xDS协议版本与演进

版本 API类型 关键特性 Envoy版本
v2 REST / gRPC 流式 首次标准化xDS,支持全量推送 1.8 - 1.18
v3 gRPC 流式(推荐) 增量xDS(Delta)、资源类型版本化、字段命名规范化 1.19+
Delta xDS gRPC 流式 仅推送变更资源,减少带宽和CPU,支持资源依赖排序 1.19+
迁移注意:Envoy 1.19+已弃用v2 API,所有新部署应使用v3 API。Istio 1.10+默认使用v3 xDS。如果使用自定义控制平面,请确保xDS服务器实现v3协议,否则Envoy将拒绝连接。

3.6 控制平面配置下发架构

下图展示了Istiod内部处理xDS请求的组件架构:

Istiod xDS配置下发架构 Istiod xDS配置下发架构 Kubernetes API Service / Pod / EndpointSlice Istio CRD VirtualService / DestinationRule Mesh Config MeshConfig / Sidecar CRD 配置缓存与模型转换 Informer 缓存 → 内部抽象语法树 → 依赖图构建 xDS资源生成器 LDS → RDS → CDS → EDS → SDS 按依赖顺序生成 gRPC流式推送 全量推送 / 增量推送(Delta xDS)→ 所有订阅Envoy

3.7 生产环境最佳实践

  • 启用Delta xDS:在Istio 1.12+中默认启用,显著减少大规模集群的配置推送延迟。
  • 配置推送QPS监控:通过Istiod指标pilot_xds_pushes和pilot_xds_push_time监控推送频率和耗时。
  • 避免全量推送:频繁的全量推送(如大量Pod同时滚动更新)可能导致Istiod CPU飙升和Envoy配置过载。使用PILOT_DEBOUNCE_AFTER和PILOT_DEBOUNCE_MAX控制推送合并窗口。
  • SDS证书预热:确保SDS证书在Envoy启动前已就绪,避免TLS握手失败。Istio通过SECRET_WARMUP机制解决此问题。
  • 资源依赖顺序:自定义控制平面实现xDS时,必须遵循LDS→RDS→CDS→EDS的依赖顺序,否则Envoy会因缺少依赖资源而拒绝配置。
排障技巧:当Envoy无法获取配置时,使用istioctl proxy-status查看每个Sidecar的xDS同步状态。如果显示SYNCED表示配置已下发;NOT SENT或STALE表示存在推送延迟或失败。进一步使用istioctl proxy-config查看Envoy当前加载的LDS/RDS/CDS/EDS资源详情。