2. Istio 架构基础：控制平面与数据平面

在深入集群升级治理之前，必须透彻理解 Istio 的架构基石。Istio 采用经典的控制平面/数据平面分离架构，这种设计直接决定了升级策略、流量管理粒度以及故障隔离边界。本章将拆解核心组件 Pilot、Mixer、Citadel、Galley 的职责，分析数据平面 Envoy 代理的工作机制，并详细说明 Sidecar 注入的完整流程。

2.1 控制平面组件详解

控制平面负责统一管理服务网格的配置、安全、策略和可观测性。在 Istio 1.5+ 版本中，传统组件被整合为单一的 istiod 二进制，但内部逻辑仍保持模块化设计。下表梳理了各组件的核心职责与升级影响：

下图展示了控制平面各组件之间的数据流与依赖关系：

2.2 数据平面：Envoy 代理

Envoy 是 Istio 数据平面的核心，以 Sidecar 模式注入到每个 Pod 中。它负责拦截所有进出容器的流量，并执行控制平面下发的路由、安全、可观测性策略。Envoy 的关键能力包括：

• L4/L7 流量拦截： 通过 iptables 规则透明劫持入站和出站流量，无需修改应用代码。
• 动态配置（xDS）： 通过 Aggregated Discovery Service (ADS) 从 Pilot 拉取监听器（LDS）、路由（RDS）、集群（CDS）、端点（EDS）等配置。
• mTLS 终止： 与 Citadel 协作，自动为服务间通信启用双向 TLS 加密，证书轮换由 Envoy SDS 实现。
• 可观测性： 生成详细的访问日志、分布式追踪（Jaeger/Zipkin）和 Prometheus 指标。

2.3 Sidecar 注入原理

Sidecar 注入是 Istio 将 Envoy 代理自动附加到应用 Pod 的机制。注入方式分为手动注入和自动注入（基于 MutatingWebhook）。理解注入流程对于排查升级后 Pod 启动失败问题至关重要。

自动注入的完整流程如下：

1. Pod 创建请求： 用户通过 Deployment/StatefulSet 创建 Pod，API Server 收到请求。
2. Webhook 拦截： 如果命名空间带有 istio-injection=enabled 标签，API Server 调用 Istio 的 MutatingWebhookConfiguration。
3. 注入请求处理： istiod 中的 Sidecar Injector 组件解析 Pod 模板，生成 Envoy 容器配置和 init 容器配置。
4. 修改 Pod 定义： 在 Pod 的 spec 中添加：
   • init 容器： istio-init，负责设置 iptables 规则，将流量重定向到 Envoy。
   • Sidecar 容器： istio-proxy，运行 Envoy 代理。
   • 卷挂载： 注入服务账户令牌、证书、istio 配置等。
5. 返回修改后的 Pod： API Server 使用修改后的 Pod 定义创建 Pod。

下表对比了手动注入与自动注入的适用场景：

下图展示了 Sidecar 自动注入的完整调用链：

2.4 架构升级要点总结

基于上述架构分析，在集群升级治理中需要重点关注以下方面：

• 控制平面升级顺序： 先升级 istiod（包含 Pilot、Citadel、Galley 功能），再升级数据平面 Envoy。
• Mixer 迁移： 如果使用 Mixer 策略，需在升级前迁移至 Envoy 原生扩展或 Istio Telemetry API。
• Sidecar 注入验证： 升级后使用 istioctl proxy-status 检查所有 Sidecar 是否与控制平面正常通信。
• 证书兼容性： Citadel 升级可能导致 CA 根证书变更，需确保旧证书在轮换期内仍然有效。