2. Istio 架构回顾：控制面与数据面组件在升级中的角色
在深入准入控制策略之前，必须清晰理解 Istio 控制面与数据面各组件的职责，以及它们在网格升级过程中各自扮演的角色。升级故障往往源于组件间版本不匹配、证书轮换中断或配置推送失败。
2.1 整体架构概览
Istio 采用经典的控制面/数据面分离架构。数据面由 Sidecar 代理（Envoy）组成，负责拦截并处理网格内所有进出流量；控制面则统一管理代理的配置分发、安全策略与遥测采集。
2.2 数据面核心：Envoy 代理
Envoy 是 Istio 数据面的唯一代理组件，以 Sidecar 模式注入到每个 Pod 中。它负责所有进出容器的流量拦截、负载均衡、熔断、重试以及遥测数据采集。
| Envoy 能力 | 升级影响 | 故障排查要点 |
|---|---|---|
| 动态配置热加载 | 新版本可能变更 xDS API 版本 | 检查 Envoy 日志中的 xDS 拒绝消息 |
| TLS 证书轮换 | Citadel 升级期间证书签发可能中断 | 验证 mTLS 握手是否成功 |
| 访问日志格式 | 升级后日志字段可能新增或废弃 | 对比新旧日志格式差异 |
| 统计指标 | 指标名称或标签可能变化 | 确认监控面板数据是否正常 |
升级提示：Envoy 版本必须与 Pilot 版本保持大版本一致。例如 Istio 1.16 使用 Envoy 1.26，升级到 1.17 时 Envoy 会随 Sidecar 注入自动更新。手动升级 Sidecar 时，务必先升级控制面。
2.3 控制面组件详解
2.3.1 Pilot — 配置分发核心
Pilot 负责将用户定义的流量规则（VirtualService、DestinationRule）转换为 Envoy 可理解的 xDS 配置，并通过 gRPC 流推送到所有 Sidecar 代理。它是升级过程中最关键的组件。
- 升级角色：新版本 Pilot 必须向后兼容旧版 Envoy 的 xDS 协议版本。
- 常见故障：升级后 Envoy 无法连接 Pilot，或收到格式错误的配置更新。
- 排查命令：
istioctl proxy-status查看代理同步状态。
2.3.2 Mixer — 已废弃但需注意迁移
Mixer 在 Istio 1.5 之前负责策略检查和遥测报告。1.5+ 版本中 Mixer 已被移除，其功能合并到 Envoy 代理中。如果从旧版本（1.4 及以下）升级，必须先将 Mixer 策略迁移到 Envoy 原生扩展。
迁移警告：如果当前网格仍在使用 Mixer 适配器（如自定义日志、配额检查），升级到 1.5+ 前必须完成适配器迁移。否则升级后策略将失效，流量可能被拒绝。
2.3.3 Citadel — 证书与身份管理
Citadel 负责管理网格内的 TLS 证书签发与轮换。它通过 Kubernetes CSR API 为每个工作负载生成 SPIFFE 身份证书，并定期轮换。
| Citadel 功能 | 升级风险 | 验证方法 |
|---|---|---|
| 证书签发 | 升级期间新 Pod 可能无法获取证书 | 检查 Pod 内 /etc/certs/ 目录证书有效期 |
| 证书轮换 | 轮换周期可能因升级中断 | 查看 Citadel 日志中的签发错误 |
| 根证书更新 | 根证书变更会导致所有 mTLS 连接中断 | 确认新旧根证书是否同时受信 |
2.4 升级中各组件的依赖关系
升级顺序至关重要。错误的升级顺序会导致控制面与数据面版本不匹配，引发配置推送失败或流量中断。
2.5 升级故障快速定位表
| 故障现象 | 可能原因 | 涉及组件 | 快速排查命令 |
|---|---|---|---|
| Envoy 无法启动 | Pilot 版本不兼容 | Pilot, Envoy | istioctl proxy-status |
| mTLS 握手失败 | Citadel 证书签发中断 | Citadel, Envoy | istioctl authn tls-check |
| 流量策略不生效 | Pilot 配置推送延迟 | Pilot | istioctl experimental describe pod |
| Gateway 拒绝连接 | Gateway 版本与 Pilot 不匹配 | Gateway, Pilot | kubectl logs -n istio-system deployment/istio-ingressgateway |
核心原则：升级过程中，控制面组件（Pilot、Citadel）必须优先升级，数据面组件（Envoy、Gateway）随后升级。任何组件版本不一致都可能导致网格功能降级或中断。