當您需要將業務從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權重配置。