從 GKE 上的 Istio 遷移至 Cloud Service Mesh
本指南說明如何使用 Google 管理控制平面和 Cloud Service Mesh 憑證授權單位，將 Google Kubernetes Engine (GKE) 叢集升級至由 Google 管理的 Cloud Service Mesh，並使用 Istio on Google Kubernetes Engine (Istio on GKE) 1.4 或 1.6 版 (Beta 版)。
事前準備
完成本指南需要具備下列先決條件：
已啟用 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 叢集上，使用 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 驗證 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 設定。<特定已淘汰的設定>。您需要更新下列
VirtualService設定：- 系統不支援使用
appendHeaders。請改用spec.http.headers。 - 不需要使用
websocketUpgrade。這項功能預設為開啟。 - 將欄位
abort.percent替換為abort.percentage。
- 系統不支援使用
偵測到無法遷移的混合器資源自訂安裝作業。需要手動遷移至遙測 v2。如果除了 GKE 安裝作業中的預設 Istio 外，您還設定了自訂的 Mixer 政策，就必須手動將這些政策遷移至遙測 v2。如要進一步瞭解如何執行這項操作，請參閱「自訂 Istio 指標」。
部署 <deploymentName> 可能是自訂閘道。請手動遷移。您需要手動遷移所有閘道部署 (除了預設安裝的
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 憑證授權單位信任根。
變更控制平面部署
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
在本節中，您將將在 GKE 上以 Istio 執行的工作負載遷移至 Cloud Service Mesh。遷移完成後，請確認每個 Pod 都已注入正確的附屬 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針對命名空間中的所有部署作業執行滾動式重新啟動作業：
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。請確保值為短時間，例如幾分鐘。請檢查命名空間中任何部署的任何 Pod 的側載 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 管理 Proxy 升級作業，請啟用 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，您可以選擇以下任一做法：
- 如果遷移錯誤不會影響您在 GKE 上執行的現有 Istio 工作負載，則無需採取額外行動。否則，視需要回復。
- 如果
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
執行下列指令，即可在 GKE 上停用 Istio：
區域叢集
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 入口網關服務和部署作業。
恭喜！您已成功使用 Google 代管的控制層和 Cloud Service Mesh 憑證授權單位，從 GKE 上的 Istio 遷移至 Cloud Service Mesh，且應用程式沒有任何停機時間。
還原變更
在本節中，如果您不想繼續使用 Cloud Service Mesh，可以回復 Cloud Service Mesh 的變更。完成這個部分後，工作負載會移回 Istio on GKE。
回復異動 Webhook 的變更：
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook執行下列指令，重新標記命名空間，以便在 GKE 側載程式注入作業中使用 Istio，而非 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針對命名空間中的所有部署作業執行滾動式重新啟動作業：
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 版本，確認您已在 GKE v1.4 Envoy Proxy 上部署 Istio：
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 上的變更還原至 GKE。
部署 Online Boutique
在本節中，您將部署名為 Online Boutique 的微服務範例應用程式至 GKE 叢集。線上精品店會部署在支援 Istio 的命名空間中。您可以驗證應用程式是否正常運作，以及 GKE 上的 Istio 是否會將補充 Proxy 插入每個 Pod。
如果您已有含有應用程式的現有叢集，可以略過建立新命名空間和部署線上精品店的步驟。您可以按照「將工作負載遷移至 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 附屬 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 中檢查附加 Envoy Proxy 版本，確認已在部署的 GKE v1.4 Envoy Proxy 上安裝 Istio：
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 的常見問題和相關解答。
為什麼要從 Istio on GKE 遷移至 Cloud Service Mesh？
Istio on Google Kubernetes Engine 是一種 Beta 版功能，可在 Google Kubernetes Engine (GKE) 叢集中部署 Google 代管的 Istio。Istio on GKE 部署了不支援的版本 (Istio 1.4 版)。為提供最新的服務網格功能和支援的服務網格實作項目，我們會將 GKE 使用者在 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。
- 提供立即可用的遙測資訊主頁和服務等級目標管理功能，無須管理其他第三方解決方案。
- Google 代管的憑證授權單位選項。
- 整合 Google Cloud 網路和 Identity-Aware Proxy (IAP)。
- 支援混合雲和多雲端平台。
如要進一步瞭解 Cloud Service Mesh 的功能和能力，請參閱「Google 代管控制層支援的功能」。
這項遷移作業是否會造成停機？
遷移指令碼的設計目的是避免停機時間。此指令碼會將 Cloud Service Mesh 做為測試版控制層安裝，並與現有的 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 上的獨立產品 (在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 支援」。