4. Istio 升级流程概览：升级前检查、控制平面升级、数据平面升级、Sidecar 重启策略

Istio 升级并非单一操作，而是一个需要严格遵循阶段顺序的工程流程。根据官方推荐及生产环境最佳实践，升级过程可划分为四个核心阶段：升级前检查、控制平面升级、数据平面升级以及Sidecar 重启策略。每个阶段都有其特定的目标、风险点和验证手段。

4.1 升级流程全景图

下图展示了 Istio 升级的完整生命周期，从环境准备到 Sidecar 最终就绪，每个阶段都包含关键的检查点与决策点。

4.2 升级前检查（Pre-Upgrade Checklist）

升级前检查是避免升级失败或中断业务的第一道防线。此阶段的核心目标是确认当前环境是否满足新版本 Istio 的要求，并记录关键状态以便回滚。

4.3 控制平面升级（Control Plane Upgrade）

控制平面升级的核心是替换 istiod 组件并更新相关的 CRD 与 Webhook 配置。此阶段通常使用 istioctl upgrade 命令完成，但也可以采用金丝雀发布（Canary Upgrade）方式。

4.3.1 标准升级流程

1. 下载新版本 istioctl： 确保客户端版本与目标版本一致。
2. 执行升级预检： istioctl x precheck 确认无阻塞项。
3. 应用新 CRD： kubectl apply -f manifests/charts/base/crds
4. 升级控制平面： istioctl upgrade -f your-iop.yaml
5. 验证控制平面： 检查 istiod Pod 状态、Webhook 配置及注入端点。

4.3.2 金丝雀升级（Canary Upgrade）

对于生产环境，推荐使用金丝雀升级策略，即同时运行新旧两个版本的控制平面，逐步将流量切换到新版本。

# 安装新版本控制平面（使用新 revision）
istioctl install --set revision=canary -f new-profile.yaml

# 验证新控制平面就绪
kubectl get pods -n istio-system -l istio.io/rev=canary

# 将测试命名空间切换到新 revision
kubectl label ns test-ns istio-injection- istio.io/rev=canary

# 验证测试命名空间 Pod 注入正常后，再逐步切换生产命名空间

4.4 数据平面升级（Data Plane Upgrade）

数据平面升级即更新所有 Envoy Sidecar 代理。由于 Sidecar 是作为 init 容器和 sidecar 容器注入到业务 Pod 中的，因此升级数据平面本质上是重新创建所有注入过 Sidecar 的 Pod。

4.4.1 数据平面升级方式对比

4.4.2 验证数据平面升级成功

升级完成后，必须验证所有 Sidecar 的版本是否已更新，并且流量转发正常。

# 查看所有 Sidecar 的 Envoy 版本
kubectl exec <pod-name> -c istio-proxy -- pilot-agent request GET /server_info | grep "version"

# 批量检查命名空间内所有 Pod 的 Sidecar 版本
kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[?(@.name=="istio-proxy")].image}{"\n"}{end}'

4.5 Sidecar 重启策略（Sidecar Restart Strategy）

Sidecar 重启策略是数据平面升级的具体执行方案，也是本课程的核心关注点。选择正确的重启策略，可以在最小化业务影响的前提下，确保所有 Sidecar 都更新到新版本。

4.5.1 三种主流重启策略

• 策略一：滚动重启（Rolling Restart）
  • 原理：通过更新 Deployment 的 Pod 模板（如添加一个无关紧要的 annotation）触发滚动更新。
  • 优点：零停机，K8s 原生支持。
  • 缺点：需要修改 Deployment 对象，可能触发不必要的配置同步。
• 策略二：优雅排空重启（Graceful Drain Restart）
  • 原理：先通过 istioctl proxy-config 排空连接，再重启 Sidecar。
  • 优点：连接中断最小化，适合长连接服务。
  • 缺点：操作步骤较多，需要脚本化。
• 策略三：原地重启（In-Place Restart）
  • 原理：直接删除 Sidecar 容器，K8s 会自动重建。
  • 优点：快速，不修改 Pod 模板。
  • 缺点：可能导致短暂连接中断，不适合有状态服务。

4.5.2 重启策略选择矩阵

4.5.3 注入策略重置的触发时机

Sidecar 注入策略重置通常发生在以下两个关键节点：

1. 控制平面升级完成时： MutatingWebhookConfiguration 被更新，导致新创建的 Pod 使用新的注入策略。
2. Pod 重启时： 如果命名空间的注入标签被修改（例如从 istio-injection: enabled 变为 istio.io/rev: canary），重启后的 Pod 将使用新的 revision 进行注入。