istiod 是集 discovery、config、CA、injection 于一体的单一二进制，但各组件独立运行。启动顺序有硬依赖：CA 先于证书，证书先于安全 gRPC 和 webhook。xDS 推送热路径仅含 pushChannel 和 Generator，CA 签发、注入等不在此列。多副本中 xDS 无主，但状态写回控制器需选主。

本文介绍Istio控制面中K8s Service、EndpointSlice和WorkloadEntry如何转换为Envoy的CDS/EDS资源。核心是服务注册聚合层将三种来源统一为model.Service和model.IstioEndpoint，CDS按“Service×端口”生成Cluster，EDS按hostname索引端点。两者通过service_name字符串对齐，WorkloadEntry需特殊开关接入，健康状态无kubelet兜底。

本文是“Istio/网格控制面内核”系列首篇，旨在填补Envoy消费侧与Mesh选型之间的缺口，聚焦istiod如何将CRD或Gateway API资源编译为xDS资源图并推送。文章梳理了xDS从协议到控制面产品的三次分叉，提出五条坐标系（资源来源、订阅身份、推送图、一致性、作用域），并明确系列16篇的边界与不涉及内容。

本文分析Istio控制面istiod对Envoy NACK的处理机制：istiod仅记录错误并计数，不重试或回滚；通过PushOrder常量实现CDS→EDS→LDS→RDS的推送顺序，但只保证同批发送顺序；istiod可观测性止步于协议层，warming等Envoy内部状态无法感知，排障需结合控制面与数据面信号。

本文探讨Istio Ambient模式下控制面istiod如何区分并服务ztunnel与waypoint两类代理。ztunnel按节点部署，仅处理L4，订阅地址与授权资源；waypoint是标准Envoy，按挂载关系订阅资源。当前ambient代理跳过sidecar的作用域过滤优化，源码留有TODO，是大规模部署的已知差距。

本文介绍Istio控制面系列，聚焦istiod如何将CRD/HTTPRoute编译为xDS图并推送。涵盖istiod进程模型、代理身份订阅、翻译层（Service、VirtualService等）、生产侧SotW/Delta、NACK/warming责任、多集群及Ambient对比。提供16篇目录和阅读路径，面向平台工程师，帮助从“能apply”推进到“能归因推送”，并明确不涉及Envoy内核或选型税文。

本文档描述了 Istio 控制平面——Istiod 的高层架构。Istiod 是一个模块化的单体应用，涵盖了从证书签名、代理配置（XDS）、传统的 Kubernetes 控制器等多种功能。 代理配置 Istiod 的主要角色——以及大部分代码——是动态配置代理（Envoy sidecar、入口、gRPC、ztunnel 等）。这大致包括 3...