3. xDS协议与控制平面交互

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

3.1 xDS协议族概览

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

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。
• 权重：用于加权负载均衡。
• 元数据：可用于区域感知路由或自定义筛选。

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会话恢复。

3.3 xDS协议交互流程

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

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收到新配置后，在不中断现有连接的前提下，将新配置应用到监听器、集群和路由表。

3.5 xDS协议版本与演进

3.6 控制平面配置下发架构

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

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会因缺少依赖资源而拒绝配置。