Istio / 网格控制面内核：从 CRD 到 xDS
内容提要
本文介绍Istio控制面系列，聚焦istiod如何将CRD/HTTPRoute编译为xDS图并推送。涵盖istiod进程模型、代理身份订阅、翻译层（Service、VirtualService等）、生产侧SotW/Delta、NACK/warming责任、多集群及Ambient对比。提供16篇目录和阅读路径，面向平台工程师，帮助从“能apply”推进到“能归因推送”，并明确不涉及Envoy内核或选型税文。
延伸解读
控制面推送不等于数据面生效
文章强调，即使控制面已推送xDS配置，Envoy也可能因warming未完成或NACK而未能生效。这提醒读者在排查问题时，不能仅看控制面日志，还需结合数据面状态，如config_dump和ACK/NACK信息，才能准确归因故障。
不同代理的xDS订阅差异
sidecar、ztunnel、waypoint和Gateway作为xDS客户端，订阅的资源类型和触发条件各不相同。理解这些差异有助于针对不同代理类型进行精准排障，例如ztunnel使用自定义资源，而waypoint虽为Envoy但推送逻辑不同。
翻译层的合并顺序与冲突
VirtualService与Gateway API HTTPRoute在编译为RDS时可能产生冲突，合并顺序一个确定、一个未定义。这提示使用双轨API时需注意潜在的路由冲突，并理解istiod内部模型如何统一处理，以避免意外行为。
Q&A
istiod 如何将 CRD 和 HTTPRoute 编译成 xDS 配置并推送给代理？
istiod 通过 watch 机制监听 Kubernetes 中的 CRD 和 HTTPRoute 资源，将其转换为内部 model，然后由 XdsServer 通过 ADS 协议编译成 LDS/RDS/CDS/EDS/SDS 等 xDS 配置，并推送给订阅的代理。
istiod 进程包含哪些主要组件，它们各自负责什么？
istiod 进程包含 discovery、config、CA 和 injection 四个主要职责。discovery 负责 xDS 推送，config 负责配置管理，CA 负责证书签发，injection 负责 sidecar 注入。其中 CA 先于 Discovery 初始化，注入 Webhook 与配置校验是独立的 HTTPS 服务。
sidecar、ztunnel 和 waypoint 作为 xDS 客户端有什么不同？
sidecar 和 Router 订阅标准的 LDS/RDS/CDS/EDS；ztunnel 订阅自定义的 Address 和 Authorization 资源；waypoint 虽然是 Envoy，但推送触发条件不同。
VirtualService 和 Gateway API HTTPRoute 如何被编译成 RDS？
istiod 的 RdsGenerator 将 VirtualService 和 Gateway API HTTPRoute（包括 GAMMA mesh 模式）编译成同一份内部路由模型，然后生成 RDS。双轨输入在同一 host 上可能产生冲突，合并顺序一个确定、一个未定义。
在 Istio 中，NACK 和 warming 的责任如何划分？
NACK 和 warming 的责任涉及 CDS→EDS→LDS→RDS 的推送顺序，以及 Envoy 消费侧的 ACK 和 warming 机制。istiod 负责推送，但配置是否生效取决于 Envoy 的 warming 过程，NACK 可能由 istiod 或 Envoy 引起，需要结合 Envoy 消费侧进行排障。
多集群环境下，istiod 如何实现 east-west 发现扇出？
多集群环境下，istiod 通过 east-west 发现扇出机制，将集群间的服务发现信息进行同步和推送，确保跨集群的流量能够正确路由。
Ambient 模式中 ztunnel 和 waypoint 的故障域边界有何不同？
在 Ambient 模式中，ztunnel 处理 L4 流量，waypoint 处理 L7 流量，它们作为不同的 xDS 客户端，故障域边界不同。ztunnel 的故障影响 L4 连接，waypoint 的故障影响 L7 路由。
如何排查 Istio 控制面推送问题？
可以使用 istioctl proxy-config 命令查看代理的 xDS 配置，并与 Envoy 的 config_dump 对齐，检查 ACK/NACK 状态和 warming 情况，从而定位问题是在翻译、推送还是数据面 warming。
