2. Istio 架构核心回顾：控制平面与数据平面

在深入 Sidecar 升级与集群治理联动之前，必须重新梳理 Istio 的架构基石。Istio 采用经典的控制平面/数据平面分离架构，理解每个组件的职责边界，是后续操作 Sidecar 注入、版本管理、流量治理的前提。

核心认知： 控制平面负责“决策”，数据平面负责“执行”。Sidecar 升级本质上是数据平面组件的版本替换，但必须与控制平面的兼容性、配置推送机制协同工作。

2.1 架构总览：控制平面与数据平面

下图展示了 Istio 1.5+ 之后的架构简化模型（移除了 Mixer，功能下沉至 Envoy 和控制平面组件）。

Istio 控制平面与数据平面架构 Istio 控制平面与数据平面架构 控制平面 (istiod) Pilot 服务发现 + 配置下发 Citadel 证书签发 + mTLS Galley 配置验证 + 转换 数据平面 (Sidecar Proxy) Pod A App 容器 Envoy Sidecar Pod B App 容器 Envoy Sidecar 注：Mixer 在 Istio 1.5+ 中已移除，其策略/遥测能力下沉至 Envoy 和 istiod 组件
架构演进提示： Istio 1.5 之后将 Pilot、Citadel、Galley 合并为单一的 istiod 进程，但逻辑职责仍然分离。理解每个组件的原始职责，有助于排查升级过程中的配置兼容性问题。

2.2 核心组件职责详解

组件 职责 与 Sidecar 升级的关联
Pilot 服务发现、流量管理规则（VirtualService/DestinationRule）的转换与下发，通过 xDS 协议推送至 Envoy Sidecar 版本升级后，Pilot 必须能生成该版本 Envoy 可理解的 xDS 配置；低版本 Pilot 可能无法推送高版本 Envoy 的新特性配置
Citadel 证书签发与管理，负责 mTLS 身份认证，通过 SDS（Secret Discovery Service）向 Envoy 下发证书 Sidecar 升级时证书轮换机制不能中断；Citadel 版本需兼容 Envoy 的 SDS 协议版本
Galley 配置验证、转换与分发，作为控制平面的配置入口，负责校验 CRD 合法性 升级过程中 Galley 的配置校验逻辑可能影响新版本 CRD 的生效；Galley 版本需与 Pilot 版本匹配
Mixer（已移除） 原负责策略检查与遥测报告，Istio 1.5+ 后功能内联至 Envoy 和 istiod 升级时需确认旧版 Mixer 配置已迁移至 EnvoyFilter 或 Telemetry API，否则策略可能失效

2.3 Envoy Sidecar 注入原理

Sidecar 注入是 Istio 将 Envoy 代理自动附加到 Pod 的机制。理解注入原理，是后续实现“无感升级”和“灰度注入”的基础。

2.3.1 注入方式对比

注入方式 触发时机 原理 适用场景
自动注入 Pod 创建时 通过 MutatingWebhookConfiguration 拦截 Pod 创建请求，由 istiod 的 Sidecar Injector 组件修改 Pod Spec，注入 initContainers（iptables 规则）和 sidecar 容器（Envoy） 生产环境默认方式，适合大规模集群
手动注入 通过 istioctl 命令 使用 istioctl kube-inject 命令修改 YAML 文件，在部署前完成注入 CI/CD 流程中预注入、调试、离线环境

2.3.2 自动注入的完整流程

  1. Webhook 拦截： Kubernetes API Server 收到 Pod 创建请求，根据 namespace 标签 istio-injection=enabled 或 sidecar.istio.io/inject: "true" 注解，调用 istiod 的 MutatingWebhook。
  2. 注入决策： istiod 检查 Pod 是否满足注入条件（排除 kube-system、已有 Sidecar 等），读取注入模板和用户自定义配置。
  3. Pod Spec 修改： istiod 在 Pod Spec 中插入：
    • initContainers[0]（istio-init）： 设置 iptables 规则，将 Pod 的入站/出站流量劫持到 Envoy。
    • containers[0]（istio-proxy）： 运行 Envoy 代理，通过 --configPath 和 --discoveryAddress 连接控制平面。
    • volumes： 挂载 istio-ca-root-cert、istio- 等证书和令牌卷。
  4. 返回修改后的 Pod Spec： API Server 使用修改后的 Spec 创建 Pod。
升级风险点： 自动注入依赖 istiod 的 Sidecar Injector 组件。当控制平面升级时，注入模板（sidecar-injector-configmap）可能发生变化，导致新创建的 Pod 使用新版本 Envoy 镜像，而存量 Pod 仍为旧版本。这是 Sidecar 版本不一致的主要来源，也是本课程要解决的核心问题。

2.3.3 注入后的 Pod 内部结构

注入完成后，Pod 内部包含以下关键容器和网络配置：

# 注入后的 Pod 结构示意
Pod: productpage-v1-xxxxx
├── initContainers:
│   └── istio-init          # 设置 iptables 规则，完成流量劫持
├── containers:
│   ├── productpage         # 业务容器（原始应用）
│   └── istio-proxy         # Envoy Sidecar 代理
│       ├── 监听端口: 15000 (管理接口)
│       ├── 监听端口: 15001 (出站流量)
│       ├── 监听端口: 15006 (入站流量)
│       └── 连接: istiod:15010 (xDS 配置下发)
└── volumes:
    ├── istio-ca-root-cert  # CA 根证书
    ├── istio-         # ServiceAccount 令牌
    └── istio-envoy         # Envoy 配置和运行时数据

2.4 组件交互流程（Sidecar 视角）

下图展示了 Sidecar 启动后与控制平面的交互过程，这是理解升级过程中“配置中断”风险的关键。

Sidecar 与控制平面交互流程 Sidecar 启动与控制平面交互流程 1. Envoy Sidecar 启动 2. 请求 xDS 配置 3. 请求 SDS 证书 4. 监听配置更新 5. 处理业务流量 6. 上报遥测数据 交互说明 • 步骤 2-3：Envoy 通过 gRPC 流式连接 istiod，订阅 LDS/RDS/CDS/EDS 和 SDS 资源 • 步骤 4：控制平面推送配置变更时，Envoy 热重载，无需重启 Pod • 步骤 6：Envoy 通过 Wasm 或 Stats 插件上报指标，用于可观测性
升级关键洞察： 步骤 2 和 3 中，Envoy 与 istiod 之间的 xDS/SDS 协议版本必须兼容。Istio 1.8+ 引入了 xDS 传输协议版本协商机制，但跨大版本升级（如 1.7 → 1.10）仍可能出现协议不兼容，导致 Sidecar 无法获取配置。这是本课程“Sidecar 升级”章节要重点解决的兼容性验证问题。

2.5 核心概念总结表

概念 定义 升级影响维度
控制平面 istiod（Pilot + Citadel + Galley），负责配置管理和证书签发 控制平面版本决定 Sidecar 可用的 API 和协议版本
数据平面 Envoy Sidecar 代理，负责实际流量转发和策略执行 Sidecar 版本决定数据面能力和安全补丁级别
Sidecar 注入 通过 Webhook 或手动方式将 Envoy 容器注入 Pod 注入模板决定新 Pod 使用的 Envoy 镜像版本
xDS 协议 Envoy 与控制平面之间的配置发现协议（LDS/RDS/CDS/EDS） 跨版本 xDS 兼容性是升级成功的关键
SDS Secret Discovery Service，Envoy 从 Citadel 获取证书 证书轮换机制在升级期间不能中断
← 上一章 📖 返回目录 下一章 →