3. Envoy xDS 协议：控制面与数据面交互、xDS 类型与动态配置更新机制

在平台工程 IDP 的故障域隔离演练中，Envoy 作为数据面代理，其配置必须能够动态响应控制面下发的指令。xDS（Discovery Service）协议正是 Istio 控制面（Pilot）与 Envoy 数据面之间通信的核心契约。理解 xDS 的交互模型与各资源类型，是掌握故障注入与隔离验证的基础。

3.1 控制面与数据面交互模型

Envoy 采用“拉取（Pull）”与“推送（Push）”结合的异步交互模式。控制面（通常为 Istiod）作为 xDS 服务器，数据面（Envoy Sidecar）作为 xDS 客户端，通过 gRPC 流式订阅资源。

3.2 xDS 资源类型详解

xDS 协议定义了多种资源发现服务，每种服务对应 Envoy 配置的一个关键维度。在 Istio 环境中，最核心的四种类型为 LDS、RDS、CDS 和 EDS，它们共同构成了 Envoy 的动态配置体系。

3.3 动态配置更新机制

Envoy 的动态更新机制基于“版本号”与“资源版本”的对比。控制面维护一个全局配置版本，每次变更都会递增版本号。Envoy 通过比较本地版本与推送版本，决定是否应用新配置。

3.3.1 更新流程步骤

1. 资源变更检测：Istiod 监听 Kubernetes 资源（Service、Pod、VirtualService、DestinationRule 等）的变化。
2. 配置生成：Istiod 将 Kubernetes 资源翻译为 Envoy 可识别的 xDS 资源（如将 VirtualService 转为 RDS 路由条目）。
3. 版本递增：生成新快照，版本号 +1。
4. 推送：通过 gRPC 流将变更的资源（全量或增量）推送给所有订阅的 Envoy。
5. Envoy 校验与生效：Envoy 校验配置合法性，若通过则应用新配置并返回 ACK；若失败则返回 NACK 并保留旧配置。

3.3.2 全量推送 vs 增量推送

3.4 故障注入场景中的 xDS 操作

在 IDP 故障域隔离演练中，xDS 协议是实施故障注入的“指令通道”。通过修改 RDS 资源中的路由规则，可以精确控制流量行为。

# 原始 RDS 路由（正常）
routes:
- match: { prefix: "/api" }
  route: { cluster: "service-a" }

# 故障注入后的 RDS 路由（添加延迟）
routes:
- match: { prefix: "/api" }
  route:
    cluster: "service-a"
    timeout: 5s
  typed_per_filter_config:
    envoy.filters.http.fault:
      "@type": type.googleapis.com/envoy.extensions.filters.http.fault.v3.HTTPFault
      delay:
        fixed_delay: 3s
        percentage: { numerator: 100 }

3.5 关键监控指标

在演练过程中，应关注以下 xDS 相关指标，以评估控制面与数据面的健康状态：

• xDS 推送延迟：从资源变更到 Envoy 确认 ACK 的时间，理想值 < 1s。
• NACK 率：Envoy 拒绝配置更新的比例，持续升高表明配置错误或版本冲突。
• 配置版本差异：控制面最新版本与 Envoy 当前版本的差值，差值过大说明推送链路异常。
• gRPC 流断开次数：Envoy 与控制面之间的连接稳定性，频繁断开会导致配置滞后。