【Envoy 数据面】xDS 资源树：LDS→RDS→CDS→EDS 的依赖、命名与顺序
内容提要
本文介绍Envoy xDS配置的资源树结构，核心为LDS→RDS→CDS→EDS（及SDS），通过名称引用形成依赖链。推送顺序至关重要，需遵循make-before-break原则：先CDS/EDS，再LDS，最后RDS，避免黑洞。Warming决定资源何时可用，ACK不等于依赖就绪。控制面需按序推送，确保数据面稳定切换。
延伸解读
命名即契约：字符串引用的隐患
xDS 资源之间通过字符串名称引用，而非强类型外键。这意味着控制面必须保证名称精确匹配，否则会出现 no_cluster 或 warming 未完成。例如，RDS 先指向新集群 Y，而 CDS/EDS 尚无 Y，就会导致请求黑洞。此外，SotW 下非 LDS/CDS 类型的删除常靠父资源不再引用间接发生，空响应语义因类型而异，不能简单假设发空 EDS 即清空。
Warming 与 ACK 的语义差异
ACK 仅表示资源本身合法且意图应用，并不代表依赖树已全部就绪。例如，Cluster warming 需要管理服务器提供对应的 ClusterLoadAssignment，即使 endpoints 无变化，Envoy 仍期望新的 EDS 响应。Listener warming 若引用 RDS，需有可用的 RouteConfiguration。因此，控制面日志中的“已推送”不等于 Worker 上 Listener 已开始接流量，排障时需区分“依赖未齐”与“资源已就绪但被限额拒绝”。
make-before-break 的实践顺序
为避免黑洞，推荐推送顺序为：先 CDS（新集群），再 EDS（对应端点），然后 LDS（新监听器），最后 RDS（切换路由），之后才删除旧资源。反向操作（先改 RDS 再补集群）是联调事故的高频原因。ADS 聚合流便于控制面显式排序，而分类型多流则依赖控制面纪律，因为只有最终一致性。
Q&A
Envoy xDS 配置中，LDS、RDS、CDS、EDS 之间是如何通过名称引用形成依赖链的？
Envoy 的 xDS 配置中，Listener（LDS）通过 HTTP 连接管理器中的 RDS 配置和路由配置名称引用 RouteConfiguration（RDS）；RouteConfiguration 中的路由通过 cluster 名称引用 Cluster（CDS）；Cluster 通过 EDS 配置中的 service_name（或默认 cluster 名）引用 ClusterLoadAssignment（EDS）。此外，Listener 和 Cluster 的 TLS 传输套接字可以引用 SDS 中的 Secret。这样，通过名称引用形成 LDS→RDS→CDS→EDS（及 SDS）的依赖链。
为什么 Envoy xDS 推送顺序很重要？正确的推送顺序是什么？
推送顺序很重要，因为 xDS 是最终一致的，如果顺序错误，可能导致数据面短暂黑洞或仍走旧路由。正确的推送顺序遵循 make-before-break 原则：先推送 CDS（若有新集群），再推送对应的 EDS，然后推送 LDS（新 Listener 依赖的上游已在），再推送与这些 Listener 相关的 RDS，如有 VHDS 则在 RDS 之后，最后删除不再被引用的旧 CDS/EDS。
在 Envoy 中，ACK 是否意味着资源已经生效并可以服务流量？
不是。ACK 仅表示客户端孤立地认为这些资源合法、意图应用，但不等于依赖树已全部 warming 完毕，也不等于流量已切到新路由。Warming 决定资源何时可用，例如 Cluster warming 需要管理服务器提供对应的 ClusterLoadAssignment，Listener warming 需要可用的 RouteConfiguration。因此，控制面日志中的“已推送”不等于 Worker 上该 Listener 已开始接流量。
如果 RDS 先指向新集群 Y，而 CDS/EDS 尚未引入 Y，会发生什么？
如果 RDS 先指向新集群 Y，而 CDS/EDS 尚未引入 Y，请求会因找不到集群而出现 no_cluster 错误，或者因 warming 未完成导致监听未上线，从而造成黑洞，直到 Y 可知。
Envoy 中 SDS 在资源树中扮演什么角色？它如何影响 warming？
SDS 提供证书和校验材料，挂在 Listener 或 Cluster 的 TLS 传输套接字上。SDS 不改变 LDS→EDS 的逻辑边，但常成为 warming 阻塞点：如果 Listener 或 Cluster 的 TLS socket 引用了尚未下发的 secret，表现是“证书相关资源未就绪”，而不是路由表错误。
在 Envoy 中，静态配置和动态配置如何结合？是否允许仅 EDS 动态？
Envoy 允许从全静态逐步增加动态层，例如仅 EDS 动态是合法部署。官方 xDS configuration API overview 允许从全静态逐步加 EDS→CDS→RDS→LDS。每多一层动态，就多一条 warming 边和一种顺序约束。
Envoy 中，如果请求了不存在的 RDS/EDS 资源，客户端会如何处理？
客户端会使用超时（文档建议约 15 秒）视为不存在，同时必须准备资源稍后出现时再推送。
