2. Istio 控制平面核心组件：Pilot、Citadel、Galley 的功能与数据流拓扑

在 Istio 1.5+ 架构中，控制平面组件被整合为单一的 istiod 二进制，但其内部仍然保留了三个核心逻辑模块：Pilot（服务发现与流量管理）、Citadel（安全与证书管理）和 Galley（配置验证与分发）。理解这三个模块的功能边界与数据流拓扑，是进行控制平面故障排查的基础。

2.1 三大核心组件功能对比

2.2 Pilot：服务发现与流量管理的枢纽

Pilot 是 Istio 控制平面中与数据面交互最频繁的组件。它负责将高层路由规则（VirtualService、DestinationRule）和服务注册信息（Kubernetes Service、Endpoint、ServiceEntry）转换为 Envoy 可以理解的 xDS 协议配置。

• 服务发现（Service Discovery）： 监听 Kubernetes API Server 中的 Service、EndpointSlice、Pod 变化，同时支持通过 ServiceEntry 和 WorkloadEntry 注册外部服务或虚拟机工作负载。
• 流量规则转换（Traffic Rule Translation）： 将 VirtualService 中的路由匹配、权重分发、故障注入等语义，以及 DestinationRule 中的负载均衡策略、连接池设置、熔断阈值，翻译为 Envoy 的 Cluster、Listener、Route 配置。
• xDS 协议推送： 作为 xDS（LDS、RDS、CDS、EDS、SDS）的服务端，通过 gRPC 流与每个 Envoy 代理维持长连接，在配置变更时增量推送，在连接重建时全量推送。

2.3 Citadel：安全身份与证书管理

Citadel 是 Istio 安全体系的基石，负责管理网格内所有工作负载的身份和证书。它实现了 SPIFFE（Secure Production Identity Framework for Everyone）标准，为每个工作负载颁发符合 SPIFFE 格式的身份证书。

• CA 服务： Citadel 内置自签名 CA（Certificate Authority），也可以集成外部 CA（如 cert-manager、Vault）。它维护根证书和中间证书，用于签发工作负载证书。
• 证书签发流程： Envoy 代理通过 SDS（Secret Discovery Service）向 Citadel 发起 CSR（Certificate Signing Request），Citadel 验证请求中的 ServiceAccount 身份后，签发有效期为 24 小时（默认）的工作负载证书。
• 证书轮换： Citadel 自动管理证书轮换，在证书过期前重新签发。Envoy 通过 SDS 流实时获取更新后的证书，无需重启 Pod。

2.4 Galley：配置验证与状态聚合

Galley 在 Istio 控制平面中扮演“配置网关”的角色。它负责验证用户提交的 Istio 配置的合法性，并将验证后的配置模型分发给 Pilot 和其他组件。

• 配置验证（Configuration Validation）： Galley 实现了 Kubernetes 的准入 Webhook（ValidatingAdmissionWebhook），在用户创建或更新 Istio CRD（如 VirtualService、DestinationRule）时进行语义校验。如果配置无效，Galley 会直接拒绝该请求并返回错误信息。
• 配置转换与分发： Galley 将 Kubernetes 原生资源和 Istio CRD 统一转换为内部配置模型，并通过 MCP（Mesh Configuration Protocol）协议推送给 Pilot。MCP 协议支持增量更新，减少全量同步的开销。
• 状态聚合： Galley 收集各组件（Pilot、Citadel、Ingress/Egress Gateway）的健康状态和版本信息，并通过 istioctl proxy-status 命令对外暴露，方便运维人员查看网格整体健康度。

2.5 控制平面数据流拓扑

下图展示了用户配置、Kubernetes API Server、Galley、Pilot、Citadel 与数据面 Envoy 之间的完整数据流拓扑。理解这个拓扑是定位配置下发失败、证书错误和策略不生效等问题的前提。

2.6 配置下发与证书签发流程详解

为了更清晰地展示 Pilot 和 Citadel 的内部处理流程，下面分别给出配置下发和证书签发的详细步骤。

2.6.1 Pilot 配置下发流程

1. 监听变更： Pilot 通过 Informer 监听 Kubernetes API Server 中的 Service、EndpointSlice、Pod、VirtualService、DestinationRule、ServiceEntry 等资源的变化。
2. 生成内部模型： Pilot 将监听到的 Kubernetes 原生资源和 Istio CRD 转换为统一的内部配置模型（ServiceRegistry、ConfigStore）。
3. 计算 xDS 配置： Pilot 根据内部模型，为每个 Envoy 代理计算专属的 Listener、Route、Cluster、Endpoint 配置。这一步会考虑 Sidecar 资源定义的流量劫持范围。
4. 增量推送： Pilot 通过 gRPC 流将变更的 xDS 配置推送给对应的 Envoy。Envoy 收到配置后，进行热更新，不中断现有连接。
5. 全量推送（兜底）： 当 Envoy 与 Pilot 的连接断开后重建时，Pilot 会进行全量推送，确保 Envoy 获得完整的配置状态。

2.6.2 Citadel 证书签发流程

1. Envoy 启动： Envoy 代理启动时，通过 SDS 协议向 Citadel 发起 CSR 请求，请求中包含 Pod 的 ServiceAccount 信息。
2. 身份验证： Citadel 通过 Kubernetes API Server 验证请求中的 ServiceAccount 是否存在，以及该 ServiceAccount 是否与请求中的 Pod 绑定。
3. 证书签发： 验证通过后，Citadel 使用 CA 根证书为工作负载签发 SPIFFE 格式的证书，证书的 SAN（Subject Alternative Name）为 spiffe://cluster.local/ns/<namespace>/sa/<service-account>。
4. 证书下发： Citadel 通过 SDS 流将证书和私钥下发给 Envoy。Envoy 将证书加载到内存中，用于后续的 mTLS 握手。
5. 证书轮换： Citadel 在证书过期前（默认 24 小时）自动触发轮换，重新签发证书并通过 SDS 流推送，Envoy 热更新证书。

2.7 组件间通信协议总结