您可以将自建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的证书方式。
若输出结果存在
cacerts
Secret,表明采用外部root CA的方式。若输出结果存在
istio-ca-secret
Secret,表明采用自签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