【Istio 控制面】控制面全景：从 CRD 到 xDS 的翻译与推送内核
内容提要
本文是“Istio/网格控制面内核”系列首篇，旨在填补Envoy消费侧与Mesh选型之间的缺口，聚焦istiod如何将CRD或Gateway API资源编译为xDS资源图并推送。文章梳理了xDS从协议到控制面产品的三次分叉，提出五条坐标系（资源来源、订阅身份、推送图、一致性、作用域），并明确系列16篇的边界与不涉及内容。
延伸解读
为何需要“控制面内核”视角
文章指出，站内已有内容分别覆盖了 Envoy 消费侧、Mesh 选型、Gateway API 资源模型，但缺少“istiod 如何将 CRD 或 Gateway API 资源编译成 xDS 并推送”的中间环节。这种视角缺失可能导致读者对配置变更的完整生命周期理解不完整，尤其是从 kubectl apply 到流量真正生效之间的过程。理解控制面内核有助于更准确地定位问题，避免将“已推送”“已 ACK”“已生效”混为一谈。
xDS 演化的三次分叉：传输与类型解耦
文章梳理了 xDS 从协议到控制面产品的三次分叉：从多流到 ADS 单流、从多组件到 istiod 单进程、从通用类型到 ztunnel 自定义类型。这三次分叉表明“传输协议”和“资源类型”是两个独立演化的维度。理解这一点有助于区分不同控制面设计背后的工程权衡，例如 ADS 解决排序问题，istiod 合并解决运维复杂度，ztunnel 自定义类型解决资源效率。
五条坐标系：理解控制面的共用语言
文章提出五条坐标系：资源来源、订阅身份、推送图、一致性、作用域。这些坐标系为后续 15 篇提供了统一的讨论框架。例如，一致性轴强调“控制面已推送”“代理已 ACK”“流量已生效”是三个独立事件，排障时不可混为一谈；作用域轴则关系到 Sidecar、Telemetry 等资源如何影响推送范围，算错可能导致推送风暴或漏推。掌握这些坐标系有助于系统化理解控制面行为。
Q&A
Istio 控制面中，istiod 的核心职责是什么？
istiod 的核心职责是将 Kubernetes 中的 CRD 或 Gateway API 资源编译成具体的 xDS 资源图，并推送给相应的代理（如 Envoy）。它负责配置的接收、翻译和推送，是控制面的核心组件。
xDS 从协议到控制面产品经历了哪三次分叉？
三次分叉分别是：1. 从多流到单流可排序（ADS），解决了多流模式下每个 cluster 单独开流导致的扩展性问题；2. 从五个微服务到一个进程（istiod），合并了 Pilot、Galley、Citadel 和注入 webhook，降低了运维复杂度；3. 从通用 xDS 类型到领域特化协议（ztunnel），为 Ambient 模式设计了自定义的 Address 和 Authorization 类型，提高了资源效率。
istiod 如何识别不同类型的代理（如 sidecar、ztunnel）？
istiod 通过解析代理连接时提供的节点 ID（type~ip~id~domain 四段式）和 NodeMetadata，得到一个 model.Proxy 对象，其 Type 字段标识代理类型，包括 SidecarProxy、Router、Waypoint、Ztunnel、Agentgateway。不同类型的代理订阅不同的 xDS 资源集合。
在 Istio 中，控制面已推送、代理已 ACK、流量已生效这三个事件有什么区别？
这三个事件是独立的：控制面已推送（AdsPushAll）只表示 istiod 已经尝试发送配置；代理已 ACK 表示 Envoy 协议校验通过并打算应用；流量已生效则取决于 Envoy 的 warming 状态机，真正切换流量。排障时不能混为一谈，否则容易误判。
本系列文章明确不涉及哪些内容？
本系列不涉及：CA 证书签发与轮转的运维手册、VirtualService/DestinationRule 字段级配置菜谱、Gateway API CRD 教程、Istio vs Linkerd 谁更好的产品排名、Wasm/EnvoyFilter 编程 SDK，以及未实测的推送延迟或吞吐数字。
为什么 ztunnel 不使用 Envoy 的通用 xDS 类型，而是自定义了 Address 和 Authorization 类型？
因为使用 Envoy 通用类型表达一条 mTLS 语义需要几十行 Protobuf，而 ztunnel 使用带 Istio 语义的字段（如 ExpectedTLSIdentity）可以将信息压缩到十分之一体积与 CPU 开销，提高了资源效率。
