当您需要将业务从Istio社区版迁移到服务网格 ASM（Service Mesh），而现有的业务又不允许停止服务时，您可以通过新建ACK集群来对现有服务进行灰度切换。本文介绍如何在不停止服务的前提下将Istio社区版灰度迁移至ASM。
卸载迁移与新建环境灰度迁移
在如何迁移Istio社区版本至ASM中，将业务从Istio迁移至ASM采用了先卸载istio，再原地安装配置ASM的方式。在一些无法容忍业务中断的场景中，推荐使用新建集群的方式，通过配置流量入口灰度切换，实现新旧集群并行运行，从而逐步完成迁移。以下是卸载迁移与新建环境灰度迁移的优缺点对比：
迁移类型 | 优点 | 缺点 |
卸载迁移 | 不需要准备另外一套环境。 | 要求业务在一定时间内停止服务，配置应用、业务重启和业务验证的操作全部完成后恢复服务。 |
新建环境灰度迁移 |
| 迁移完成前会同时存在两套相同的应用部署。 |
步骤一：创建新集群并加入ASM
创建新集群，您可以根据实际业务需求选择创建ACK托管集群、ACK Serverless集群或ACS集群。具体操作，请参见创建ACK托管集群、创建ACK Serverless集群或创建ACS集群。
关于ASM支持的集群类型，请参见功能特性。如有其他疑问，请提交工单咨询。
将新集群加入到ASM实例。具体操作，请参见添加集群到ASM实例。
执行以下命令，将旧集群中的Istio的配置导出。
kubectl get VirtualService --all-namespaces -o yaml > all-vs.yaml kubectl get DestinationRule --all-namespaces -o yaml > all-dr.yaml kubectl get Gateway --all-namespaces -o yaml > all-gw.yaml kubectl get ServiceEntry --all-namespaces -o yaml > all-se.yaml kubectl get EnvoyFilter --all-namespaces -o yaml > all-ef.yaml kubectl get Sidecar --all-namespaces -o yaml > all-sidecar.yaml kubectl get WorkloadEntry --all-namespaces -o yaml > all-we.yaml kubectl get WorkloadGroup --all-namespaces -o yaml > all-wg.yaml kubectl get PeerAuthentication --all-namespaces -o yaml > all-pa.yaml kubectl get RequestAuthentication --all-namespaces -o yaml > all-ra.yaml kubectl get AuthorizationPolicy --all-namespaces -o yaml > all-ap.yaml使用ASM实例的kubeconfig，将Istio配置导入到ASM。
kubectl apply -f all-*.yaml如下图所示，将部分应用迁移到新集群后，使用测试流量访问ASM网关验证新集群是否符合预期。
步骤二：验证和切换
新集群测试验证无误后，可以开始通过配置DNS权重将分配至新集群入口的流量逐步提升，并与此同时增加新集群的部署规模，直到将流量完全切换至新集群。
通过DNS权重将部分流量引导至新集群入口，并同时对新集群扩容，以承担更多流量。
若应用行为不符合预期，则将新集群权重设置为0，使得流量仍然全部进入旧集群。
流量完全切换至新集群后，将旧集群保留一段时间，保证能够随时调整DNS权重将流量切换回到旧集群。
步骤三：完成切换并下线旧集群
新集群在符合预期的情况下正常工作一段时间后，可以彻底下线旧集群。至此灰度迁移完成。
相关操作
通过配置DNS权重将生产流量分别引导到旧集群和新集群，可以实现平滑的灰度迁移。这种方法允许您逐步将流量从旧集群迁移到新集群，同时监控应用性能和用户反馈，确保迁移过程中的稳定性和可靠性。如果您使用的DNS为阿里云云解析DNS，可以根据权重配置进行DNS权重配置。