【Istio 控制面】istiod 进程模型：discovery、config、CA 与注入的边界
内容提要
istiod 是集 discovery、config、CA、injection 于一体的单一二进制，但各组件独立运行。启动顺序有硬依赖：CA 先于证书，证书先于安全 gRPC 和 webhook。xDS 推送热路径仅含 pushChannel 和 Generator，CA 签发、注入等不在此列。多副本中 xDS 无主，但状态写回控制器需选主。
延伸解读
排障先分组件，别按进程一刀切
istiod 虽是单一进程，但 discovery、CA、注入、校验是独立组件，各自有独立的失败模式。CA 或注入 webhook 故障通常不影响 xDS 推送，反之亦然。排障时应先定位是哪个组件的问题，再针对性查看日志，避免在错误的方向上浪费时间。
启动顺序的硬依赖：CA 先行
istiod 启动顺序有硬依赖：CA 必须先于 istiod 自身证书，证书先于安全 gRPC 和 webhook HTTPS 服务。这意味着 CA 初始化失败会导致整个 istiod 启动失败。理解这一依赖链有助于快速判断启动失败的可能原因，并合理配置健康检查与依赖。
xDS 推送无主，状态写回需选主
多副本 istiod 中，xDS 推送无需选主，每个副本独立服务连到自己的代理。但写回 K8s API 的控制器（如 GatewayStatusController）必须选主，避免重复写和状态抖动。这一区分有助于理解多副本行为，以及为何某些组件异常只影响部分副本。
Q&A
istiod 是一个二进制，但内部组件是如何组织的？
istiod 实际运行的可执行文件是 pilot-discovery，它内部使用一个通用的组件运行器 server.Instance，将 discovery、CA、注入、校验等功能注册为独立的 Component，每个组件独立运行，通过统一的机制管理启动和停止。
istiod 启动时各组件的顺序是怎样的？为什么 CA 必须先于安全 gRPC 服务？
启动顺序为：先创建 CA（maybeCreateCA），然后初始化配置控制器（initControllers）和生成器（InitGenerators），接着生成 istiod 自身证书（initIstiodCerts），之后才初始化安全 gRPC 服务（initSecureDiscoveryService）和 webhook HTTPS 服务（initSecureWebhookServer）。因为 istiod 自身的安全 gRPC 和 webhook 服务可能使用由 CA 签发的证书，所以 CA 必须先于这些服务创建。
xDS 推送热路径包含哪些组件？CA 和注入 webhook 在热路径上吗？
xDS 推送热路径仅包含 pushChannel、debounce、PushQueue 和 XdsResourceGenerator。CA 证书签发、注入 webhook 和配置校验 webhook 都不在热路径上，它们只在特定事件（如代理首次连接、Pod 创建、资源写入）时触发，与每次配置推送无关。
多副本 istiod 中，哪些组件需要选主？为什么？
需要选主的组件包括 NamespaceController、GatewayStatusController、StatusController、IngressController、GatewayDeploymentController 等，它们需要将状态写回 Kubernetes API。如果不选主，多个副本会重复写导致冲突或状态抖动。而 xDS 推送本身不需要选主，每个副本独立服务连接到自己的代理。
如果 CA 证书轮转出现问题，是否会影响 xDS 推送？排障时应该怎么做？
CA 证书轮转问题通常不会影响 xDS 推送，因为 CA 签发不在 xDS 推送热路径上。排障时应按组件定位问题：如果代理连接建立失败，才需要检查安全 gRPC 服务的证书链；如果 xDS 推送延迟增大，应优先检查 PushQueue 和 pushChannel，而不是证书或 webhook。
istiod 中 Config 组件的作用是什么？它是否直接对外提供 gRPC 服务？
Config 组件负责配置摄取与翻译，包括 ConfigStore 和 ServiceDiscovery 两条聚合管线，最终生成 PushContext 快照，作为 Discovery 的输入。它不直接对外提供 gRPC 服务，而是通过 DiscoveryServer 对外提供 xDS 服务。
