您可以将自建Istio版本迁移至阿里云服务网格ASM，减轻开发与运维的工作负担。在迁移过程中支持回滚操作。本文介绍如何迁移Istio社区版本至ASM。
前提条件
已创建ASM支持的Kubernetes集群，例如ACK、容器服务 Serverless 版集群等。
已通过kubectl工具连接集群。具体操作，请参见通过kubectl工具连接集群。
配置流程
迁移前检查
迁移前，您需要参照下表确认Istio社区版本、证书提供者和证书方式是否符合迁移条件。证书提供者需要您自行确认。下文介绍如何查看Istio社区版本和证书的安装方式。
Istio社区版本（单集群） | 证书提供者（PILOT_CERT_PROVIDER） | 证书方式 | 是否支持迁移 | 建议使用ASM版本 |
<1.5 | istiod | 外部root CA或自签CA |
| 不涉及 |
≥1.5且≤1.14 | istiod | 外部root CA或自签CA |
| ASM最新版本，请参见功能发布记录。 |
≥1.15 | istiod | 外部root CA或自签CA |
| ASM最新版本，请参见功能发布记录。 |
不涉及 | certManager或其他 | 不涉及 |
| 不涉及 |
若您需要迁移ASM还未支持的Istio社区版本，请加入钉群（钉群号：30421250），联系产品技术专家进行咨询。
查看Istio社区版本
执行以下命令，查看当前社区版本。
./istioctl version示例输出：
client version: 1.14.3
control plane version: 1.14.3
data plane version: 1.14.3 (6 proxies)查看安装Istio社区版本的证书方式
安装Istio社区版本时，有以下两种常见的证书方式：
pluggedCertCA插入的外部root CA。更多信息，请参见Plug in CA Certificates。
selfSignedCA自签CA（默认安装方式）。
您可以执行kubectl get secret -n istio-system命令，确认istio-system命名空间下Secret的证书方式。
若输出结果存在
cacertsSecret，表明采用外部root CA的方式。若输出结果存在
istio-ca-secretSecret，表明采用自签CA的方式。
步骤一：创建ASM企业版或旗舰版实例
ASM从1.13版本开始支持金丝雀版本升级方式，对应部署的Istiod等相关资源带有版本后缀，不会和当前Kubernetes集群下已部署的Istio社区版本冲突。例如，ASM 1.14.3对应的Istio的相关资源都带有1-14-3后缀。
通过CreateServiceMesh API创建ASM实例。
主要配置项说明如下。关于配置项的更多说明，请参见创建一个服务网格实例。
配置项
说明
RegionId
需要和Kubernetes集群处于相同地域。
您可以登录容器服务管理控制台，在集群页面查看Kubernetes集群所在的地域。
关于ASM支持的地域及Region ID的更多信息，请参见开服地域。
VpcId
Kubernetes集群所在的专有网络ID。
VSwitches
Kubernetes集群所在的交换机ID。
CRAggregationEnabled
默认为关闭，无需修改。
ClusterSpec
迁移场景下仅支持以下两种服务网格实例规格：
enterprise：企业版。
ultimate：旗舰版。
ClusterDomain
默认为cluster.local，需要和自建Istio所在的Kubernetes集群的ClusterDomain保持一致。
UseExistingCA
打开UseExistingCA开关，使用已知的CA证书创建ASM实例。
ExistingRootCaCert、
ExistingCaCert、
ExistingCaKey、
CertChain
创建网格时的证书配置：
如果自建Istio为自签名CA，请按照以下格式填写相关参数：
ExistingRootCaCert：对应istio-system命名空间下的istio-ca-secret的caCert内容（Base64编码格式）。
ExistingCaCert：对应istio-system命名空间下istio-ca-secret的caCert内容（Base64编码格式）。
ExistingCaKey：对应istio-system命名空间下istio-ca-secret的caKey内容（Base64编码格式）。
CertChain：将ExistingCaCert和ExistingRootCaCert进行Base64解码后得到两个证书，将这两个证书放在一个文件中，进行Base64编码后填入即可。
如果自建Istio证书为外部Root CA，直接将对应istio-system命名空间下istio-cacerts的secret相应内容填入即可。
说明创建网格时使用自定义证书之后，需要您自行维护证书的生命周期（参考UpdateMeshFeature API），防止证书过期影响业务。
查看ASM实例是否创建成功。
登录ASM控制台，在左侧导航栏，选择。
在网格管理页面，查看创建的ASM实例。
当ASM实例的状态为运行中，表示创建成功。
步骤二：在新建的ASM实例下添加Kubernetes集群
执行以下命令，修改Kubernetes集群下的
mutatingwebhookconfigurations。修改名称为
istio-sidecar-injector或者istio-revision-tag-default，将istio-injection=enabled对应的Webhook修改为istio-injection=enabled-addon。重要请确保mutatingwebhookconfiguration Webhook对
istio-injection=enabled标签生效且为唯一生效值，避免多个生效值同时存在时，注入的Sidecar结果随机，导致Pod启动失败。export KUBECONFIG=<Your ACK Cluster's Kube Config File> kubectl get mutatingwebhookconfigurations -A示例输出：
NAME WEBHOOKS AGE istio-revision-tag-default 4 5d4h istio-sidecar-injector 4 5d4h通过AddClusterIntoServiceMesh API添加自建Istio所在的Kubernetes集群。
打开IgnoreNamespaceCheck开关，开启忽略istio-system检查逻辑。关于配置项的更多说明，请参见AddClusterIntoServiceMesh。
重要Kubernetes集群添加到ASM后，请勿在原有Kubernetes集群下变更和新建Istio相关资源，否则会出现如下示例报错：
Error from server: error when creating "samples/bookinfo/networking/destination-rule-all.yaml": admission webhook "asm-validation.istio.io" denied the request: 当前Kubernetes集群已经添加到服务网格ASM中，在ASM控制台中创建Istio相关自定义资源，或使用ASM提供的kubeconfig进行管理。Kubernetes集群添加完成后，您可以看到在Kubernetes集群的istio-system命名空间下新增了一些Pod和Configmap，以及相关mutatingwebhookconfigurations和validatingwebhookconfigurations Webhook。
同步命名空间和注入配置。
登录ASM控制台，在左侧导航栏，选择。
在网格管理页面，单击目标实例名称，然后在左侧导航栏，选择。
在全局命名空间页面，单击从Kubernetes集群同步自动注入，同步Namespace以及Namespace下的自动注入配置。（default命名空间的自动注入在加入网格之后会默认关闭，需要手动开启。）
任选以下方式，关闭ASM实例的mTLS。
ASM实例默认开启mTLS，如果您自建istio并未开启mTLS，请关闭ASM实例的mTLS，防止新老sidecar、网关之间连接建立失败。如果您自建istio已经开启mTLS，可以跳过这一步。
方式一：通过控制台
在网格详情页面左侧导航栏，选择，然后在右侧页面单击设置全局双向。
在设置全局双向TLS模式页面，配置mTLS模式(命名空间级)为DISABLE - 禁用双向TLS认证，然后单击创建。
方式二：通过命令行
使用以下内容，创建peer-authentication.yaml。
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: DISABLE执行以下命令，关闭mTLS。
kubectl apply -f peer-authentication.yaml
步骤三：验证Sidecar注入是否成功
执行以下命令，创建测试命名空间及服务。
export KUBECONFIG=<Your ACK Cluster's Kube Config File> kubectl create ns foo kubectl label ns foo istio.io/rev=1-14-3 # 请将1-14-3替换为ASM的实际版本。 kubectl create deployment nginx --image=nginx -n foo执行以下命令，查看Pod是否成功注入对应ASM版本的Sidecar。
kubectl get pods -n foo -o yaml |grep proxyv2预期输出：
image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/proxyv2:v1.14.3.47-ga38201****-aliyun image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/proxyv2:v1.14.3.47-ga38201****-aliyun image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/proxyv2:v1.14.3.47-ga38201****-aliyun imageID: registry-vpc.cn-hangzhou.aliyuncs.com/acs/proxyv2@sha256:a2a4d61a8a6183a890c7beac21e6790fc125a0e45ebbc299e728f96755f3**** image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/proxyv2:v1.14.3.47-ga38201****-aliyun imageID: registry-vpc.cn-hangzhou.aliyuncs.com/acs/proxyv2@sha256:a2a4d61a8a6183a890c7beac21e6790fc125a0e45ebbc299e728f96755f3****预期输出表明Pod成功注入对应ASM版本的Sidecar。ASM的Sidecar镜像对应在acs/proxyv2 HUB下。
步骤四：迁移Istio配置到ASM
每个ASM实例对应一个独立的Kubernetes集群。ASM控制面涉及的相关资源配置（VirtualService、DestinationRule等）需要创建在ASM对应的集群下。
执行以下命令，从已安装Istio社区版本的Kubernetes集群中备份导出已有Istio自定义资源。
export KUBECONFIG=<Your ACK Cluster's Kube Config File> 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执行以下命令，将本小节步骤1导出的YAML部署到ASM实例。
替换命令中
all-*为实际的YAML文件名称。kubectl --kubeconfig={服务网格ASM对应的kubeconfig} apply -f all-*.yaml
步骤五：迁移数据面
数据面的迁移包括Sidecar和Gateway。Sidecar的迁移和Webhook的注入配置相关，因此在迁移之前需要确认已将本地Istio社区版本下对应的mutatingwebhookconfigurations Webhook下的匹配条件istio-injection=enabled修改为非enabled的值。具体操作，请参见步骤二的第一步。
迁移Sidecar
通过滚动更新业务服务Pod来注入ASM的Sidecar版本。
ASM的Sidecar连接到ASM实例对应的Istiod控制面后，可享有ASM扩展的服务网格相关能力，例如SpringCloud支持、流量泳道、限流、路由级熔断等。
业务Pod滚动更新后，查看对应业务服务。
登录ASM控制台，在左侧导航栏，选择。
在网格管理页面，单击目标实例名称，然后在左侧导航栏，选择。
在网格状态页面，可以查看当前ASM控制面和Sidecar的配置同步状态。
（可选）迁移Gateway
入口流量网关有多种类型。目前，ASM提供迁移自建的Istio IngressGateway和Nginx Ingress到ASM网关的指导。具体操作，请参见自建Istio IngressGateway如何迁移至ASM网关和Nginx Ingress如何迁移至ASM网关。
若您需要迁移其他类型的入口流量网关，请加入钉群（钉群号：30421250），联系产品技术专家进行咨询。
步骤六：卸载自建Istio
当Istio社区版本的Sidecar更新到ASM后，您可以执行istioctl ps命令，查看当前Sidecar版本的分布，确认迁移完成后删除自建Istio。
执行以下命令，查看当前Sidecar版本的分布。
export KUBECONFIG=<Your ACK Cluster's Kube Config File> ./istioctl ps示例输出：
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION istio-egressgateway-666cdd84d7-p****.istio-system Kubernetes SYNCED SYNCED SYNCED NOT SENT NOT SENT istiod-5dbcf9****-tnsgt 1.14.3 istio-ingressgateway-58f4c4f77f-n****.istio-system Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-5dbcf9****-tnsgt 1.14.3输出结果为空，表示数据面已完整地迁移到ASM版本的Sidecar或Gateway。
执行以下命令，卸载本地Istio。
istioctl manifest generate <your original installation options> | kubectl delete --ignore-not-found=true -f -<your original installation options>表示初安装Istio时的选项，例如--set profile=demo。说明如果您有以前安装的Istio YAML备份，可以通过以下命令进行卸载。
kubectl delete --ignore-not-found=true -f <your-istiod-install.yaml>执行以下命令，删除istio.io相关的CRD。
kubectl get crd -oname | grep --color=never 'istio.io' | xargs kubectl delete说明需使用和安装同版本或更高版本的Istioctl进行操作，避免新版本新增的相关资源未卸载。更多信息，请参见Istioctl。
执行以下命令，卸载原有社区版本相关证书文件。
kubectl delete secret istio-ca-secret -n istio-system kubectl delete secret cacerts -n istio-system