#在 ambient 模式下更新 Alauda Service Mesh

在 ambient 模式下，您通过就地提升每个 mesh 组件资源的版本来更新 Alauda Service Mesh。随后，Alauda Service Mesh v2 Operator 会将正在运行的组件替换为请求的版本。应用 Pod 会切换到升级后的 ZTunnel proxy，而无需重启或重新调度，这与 sidecar 模式形成了关键的运维差异；在 sidecar 模式下，每个工作负载都必须在获取新 proxy 版本之前重启。

#升级路径

下表包含 ambient 模式下 mesh 的完整升级路径。ambient 模式在 Alauda Service Mesh v2.1 中引入，因此路径从该版本开始。升级时，您需要按顺序升级 Operator 版本，并在进入下一步之前，将 mesh 组件更新到每一步对应的 Istio 版本。

#更新顺序

请按以下顺序更新 mesh 组件：

1. Istio control plane — 更改 Istio resource 中的版本。
2. Istio CNI — 将 IstioCNI resource 更改为相同版本。
3. ZTunnel — 将 ZTunnel resource 更改为相同版本。

顺序很重要，因为存在受支持的 version skew：1.x 版本的 Istio CNI plugin 和 ZTunnel proxy 可以与 1.x 或 1.x+1 版本的 control plane 配合工作，但不能与更旧的版本配合工作。先升级 control plane 可确保更新过程中出现的所有组件组合都保持在受支持的范围内。

有关逐步命令，请参见 Updating ambient mode components。

#更新期间的连接处理

在 ambient 模式下，是每个节点上的 ZTunnel proxy，而不是每个应用 Pod，持有到 istiod 的 xDS 连接。因此，control plane 更新不需要重启任何应用 Pod：ZTunnel 和 waypoint proxy 会自行重新连接到新的 control plane。

替换 ZTunnel pod 本身是唯一可能影响应用流量的步骤。由于 ZTunnel 在 Layer 4 代理 TCP 连接，因此它无法将已建立的连接交接给其后继实例，所以正在更新的节点上的长时间运行的 TCP 连接可能会被重置。要了解此行为及其缓解选项，请参见 The ZTunnel update process。

#版本兼容性

规划更新时，请遵循以下指导：

• 尽可能保持 Istio control plane、Istio CNI 和 ZTunnel 版本一致。
• data plane 组件绝不能领先于 control plane。请将 waypoint proxy、Istio CNI plugin 和 ZTunnel 保持在 control plane 一个 minor version 之内（相同版本或 n-1）。
• 在更新生产集群之前，请先在非生产环境中测试目标版本组合。

#高可用性

InPlace 更新会重启 control plane Pod，这可能会短暂中断 mesh 配置下发。此建议同样适用于 ambient 模式：请以多个副本运行 istiod，以尽量缩小中断窗口。有关详细信息，请参见 Istio High Availability。