從 GKE 上的 Istio 遷移至 Cloud Service Mesh
本指南說明如何將 Google Kubernetes Engine (GKE) 叢集從 Istio on Google Kubernetes Engine (Istio on GKE) 1.4 或 1.6 版 (Beta 版) 升級至代管的 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 遷移作業，或復原為 GKE 上的 Istio。
設定環境
如要設定環境，請按照下列步驟操作：
在 Google Cloud 控制台中啟用 Cloud Shell。
Google Cloud 控制台頁面底部會開啟 Cloud Shell 工作階段，並顯示指令列提示。Cloud 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 旗標之一，在安裝時執行這個步驟。
專案必須啟用 Service Mesh 功能。您可以傳遞 --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 叢集上部署 Cloud Service Mesh，並使用一般管道的 Google 代管控制層。這個控制層最初會與第二個 (或 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 驗證 Webhook。您必須完成這個步驟，才能將部分 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。如果搭配使用外掛程式憑證和 GKE 上的 Istio，工作負載遷移至 Google 代管控制層後，系統就不會再使用這些憑證。所有工作負載都會使用由 Google Cloud Service Mesh 憑證授權單位簽署的憑證。Cloud Service Mesh 憑證授權單位不支援外掛程式憑證。這封郵件僅供參考，你不需採取任何動作。
系統偵測到無法遷移的安全性政策。<錯誤原因>。 這通常是因為需要手動遷移 Alpha 版 AuthZ 政策。如要瞭解更多背景資訊，以及如何遷移政策，請參閱「將 Istio 1.4 Alpha 之前的安全政策遷移至目前的 API」。如要進一步瞭解錯誤訊息，請參閱「security-policy-migrate」。
偵測到可能不相容的 VirtualService 設定。<Specific deprecated config>。您需要更新下列
VirtualService設定：- 系統不支援使用
appendHeaders。請改用spec.http.headers。 - 不需要使用
websocketUpgrade。這項功能預設為開啟。 - 將
abort.percent欄位替換為abort.percentage。
- 系統不支援使用
偵測到無法遷移的混音器資源自訂安裝項目。需要手動遷移至 TelemetryV2。如果除了預設的 Istio on GKE 安裝作業外，您還設定了自訂混音器政策，則需要手動將這些政策遷移至 Telemetry V2。如要進一步瞭解如何執行這項操作，請參閱「自訂 Istio 指標」。
部署作業「<deploymentName>」可能是自訂閘道。手動遷移。您需要手動遷移
istio-ingressgateway以外的所有閘道部署作業 (預設會安裝istio-ingressgateway)。如要瞭解如何升級 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，即可停用trust-domain驗證。 - 將 Cloud Service Mesh 憑證授權單位信任根新增至
istio-citadel，將ConfigMap分發至所有命名空間。 - 將 Cloud Service Mesh 憑證授權單位信任根新增至
istio-ca-secret，以發布根憑證。
將舊版設定資訊清單儲存在
tmpdir中。提供復原函式的步驟 (稍後會說明)。
將工作負載遷移至 Cloud Service Mesh
在本節中，您會將在 GKE 上 Istio 執行的工作負載遷移至 Cloud Service Mesh。遷移後，請確認每個 Pod 都已注入正確的 Sidecar Proxy (Cloud Service Mesh)，且應用程式運作正常。
如果您要在現有叢集上執行這項程序，請選取要遷移的命名空間。
將命名空間定義為變數；這個命名空間會遷移至 Cloud Service Mesh：
export NAMESPACE=NAMESPACE_NAME
如要將工作負載遷移至 Cloud Service Mesh，您必須重新標記 Cloud Service Mesh 的命名空間。為命名空間加上標籤後，Cloud Service Mesh 會自動將補充資訊注入所有工作負載。如要為命名空間加上標籤，請執行下列指令，並將標籤設為
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 Proxy 版本，確認您現在已部署 Cloud Service Mesh Envoy Proxy：
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}'
查看遷移狀態
執行下列指令，查看遷移作業的狀態：
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 資訊主頁，確認所有服務都收到黃金信號。您也應該能看到應用程式拓撲。
前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。
您應該可以查看服務的指標和拓撲。
如要進一步瞭解 Cloud Service Mesh 資訊主頁，請參閱「在 Google Cloud 控制台中探索 Cloud Service Mesh」。
完成遷移作業
在本節中，您將完成從 GKE 上的 Istio 遷移至 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重新設定 Webhook，改用 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和修訂版本標籤，自動插入作業就會失敗，因此 GKE 上的 Istio 說明文件中的所有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確認已從叢集成功移除 GKE 部署作業和服務中的 Istio：
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 Ingress 閘道服務和部署作業。
恭喜！您已成功從 GKE 上的 Istio 遷移至 Cloud Service Mesh，並使用 Google 代管的控制層和 Cloud Service Mesh 憑證授權單位，應用程式完全沒有停機。
復原變更
在本節中，如果您不想繼續使用 Cloud Service Mesh，可以復原 Cloud Service Mesh 變更。完成本節後，工作負載就會移回 Istio on GKE。
復原異動 Webhook 變更：
${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 驗證補充 Envoy Proxy 版本，確認您已部署 Istio on GKE v1.4 Envoy Proxy：
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 Webhook：
${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
您已成功將 Istio on GKE 的變更還原。
部署 Online Boutique
在本節中，您會將名為「Online Boutique」的微服務範例應用程式部署至 GKE 叢集。Online Boutique 會部署在已啟用 Istio 的命名空間中。確認應用程式是否正常運作，以及 GKE 上的 Istio 是否將補充 Proxy 插入每個 Pod。
如果您已有包含應用程式的叢集，可以略過建立新命名空間和部署 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等待所有部署作業準備就緒：
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 Sidecar Proxy，後者會由 GKE 上的 Istio 自動注入 Pod：
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 Proxy 版本，確認您已部署 Istio on GKE v1.4 Envoy Proxy：
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-ingressgateway服務 IP 位址的 IP 位址，即可存取應用程式：kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
常見問題
本節說明從 GKE 上的 Istio 遷移至 Cloud Service Mesh 的常見問題和相關解答。
為什麼要將我從 GKE 上的 Istio 遷移至 Cloud Service Mesh？
Google Kubernetes Engine 上的 Istio 是 Beta 版功能，可在 Google Kubernetes Engine (GKE) 叢集上部署 Google 代管的 Istio。Istio on GKE 部署了不受支援的版本 (Istio 1.4 版)。為提供最新的服務網格功能和支援的服務網格實作方式，我們將所有 GKE 上的 Istio 使用者升級至 Cloud Service Mesh。
Cloud Service Mesh 是 Google 代管並支援的服務網格產品，以 Istio API 為基礎。Cloud Service Mesh 之於 Istio，就像 GKE 之於 Kubernetes。由於 Cloud Service Mesh 是以 Istio API 為基礎，因此遷移至 Cloud Service Mesh 時，您可以繼續使用 Istio 設定。此外，您也不必受制於特定廠商。
Cloud Service Mesh 具有下列優點：
- 由 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，可以在 GKE (位於Google Cloud) 上將 Cloud Service Mesh 做為獨立產品使用。詳情請參閱「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 支援」。