#迁移概述

本文档介绍 Alauda Service Mesh v1（Mesh v1）与 Alauda Service Mesh v2（Mesh v2）之间的变化、迁移阶段以及本节中使用的约定。请在开始前阅读本文档。

#为什么要迁移

Mesh v1 基于上游 istio-operator 项目构建，该项目已不再维护。Alauda Container Platform 4.4 不再提供 Mesh v1，因此所有 Mesh v1 mesh 都必须在平台处于 4.2 或 4.3 时完成迁移。Mesh v2 基于 Sail Operator 构建，并跟踪当前的 Istio 版本。

#有哪些变化

Istio 资源（Gateway、VirtualService、DestinationRule、ServiceEntry、Sidecar、PeerAuthentication、Telemetry 以及其他资源）会原样复用。迁移改变的是为这些资源编程的控制平面，而不是资源本身。

#功能映射

#迁移阶段

迁移分为七个阶段。每个阶段结束时都必须通过检查，才能开始下一阶段。

对于跨越多个集群的 mesh，请遵循单集群阶段，并添加迁移多集群 mesh中的步骤。有关每个阶段可以回滚到的状态，请参阅回滚迁移。

#为什么同时运行两个控制平面是安全的

在阶段 2到阶段 5期间，两个控制平面共享一个集群。以下四个特性使它们彼此隔离：

• 同一个证书颁发机构。Mesh v1 将其中间证书以 istiod 所需的格式存储在 istio-system 命名空间的 cacerts secret 中。Mesh v2 istiod 在同一命名空间中运行并加载同一个 secret，因此双方都从同一个根证书颁发工作负载证书，双向 TLS 可以在两者之间正常工作。
• 修订版本隔离。Mesh v1 本身是一个基于修订版本的部署（1-22）。Mesh v2 使用 RevisionBased 更新策略，因此其注入和验证 webhook 都带有自身的修订版本后缀。istio.io/rev 标签会为每个命名空间准确选择一个控制平面。
• 不共享默认值。Mesh v1 占用 default webhook 槽位。Mesh v2 不会创建名为 default 的 IstioRevisionTag，直到 Mesh v1 被移除。
• 独立的流量捕获。Mesh v1 使用 istio-init 容器捕获流量，Mesh v2 使用 IstioCNI。CNI 插件会跳过已带有 istio-init 的 pod，因此两个版本的 pod 可以在同一节点上运行而不会相互干扰。

#约定

针对承载 mesh 的集群运行命令。针对 global 集群执行操作的命令会显式传递 --context "${GLOBAL_CONTEXT}"。

特定于环境的值是 shell 变量。使用变量的每个页面都会通过发现命令设置该变量，或指向执行设置的页面。