从 Istio on GKE 迁移到 Cloud Service Mesh
本指南介绍了如何使用 Google Kubernetes Engine (Istio on GKE) 1.4 或 1.6 版（Beta 版）将 Google Kubernetes Engine (GKE) 集群升级到代管式 Cloud Service Mesh，其中包含 Google 管理的控制平面和 Cloud Service Mesh 证书授权机构。
前提条件
您必须满足以下前提条件才能完成本指南：
已启用 Istio on GKE 的 GKE 集群。如果您有多个 GKE 集群，请对所有集群执行相同步骤。
Istio on GKE 必须是 1.4 或 1.6 版。
确保您运行的是 GKE 1.17.17-gke.3100+、1.18.16-gke.1600+、1.19.8-gke.1600+ 或更高版本。
GKE 集群必须在这些位置之一运行。
运行此脚本的用户或服务账号需要设置项目中记录的 IAM 权限。
本指南在 Cloud Shell 上进行了测试，因此我们建议您使用 Cloud Shell 执行本指南中的步骤。
目标
- 在常规渠道部署 Cloud Service Mesh Google 管理的控制平面。本指南针对常规渠道，稳定渠道或快速渠道的说明需要略加修改。如需详细了解发布渠道，请访问此链接。
- 将 Istio 配置迁移到 Cloud Service Mesh。
- 配置 Cloud Service Mesh 证书授权机构。
- 将应用迁移到 Cloud Service Mesh。
- 将
istio-ingressgateway从 Istio on GKE 升级到 Cloud Service Mesh。 - 完成 Cloud Service Mesh 迁移或回滚到 Istio on GKE。
设置环境
如需设置您的环境，请按以下步骤操作：
在 Google Cloud 控制台中，激活 Cloud Shell。
Cloud Shell 会话随即会在 Google Cloud 控制台页面的底部启动，并显示命令行提示符。Cloud Shell 是一个 shell 环境，其中已安装 Google Cloud CLI 和 Google Cloud CLI，并且包括已为当前项目设置的值。该会话可能需要几秒钟来完成初始化。
创建本指南中使用的环境变量：
# Enter your project ID export PROJECT_ID=PROJECT_ID # Copy and paste the following gcloud config set project ${PROJECT_ID} export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)') export CLUSTER_1=GKE_CLUSTER_NAME export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.创建
WORKDIR文件夹与本指南关联的所有文件都最终位于WORKDIR中，因此您可以在完成后删除WORKDIR。mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`为本指南创建一个
KUBECONFIG文件：您还可以使用现有的KUBECONFIG文件，其中包含要迁移到 Cloud Service Mesh 的 GKE 集群的集群上下文。touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig获取 GKE 集群的凭据，并将上下文存储在变量中：
区域级集群
gcloud container clusters get-credentials ${CLUSTER_1} \ --zone=${CLUSTER_1_LOCATION} export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}区域级集群
gcloud container clusters get-credentials ${CLUSTER_1} \ --region=${CLUSTER_1_LOCATION} export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}集群必须注册到舰队。 此步骤可以在安装之前单独完成，也可以在安装过程中通过传递 --fleet-id 标志外加 --enable-all 或 --enable-registration 标志来完成。
项目必须启用服务网格功能。您可以在安装过程中通过传递 --enable-all 或 --enable-registration 标志之一来启用它，也可以在安装之前通过运行以下命令来启用它：
gcloud container hub mesh enable --project=FLEET_PROJECT_ID其中，FLEET_PROJECT_ID 是舰队宿主项目的 ID。
可选的步骤
如果集群是专用集群（启用了 master-authorized-networks），请将 $SHELL_IP 添加到 master-authorized-networks 许可名单。如果您已有集群访问权限，则不需要执行此步骤。
区域级集群
export SHELL_IP=$(curl ifconfig.me)
gcloud container clusters update ${CLUSTER_1} \
--zone=${CLUSTER_1_LOCATION} \
--enable-master-authorized-networks \
--master-authorized-networks ${SHELL_IP}/32
区域级集群
export SHELL_IP=$(curl ifconfig.me)
gcloud container clusters update ${CLUSTER_1} \
--region=${CLUSTER_1_LOCATION} \
--enable-master-authorized-networks \
--master-authorized-networks ${SHELL_IP}/32
安装 Cloud Service Mesh
在本部分中，您将使用 GKE 集群上的常规渠道的 Google 管理的控制平面来部署 Cloud Service Mesh。此控制平面最初作为第二个（或 Canary 版）控制平面一起部署。
将安装 Cloud Service Mesh 的最新版脚本下载到当前工作目录，并使脚本可执行：
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcli如需配置 GKE 集群，请运行安装脚本以使用常规渠道的 Google 管理的控制平面安装 Cloud Service Mesh：
./asmcli install \ -p ${PROJECT_ID} \ -l ${CLUSTER_1_LOCATION} \ -n ${CLUSTER_1} \ --fleet_id ${FLEET_PROJECT_ID} \ --managed \ --verbose \ --output_dir ${CLUSTER_1} \ --enable-all \ --channel regular此步骤可能需要几分钟时间才能完成。
将
istioctl复制到WORKDIR文件夹：cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
在下一部分中，您将下载并运行 migrate_addon 脚本，以帮助迁移到 Cloud Service Mesh。istioctl 命令行实用程序需要与 migrate_addon 脚本位于同一文件夹中。您可以使用 WORKDIR 文件夹作为 istioctl 命令行实用程序和 migrate_addon 脚本。
将配置迁移到 Cloud Service Mesh
在本部分中，您将 Istio on GKE 配置迁移到 Cloud Service Mesh。引导式脚本确定可以和不能迁移哪些配置。
下载迁移工具并使其可执行：
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon chmod +x ${WORKDIR}/migrate_addon停用 Galley 验证网络钩子。此步骤将迁移部分 1.4 配置到 Cloud Service Mesh。回答
Y针对这两个问题：${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook输出内容类似如下：
tmpdir directory not present. Create directory? Continue? [Y/n] Y Disabling the Istio validation webhook... Continue? [Y/n] Y Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}] clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted验证并手动迁移配置。此步骤有助于识别在将工作负载迁移到 Google 管理的控制层面之前需要手动迁移的一些配置。
${WORKDIR}/migrate_addon -d tmpdir --command config-check输出内容类似如下：
Installing the authentication CR migration tool... OK Checking for configurations that will need to be explicitly migrated... No resources found
迁移自定义配置
在迁移到 Cloud Service Mesh 之前，您可能需要手动迁移自定义配置。上述脚本可识别自定义配置，并输出所需内容的相关信息。这些自定义项如下所示：
Cloud Service Mesh 不支持检测到的自定义 Envoy 过滤器。请尽可能移除这些项。Google 管理的控制平面目前不支持 Envoy 过滤器。
检测到的自定义插件证书。插件证书不会迁移到 Cloud Service Mesh。如果将插件证书与 Istio on GKE 搭配使用，则在工作负载迁移到 Google 管理的控制平面后，系统不会使用这些证书。所有工作负载都使用由 Google Cloud Service Mesh 证书授权机构签名的证书。Cloud Service Mesh 证书授权机构不支持插件证书。此消息为参考信息，无需执行任何操作。
检测到无法迁移的安全政策。<Error reason>。这通常失败，因为 Alpha 版 AuthZ 政策需要手动迁移。如需了解有关如何迁移政策的更多上下文和信息，请参阅将 Istio 1.4 Alpha 版之前的安全政策迁移到当前 API。如需详细了解错误消息，请参阅 security-policy-migrate。
检测到可能不兼容的 VirtualService 配置。<Specific deprecated config>。您需要更新以下内容
VirtualServiceconfiguration：- 不支持使用
appendHeaders。请改用spec.http.headers。 - 不需要使用
websocketUpgrade。该功能默认处于启用状态。 - 将字段
abort.percent替换为abort.percentage。
- 不支持使用
检测到无法迁移的 Mixer 资源的自定义安装。需要手动迁移到 telemetryv2。如果除了默认 Istio on GKE 安装之外还配置了自定义 Mixer 政策，则需要手动将这些政策迁移到遥测 v2。如需详细了解如何执行此操作，请参阅自定义 Istio 指标。
部署 <deploymentName> 可以是自定义网关。手动迁移此文件。您需要手动迁移除
istio-ingressgateway（默认安装）以外的所有网关 Deployment。如需了解如何升级 Google 管理的控制层面的网关，请参阅配置 Google 管理的控制层面。
如需迁移配置，请按以下步骤操作：
手动迁移所有自定义配置（列出的最后一个配置除外），然后再继续执行第 2 步。
使用迁移工具迁移可以自动迁移（或忽略）的配置。
${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs输出类似于以下内容：
Converting authentication CRs... 2021/06/25 20:44:58 found root namespace: istio-system 2021/06/25 20:44:59 SUCCESS converting policy /default Running: kubectl apply --dry-run=client -f beta-policy.yaml peerauthentication.security.istio.io/default created (dry run) Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y Running: kubectl apply -f beta-policy.yaml peerauthentication.security.istio.io/default created OK
应用 Cloud Service Mesh 证书授权机构根信任。这样，您就可以从当前 Citadel CA 迁移到 Cloud Service Mesh 证书授权机构，而不会对应用产生任何停机时间。
${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca输出类似于以下内容：
Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y Running: kubectl get cm -n istio-system istio-asm-managed -oyaml Running: kubectl -n istio-system apply -f - secret/meshca-root created Running: kubectl get cm istio -n istio-system -o yaml Running: kubectl get cm istio -n istio-system -o yaml Running: kubectl replace -f - configmap/istio replaced Running: kubectl get deploy istio-pilot -n istio-system -o yaml Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{ "name":"discovery", "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12", "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}] }]}}}} deployment.apps/istio-pilot patched Running: kubectl get deploy istio-citadel -n istio-system -o yaml Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{ "containers":[{ "name":"citadel", "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"], "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}] }], "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}] }}}} deployment.apps/istio-citadel patched OK Waiting for root certificate to distribute to all pods. This will take a few minutes... ASM root certificate not distributed to asm-system, trying again later ASM root certificate not distributed to asm-system, trying again later ASM root certificate distributed to namespace asm-system ASM root certificate distributed to namespace default ASM root certificate distributed to namespace istio-operator ASM root certificate not distributed to istio-system, trying again later ASM root certificate not distributed to istio-system, trying again later ASM root certificate distributed to namespace istio-system ASM root certificate distributed to namespace kube-node-lease ASM root certificate distributed to namespace kube-public ASM root certificate distributed to namespace kube-system ASM root certificate distributed to namespace online-boutique Waiting for proxies to pick up the new root certificate... OK Configuring Istio Addon 1.6 to trust Anthos Service Mesh... Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml Running: kubectl replace -f - configmap/istio-istio-1611 replaced Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge istiooperator.install.istio.io/istio-1-6-11-gke-0 patched Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem} Running: kubectl -n istio-system patch secret istio-ca-secret secret/istio-ca-secret patched Running: kubectl patch deploy istiod-istio-1611 -n istio-system deployment.apps/istiod-istio-1611 patched Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination... deployment "istiod-istio-1611" successfully rolled out Running: kubectl apply -f - -n istio-system envoyfilter.networking.istio.io/trigger-root-cert created Waiting for proxies to pick up the new root certificate... Running: kubectl delete envoyfilter trigger-root-cert -n istio-system OK此步骤需要几分钟时间才能将 Cloud Service Mesh 根证书分发给所有命名空间。等待脚本完成并显示
OK消息。
上一步会执行以下操作：
- 为集群中的所有工作负载安装 Cloud Service Mesh 证书颁发机构信任根。
更改控制层面 Deployment
istio-pilot、istiod和istio-citadel的配置。这些更改包括：- 将映像升级到最新构建。
- 通过设置
PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true停用trust-domain验证。 - 将 Cloud Service Mesh 证书授权机构信任根添加到
istio-citadel，以将ConfigMap分发到所有命名空间。 - 将 Cloud Service Mesh 证书授权机构信任根添加到
istio-ca-secret以分发根证书。
将较旧的配置清单存储在
tmpdir中。提供回滚函数的步骤（稍后记录）。
将工作负载迁移到 Cloud Service Mesh
在本部分中，您需要将 Istio on GKE 上运行的工作负载迁移到 Cloud Service Mesh。迁移后，您需要验证每个 pod 中是否注入了正确的 Sidecar 代理 (Cloud Service Mesh)，并且应用是否按预期运行。
如果要在现有集群上执行此过程，请选择要迁移的命名空间。
将命名空间定义为变量；此命名空间会迁移到 Cloud Service Mesh：
export NAMESPACE=NAMESPACE_NAME
如需将工作负载迁移到 Cloud Service Mesh，您必须为 Cloud Service Mesh 重新添加命名空间。通过为命名空间添加标签，Cloud Service Mesh 会自动将 Sidecar 注入所有工作负载。如需为命名空间添加标签，请运行以下命令，将标签设置为
asm-managed：kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite对命名空间中的所有 Deployment 执行滚动重启：
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}输出内容类似如下：
deployment.apps/deploymentName1 restarted deployment.apps/deploymentName2 restarted ...
确保所有 pod 都重启并为每个 pod 运行两个容器：
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods输出内容类似如下：
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
验证此步骤的好方法是查看 Pod 的
AGE。请确保该值很短，例如几分钟。从命名空间中的任何 Deployment 的任何一个 Pod 检查 Sidecar Envoy 代理版本，以确认您现已部署 Cloud Service Mesh Envoy 代理：
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'输出类似于以下内容：
"gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3" "appContainerImage"
重启后验证并验证您的应用。
kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'（可选）如果您希望 Google 管理代理的升级，请启用 Google 管理的数据平面
查看迁移状态
运行以下命令查看迁移的状态：
kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}
输出指示迁移是已完成、待处理还是已失败：
{"migrationStatus":"SUCCESS"}
{"migrationStatus":"PENDING"}
{"migrationStatus":"MIGRATION_CONFIG_ERROR"}
{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}
如果 migrationStatus 输出 SUCCESS，则控制平面已成功升级到 Cloud Service Mesh。如需手动更新数据平面，请完成迁移工作负载中的步骤。
如果 migrationStatus 输出除 SUCCESS 以外的任何状态，您可以选择执行以下任一操作：
- 如果迁移错误不会影响现有的 Istio on GKE 工作负载，则无需执行任何额外操作。否则，请根据需要回滚。
- 如果
migrationStatus显示MIGRATION_CONFIG_ERROR，请更新集群中的自定义配置并重新手动运行迁移。
您可以在成功迁移后在 Metrics Explorer 中查看控制平面指标，请参阅 verify_control_plane_metrics
访问 Cloud Service Mesh 信息中心
在本部分中，您将转到 Cloud Service Mesh 信息中心，并确保收到所有 Service 的黄金信号。您还应能够查看应用拓扑。
在 Google Cloud 控制台中，前往 Cloud Service Mesh 页面。
您应该能够查看 Service 的指标和拓扑。
如需详细了解 Cloud Service Mesh 信息中心，请参阅在 Google Cloud 控制台中探索 Cloud Service Mesh。
成功完成迁移
在本部分中，您将完成 Istio on GKE 到 Cloud Service Mesh 的迁移。在继续本部分之前，请确保您要继续使用 Cloud Service Mesh。本部分还可帮助您清理 Istio on GKE 工件。如果要回滚到 Istio on GKE，请继续阅读下一部分。
将
istio-ingressgateway（GKE 上的标准 Istio 的一部分）替换为 Google 管理的控制层面版本控制网关：${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway输出内容类似如下：
Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite label "istio.io/rev" not found. namespace/istio-system labeled Running: kubectl apply -f - serviceaccount/asm-ingressgateway created deployment.apps/asm-ingressgateway created role.rbac.authorization.k8s.io/asm-ingressgateway created rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system deployment.apps/asm-ingressgateway condition met Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}} horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change) Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0 deployment.apps/istio-ingressgateway scaled OK重新配置网络钩子以使用 Google 管理的控制平面：所有工作负载首先使用 Google 管理的控制平面：
${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook输出类似于以下内容：
Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}] mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default' OK使用 Cloud Service Mesh 标签重新标记所有命名空间，并执行所有工作负载的滚动重启，使其在 Google 管理的控制平面上：
export NAMESPACE=NAMESPACE_NAME \ kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite` kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}您可以忽略输出中的
"istio-injection not found"消息。这意味着命名空间之前没有istio-injection标签，对于 Cloud Service Mesh 的新安装或新部署，这是预期现象。如果命名空间同时具有istio-injection和修订版本标签，自动注入将失败，因此 Istio on GKE 文档中的所有kubectl label命令都包含移除istio-injection标签。通过运行以下命令完成迁移：
${WORKDIR}/migrate_addon -d tmpdir --command write-marker输出内容类似如下：
Current migration state: SUCCESS Running: kubectl apply -f - configmap/asm-addon-migration-state created OK
通过运行以下命令停用 Istio on GKE：
区域级集群
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --zone=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLED区域级集群
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --region=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLED通过运行以下命令清理配置：
${WORKDIR}/migrate_addon -d tmpdir --command cleanup输出内容类似如下：
Cleaning up old resources... Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus} Will delete IstioOperator/istio-1-6-11-gke-0.istio-system Will delete ServiceAccount/istio-citadel-service-account.istio-system ... Will delete DestinationRule/istio-policy.istio-system Will delete DestinationRule/istio-telemetry.istio-system Will delete Secret/istio-ca-secret.istio-system Deleting resources previously listed... Continue? [Y/n] Y Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found ... Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found secret "istio-ca-secret" deleted Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security job.batch "istio-security-post-install-1.4.10-gke.8" deleted确保已成功从集群中移除 Istio on GKE 部署和服务：
kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services输出类似于以下内容：
NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/asm-ingressgateway 1/1 1 1 10m NAME TYPE CLUSTER-IP EXTERNAL-IP AGE PORT(S) service/istio-ingressgateway LoadBalancer 10.64.5.208 34.139.100.237 95m 15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP
您只能看到 Cloud Service Mesh 入站流量网关服务和部署。
恭喜！您已成功借助 Google 管理的控制平面和 Cloud Service Mesh 证书授权机构，在不发生任何应用停机的情况下从 Istio on GKE 迁移到 Cloud Service Mesh。
回滚更改
在本部分中，如果您不想继续使用 Cloud Service Mesh，可以回滚 Cloud Service Mesh 更改。完成本部分后，您的工作负载会移回 Istio on GKE。
回滚变更网络钩子更改：
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook通过运行以下命令，为命名空间重新添加标签以使用 Istio on GKE Sidecar 注入而不是 Cloud Service Mesh：
对于具有 1.4 版工作负载的命名空间：
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite对于具有 1.6 版工作负载的命名空间：
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite对命名空间中的所有 Deployment 执行滚动重启：
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}等待几分钟，并确保所有 Pod 都在运行：
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods输出内容类似如下：
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
从任一 Pod 验证 Sidecar Envoy 代理版本，以确认您部署了 Istio on GKE v1.4 Envoy 代理：
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'输出类似于以下内容：
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "appContainerImage"
或
"gke.gcr.io/istio/proxyv2:1.6.14-gke.4" "appContainerImage"
重启后验证并验证您的应用。
回滚 Cloud Service Mesh 证书授权机构更改：
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca重新启用 Istio Galley 网络钩子：
${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
您已成功回滚对 Istio on GKE 的更改。
部署 Online Boutique
在本部分中，您需要将名为 Online Boutique 的基于微服务的示例应用部署到 GKE 集群。Online Boutique 部署在启用了 Istio 的命名空间中。您需要验证应用是否正常工作，以及 Istio on GKE 是否正在向每个 Pod 注入 Sidecar 代理。
如果您已有具有应用的现有集群，则可以跳过创建新命名空间和部署 Online Boutique。对于将工作负载迁移到 Cloud Service Mesh 部分中的所有命名空间，您都可以使用相同的过程。
将 Online Boutique 部署到 GKE 集群：
kpt pkg get \ https://github.com/GoogleCloudPlatform/microservices-demo.git/release \ online-boutique kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique等待所有 Deployment 准备就绪：
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice确保每个 Pod 有两个容器：应用容器和 Istio on GKE 自动注入 Pod 的 Istio Sidecar 代理：
kubectl --context=${CLUSTER_1_CTX} -n online-boutique get pods输出内容类似如下：
NAME READY STATUS RESTARTS AGE adservice-7cbc9bd9-t92k4 2/2 Running 0 3m21s cartservice-d7db78c66-5qfmt 2/2 Running 1 3m23s checkoutservice-784bfc794f-j8rl5 2/2 Running 0 3m26s currencyservice-5898885559-lkwg4 2/2 Running 0 3m23s emailservice-6bd8b47657-llvgv 2/2 Running 0 3m27s frontend-764c5c755f-9wf97 2/2 Running 0 3m25s loadgenerator-84cbcd768c-5pdbr 2/2 Running 3 3m23s paymentservice-6c676df669-s779c 2/2 Running 0 3m25s productcatalogservice-7fcf4f8cc-hvf5x 2/2 Running 0 3m24s recommendationservice-79f5f4bbf5-6st24 2/2 Running 0 3m26s redis-cart-74594bd569-pfhkz 2/2 Running 0 3m22s shippingservice-b5879cdbf-5z7m5 2/2 Running 0 3m22s
您还可以从任一 Pod 中查看 Sidecar Envoy 代理版本，以确认您部署了 Istio on GKE v1.4 Envoy 代理：
export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}') kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'输出内容类似如下：
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
通过导航到
istio-ingressgatewayService IP 地址的 IP 地址来访问应用：kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
常见问题解答
本部分介绍了有关从 Istio on GKE 迁移到 Cloud Service Mesh 的常见问题解答。
为什么要从 Istio on GKE 迁移到 Cloud Service Mesh？
Google Kubernetes Engine 上的 Istio 是一项测试版功能，用于在 Google Kubernetes Engine (GKE) 集群上部署由 Google 管理的 Istio。Istio on GKE 部署了不受支持的版本（Istio 1.4 版）。为了向您提供最新的服务网格功能和支持的服务网格实现，我们正在将所有 Istio on GKE 用户升级到 Cloud Service Mesh。
Cloud Service Mesh 基于 Istio API，是 Google 管理和支持的服务网格产品。Cloud Service Mesh 与 Istio 的关系类似于 Google Kubernetes Engine (GKE) 与 Kubernetes 的关系。由于 Cloud Service Mesh 基于 Istio API，因此在迁移到 Cloud Service Mesh 后，您可以继续使用您的 Istio 配置。此外，不存在专有供应商锁定。
Cloud Service Mesh 具有以下优势：
- Google 管理和 Google 支持的服务网格。
- 无供应商锁定的 Istio API。
- 开箱即用的遥测信息中心和 SLO 管理功能，无需管理其他第三方解决方案。
- Google 托管的证书授权机构选项。
- 与 Google Cloud 网络和 Identity-Aware Proxy (IAP) 集成。
- 混合云和多云平台支持。
如需详细了解 Cloud Service Mesh 的特性和功能，请参阅 Google 管理的控制平面支持的功能。
迁移是否会导致停机？
迁移脚本旨在避免停机。脚本会将 Cloud Service Mesh 作为 Canary 版控制平面安装，与现有 Istio 控制平面并存。istio-ingressgateway 已就地升级。然后，重新为启用 Istio 的命名空间添加标签，开始使用 Cloud Service Mesh 与 Cloud Service Mesh 证书授权机构。
确保为应用正确配置 PodDisruptionBudgets，以避免任何应用停机。虽然您可以避免停机，但如果您自行执行此迁移，我们建议您在计划维护期执行此迁移。Google 驱动的迁移在 GKE 维护期执行。确保您的 GKE 集群已配置维护期。
使用 Cloud Service Mesh 是否会产生费用？
在 GKE 上使用 Cloud Service Mesh 的方法有两种：
如果您是 GKE Enterprise 订阅者，则 Cloud Service Mesh 包含在您的 GKE Enterprise 订阅中。
如果您不是 GKE Enterprise 订阅者，可以将 Cloud Service Mesh 作为 GKE (on Google Cloud) 上的独立产品使用。如需了解详情，请参阅 Cloud Service Mesh 价格详情。
是否有任何最新版本或 Cloud Service Mesh 不支持的功能或配置？
该脚本会检查所有 Istio 配置，并将其迁移到最新的 Cloud Service Mesh 版本。某些配置可能需要执行其他步骤，以便从 Istio 1.4 版迁移到 Cloud Service Mesh 1.10 版。该脚本会执行配置检查，并在任何配置需要其他步骤时通知您。
迁移是否会更改我当前的 Istio 配置？
不会，您的 Istio 配置可以在 Cloud Service Mesh 中使用，无需进行任何更改。
迁移到 Cloud Service Mesh 后，可以迁移回 Istio 吗？
是的，Cloud Service Mesh 没有使用承诺。您可以随时卸载 Cloud Service Mesh 并重新安装 Istio。
如果迁移失败，是否可以回滚？
可以，该脚本可让您回滚到先前的 Istio on GKE 版本。
我可以使用此脚本迁移哪个 Istio 版本？
该脚本可帮助您从 Istio on GKE 1.4 版迁移到 Cloud Service Mesh 1.10 版。脚本会在迁移前阶段验证您的 Istio 版本，并告知您 Istio 版本是否可以迁移。
如何获取关于此次迁移的更多帮助？
我们的支持团队很乐意提供帮助。您可以通过 Google Cloud 控制台创建支持请求。如需了解详情，请参阅管理支持请求。
如果我没有迁移到 Cloud Service Mesh，会发生什么？
您的 Istio 组件可以继续运行，但 Google 不再管理您的 Istio 安装。您将不再收到自动更新，也不能保证安装作为 Kubernetes 集群版本更新。
如需了解详情，请参阅 Istio 支持。