以 Canary 為基礎遷移至 Mesh CA
如要在停機時間最短的情況下遷移 CA，且不遷移控制平面，請參閱「就地遷移 CA」。如要從 Istio CA (也稱為 Citadel) 遷移至 Cloud Service Mesh 憑證授權單位 (網格憑證授權單位)，必須遷移信任根。在 Cloud Service Mesh 1.10 之前，如要從 Google Kubernetes Engine (GKE) 上的 Istio 遷移至採用 Mesh CA 的 Cloud Service Mesh，您必須安排停機時間，因為 Cloud Service Mesh 無法載入多個根憑證。因此，在遷移期間，新部署的工作負載會信任新的根憑證，其他工作負載則會信任舊的根憑證。使用由不同根憑證簽署的憑證，工作負載就無法相互驗證。也就是說，遷移期間相互傳輸層安全標準 (mTLS) 流量會中斷。只有在控制層和所有命名空間中的所有工作負載，都使用 Mesh CA 的憑證重新部署後，整個叢集才會完全復原。如果網格有多個叢集，且工作負載會將要求傳送至其他叢集的工作負載，則這些叢集的所有工作負載也需要更新。
請按照本指南中的步驟操作，以因應下列用途：
- 從 GKE 上的 Istio 遷移至 Cloud Service Mesh 1.28.7-asm.3 叢集內控制層和網格憑證授權單位。
- 從使用 Istio CA 的 Cloud Service Mesh 1.15 或 1.16 修補程式版本 升級至使用網格 CA 的 Cloud Service Mesh 1.28.7-asm.3 叢集內控制層。
限制
- 所有 GKE 叢集都必須位於同一 Google Cloud 專案中。
必要條件
按照「安裝依附工具並驗證叢集」中的步驟操作，以便：必要工具
在遷移期間，您會執行 Google 提供的 migrate_ca 工具，驗證叢集中每個 Pod 的下列項目：
- Istio CA 和網格 CA 的根憑證。
- 由 Istio CA 和網格 CA 核發的工作負載 mTLS 憑證。
- 由 Istio CA 和網格 CA 設定的信任網域。
這項工具需要下列依附元件：
awkgrepistioctl執行asmcli install會下載與您安裝的 Cloud Service Mesh 版本相符的istioctl版本。jqkubectlopenssl
遷移作業總覽
如要遷移至 Mesh CA，請按照修訂版本遷移程序操作 (也稱為「金絲雀升級」)。透過以修訂版本為準的遷移作業，系統會與現有控制層一併部署新的控制層修訂版本。然後逐步將工作負載移至新修訂版本，以便在遷移過程中監控遷移效果。在遷移過程中，使用網格憑證授權單位的工作負載，以及使用 Istio 憑證授權單位的工作負載，都能正常進行驗證和授權。
以下是遷移至 Mesh CA 的概要步驟：
發布 Mesh CA 信任根。
安裝使用 Istio CA 的新控制層修訂版本，並透過選項發布網格 CA 信任根。
將工作負載逐一遷移至新的控制層和命名空間，並測試應用程式。所有工作負載都成功遷移至新控制層後，請移除舊控制層。
遷移至 Mesh CA。所有 Sidecar Proxy 都已設定舊的信任根和網格 CA 信任根，因此您可以遷移至網格 CA，不會發生停機情形。同樣地，您會按照修訂版本遷移程序操作：
安裝已啟用 Mesh CA 的控制層修訂版本。
將工作負載逐一遷移至新控制層修訂版本和命名空間，然後測試應用程式。所有工作負載都成功遷移至新的控制層後，請移除舊的控制層。
移除叢集中與舊版 CA 相關聯的 CA 密鑰，然後重新啟動新的控制層。
發布 Mesh CA 信任根
如要遷移至 Mesh CA，網格中的所有 GKE 叢集都必須使用 Cloud Service Mesh 1.10 以上版本，且所有叢集都必須設定控制層選項，以觸發 Mesh CA 的信任根，並將其分配至叢集上所有工作負載的 Proxy。程序完成後，每個 Proxy 都會設定舊版和新版信任根。採用這項配置後，遷移至 Mesh CA 時，使用 Mesh CA 的工作負載就能向使用舊版 CA 的工作負載進行驗證。
安裝新的控制層修訂版本
安裝控制層修訂版本，並選擇要分配 Mesh CA 信任根的選項。
請按照「安裝相依工具並驗證叢集」一文中的步驟操作，準備使用 Google 提供的工具
asmcli安裝新的控制層修訂版本。確認您使用的
asmcli版本會安裝 Cloud Service Mesh 1.11 以上版本：./asmcli --version
執行
asmcli install。 請將下列指令中的預留位置替換為您的值。./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH
--fleet_id機群主專案的專案 ID。--kubeconfigkubeconfig檔案的路徑 您可以指定相對路徑或完整路徑。環境變數$PWD在這裡無法運作。--output_dir：加入這個選項可指定目錄，asmcli會將anthos-service-mesh套件下載至該目錄，並解壓縮安裝檔案，其中包含istioctl、範例和資訊清單。否則，asmcli會將檔案下載至tmp目錄。 您可以指定相對路徑或完整路徑。環境變數$PWD在這裡無法運作。-
--enable_all允許工具執行下列操作：- 授予必要的 IAM 權限。
- 啟用必要的 Google API。
- 在叢集上設定標籤，以識別網格。
- 向機群註冊叢集 (如果尚未註冊)。
-ca citadel為避免停機，請指定 Istio CA (citadel選項對應於 Istio CA)。此時請勿切換至 Mesh CA。--ca_cert中繼憑證。--ca_key中繼憑證的金鑰--root_cert根憑證。--cert_chain憑證鏈結。--option ca-migration-citadel重新部署工作負載時，這個選項會觸發新的信任根目錄，並將其分配給工作負載的 Sidecar Proxy。REVISION_1：建議使用。修訂版本標籤是控制層上設定的鍵/值組合。修訂版本標籤鍵一律為istio.io/rev。根據預設，這項工具會根據 Cloud Service Mesh 版本設定修訂版本標籤的值，例如：asm-1287-3。建議您加入這個選項，並將REVISION_1替換為描述安裝作業的名稱，例如asm-1287-3-distribute-root。名稱必須是 DNS-1035 標籤，且只能使用小寫英數字元或-，開頭須為英文字母，結尾則須為英數字元 (例如my-name或abc-123)。
將工作負載遷移至新的控制層
如要完成發布新的信任根，您需要使用修訂標籤 istio.io/rev=<var>REVISION_1</var>-distribute-root 標記命名空間，然後重新啟動工作負載。重新啟動工作負載後，請執行工具，驗證 Sidecar Proxy 是否已設定網狀架構 CA 的舊版和新版信任根。
設定
kubectl的目前背景資訊。在下列指令中，如果叢集屬於單一區域，請將--region變更為--zone。gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION下載驗證工具：
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
在工具上設定可執行位元：
chmod +x migrate_ca
migrate_ca工具會呼叫istioctl，而這取決於版本。asmcli工具會在您為--output_dir指定的目錄中，將符號連結新增至istioctl。請確認該目錄位於路徑開頭。在下列指令中，將ISTIOCTL_PATH替換為包含工具下載的istioctl的目錄。export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
取得
istiod和istio-ingressgateway上的修訂標籤。kubectl get pod -n istio-system -L istio.io/rev
輸出結果會與下列內容相似：
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-5fd454f8ff-t7w9x 1/1 Running 0 36m default istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p 1/1 Running 0 18m asm-195-2-distribute-root istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs 1/1 Running 0 18m asm-195-2-distribute-root istiod-68bc495f77-shl2h 1/1 Running 0 36m default istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c 1/1 Running 0 18m asm-195-2-distribute-root istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s 1/1 Running 0 18m asm-195-2-distribute-root
在輸出內容的
REV欄下方，記下新修訂版本的修訂版本標籤值，該值與您執行asmcli install時指定的修訂版本標籤相符。在本範例中，這個值為asm-1287-3-distribute-root。將工作負載移至新修訂版本後，請刪除舊修訂版本
istiod。請記下舊版istiod的修訂版本標籤值。輸出範例顯示從 Istio 遷移的作業，該作業使用default修訂版本。
將修訂版本標籤新增至命名空間，並移除
istio-injection標籤 (如有)。在下列指令中，將NAMESPACE替換為要標記的命名空間。kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
如果輸出內容顯示
"istio-injection not found"，可以忽略。也就是說，命名空間先前沒有istio-injection標籤。如果命名空間同時有istio-injection和修訂版本標籤，自動插入行為會不確定，因此 Cloud Service Mesh 文件中的所有kubectl label指令都會明確確保只設定其中一個標籤。重新啟動 Pod，觸發重新注入。
kubectl rollout restart deployment -n NAMESPACE
測試應用程式，確認工作負載是否正常運作。
如果其他命名空間也有工作負載，請重複上述步驟，為命名空間加上標籤並重新啟動 Pod。
確認叢集上所有工作負載的 Sidecar Proxy 都已設定新舊根憑證：
./migrate_ca check-root-cert
預期輸出內容：
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
如要遷移閘道，請按照「Canary 升級 (進階)」中的步驟操作，安裝新的閘道部署作業。請記住以下要點：
- 使用
REVISION_1做為修訂版本標籤。 - 在與舊版安裝的閘道相同的命名空間中部署閘道資源，執行零停機時間遷移。請確保指向舊版閘道的服務資源現在也包含較新的部署作業。
- 在確認應用程式運作正常前 (下一個步驟完成後)，請勿刪除舊版閘道部署作業。
- 使用
如果確認應用程式運作正常，請繼續執行步驟，改用新版
istiod。如果應用程式有問題，請按照步驟復原。完成轉換
確認應用程式運作正常後，請移除舊版控制平面，完成新版轉換作業。
切換至
anthos-service-meshGitHub 存放區檔案所在的目錄。將驗證 Webhook 設為使用新的控制層。
kubectl apply -f asm/istio/istiod-service.yaml
刪除舊的
istio-ingressgatewayDeployment。執行的指令取決於您是從 Istio 遷移，還是從舊版 Cloud Service Mesh 升級：遷移
如果您是從 Istio 遷移，舊版
istio-ingressgateway沒有修訂版本標籤。kubectl delete deploy/istio-ingressgateway -n istio-system
升級
如果您是從舊版 Cloud Service Mesh 升級，請在下列指令中，將
OLD_REVISION替換為舊版istio-ingressgateway的修訂版本標籤。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
刪除「
istiod」的舊修訂版本。使用的指令取決於您是從 Istio 遷移，還是從舊版 Cloud Service Mesh 升級。遷移
如果您是從 Istio 遷移，舊版
istio-ingressgateway沒有修訂版本標籤。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
升級
如果您是從舊版 Cloud Service Mesh 升級，請確保下列指令中的
OLD_REVISION與舊版istiod的修訂版本標籤相符。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
移除舊版
IstioOperator設定。kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
預期輸出內容如下：
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
復原
如果您在使用新版
istiod測試應用程式時遇到問題，請按照下列步驟還原至舊版：刪除在步驟 11 安裝的新閘道部署。
重新標記命名空間，以啟用自動插入功能，並使用舊版
istiod。使用的指令取決於您是否使用修訂版本標籤，或搭配先前的版本使用istio-injection=enabled。如果您使用修訂版本標籤自動插入：
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
如果您使用
istio-injection=enabled：kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
預期輸出內容：
namespace/NAMESPACE labeled
確認命名空間的修訂版本標籤與先前版本的
istiod修訂版本標籤相符：kubectl get ns NAMESPACE --show-labels
重新啟動 Pod，觸發重新注入程序，讓 Proxy 採用先前版本：
kubectl rollout restart deployment -n NAMESPACE
移除新的
istio-ingressgatewayDeployment。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
移除「
istiod」的新修訂版本。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
移除新的
IstioOperator設定。kubectl delete IstioOperator installed-state-asm-1287-3-distribute-root -n istio-system
預期輸出內容如下：
istiooperator.install.istio.io "installed-state-asm-1287-3-distribute-root" deleted
遷移至 Mesh CA
現在所有工作負載的 Sidecar Proxy 都已設定 Mesh CA 的舊信任根和新信任根，因此遷移至 Mesh CA 的步驟與您發布 Mesh CA 信任根的步驟類似：
安裝已啟用 Mesh CA 的新控制層
您可以使用 asmcli install 安裝已啟用 Mesh CA 的新控制層修訂版本。
如果您自訂了先前的安裝作業，執行
asmcli install時，必須指定相同的疊加檔案。執行
asmcli install。 在下列指令中，將預留位置換成您的值。./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --enable_all \ --ca mesh_ca \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
--fleet_id機群主專案的專案 ID。--kubeconfigkubeconfig檔案的路徑 您可以指定相對路徑或完整路徑。環境變數$PWD在這裡無法運作。--output_dir加入這個選項，即可指定asmcli下載anthos-service-mesh套件並解壓縮安裝檔案的目錄，其中包含istioctl、範例和資訊清單。否則，asmcli會將檔案下載至tmp目錄。您可以指定相對路徑或完整路徑。環境變數$PWD在這裡無法運作。-
--enable_all允許工具執行下列操作：- 授予必要的 IAM 權限。
- 啟用必要的 Google API。
- 在叢集上設定標籤，以識別網格。
- 向機群註冊叢集 (如果尚未註冊)。
--ca mesh_caMesh CA 信任根已發布，因此現在可以切換至 Mesh CA。REVISION_2建議。將REVISION_2替換成描述安裝作業的名稱，例如asm-1287-3-meshca-ca-migration。名稱必須是 DNS-1035 標籤，且只能使用小寫英數字元或-，開頭須為英文字母，結尾則須為英數字元 (例如my-name或abc-123)。--option ca-migration-migration重新部署工作負載時，這個選項會將 Proxy 設為使用 Mesh CA 信任根。
將工作負載遷移至新的控制層
如要完成安裝程序，請使用新的修訂版本標籤標示命名空間，然後重新啟動工作負載。
取得
istiod和istio-ingressgateway上的修訂標籤。kubectl get pod -n istio-system -L istio.io/rev
輸出結果會與下列內容相似：
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-asm-1287-3-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1287-3-distribute-root istio-ingressgateway-asm-1287-3-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1287-3-distribute-root istio-ingressgateway-asm-1287-3-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1287-3-meshca-ca-migration istio-ingressgateway-asm-1287-3-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1287-3-meshca-ca-migration istiod-asm-1287-3-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1287-3-distribute-root istiod-asm-1287-3-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1287-3-distribute-root istiod-asm-1287-3-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1287-3-meshca-ca-migration istiod-asm-1287-3-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1287-3-meshca-ca-migration
在輸出內容的「
REV」欄下方，記下新版本的修訂標籤值。在本範例中，這個值為asm-1287-3-meshca-ca-migration。另請注意舊版
istiod的修訂標籤值。 將工作負載移至新版istiod後，您需要這個 ID 才能刪除舊版istiod。在這個範例中，前一修訂版本的修訂標籤值為asm-1287-3-distribute-root。
將新修訂版本標籤新增至命名空間。在下列指令中，將
NAMESPACE替換為要標記的命名空間。kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
重新啟動 Pod，觸發重新注入。
kubectl rollout restart deployment -n NAMESPACE
測試應用程式，確認工作負載正常運作。確認舊命名空間中的工作負載與新命名空間中的工作負載之間，可以透過 mTLS 通訊。
如果其他命名空間也有工作負載，請重複上述步驟，為命名空間加上標籤並重新啟動 Pod。
如果確認應用程式運作正常，請繼續執行步驟，改用新的控制層。如果應用程式有問題，請按照步驟復原。
完成轉換
確認應用程式運作正常後，請移除舊版控制平面，完成新版轉換作業。
切換至
anthos-service-meshGitHub 存放區檔案所在的目錄。將驗證 Webhook 設為使用新的控制層。
kubectl apply -f asm/istio/istiod-service.yaml
刪除舊的
istio-ingressgatewayDeployment。在下列指令中，將OLD_REVISION替換為istio-ingressgateway前一版本的修訂標籤。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
刪除舊的
istiod修訂版本。在下列指令中，將OLD_REVISION替換為istiod前一版本的修訂版本標籤。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
移除舊的
IstioOperator設定。kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
預期輸出內容如下：
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
復原
如果在測試應用程式時遇到問題，請按照下列步驟，將應用程式還原至先前的修訂版本：
istiod重新標記命名空間，以啟用先前
istiod修訂版本的自動插入功能。kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
預期輸出內容：
namespace/NAMESPACE labeled
確認命名空間的修訂版本標籤與先前版本的
istiod修訂版本標籤相符：kubectl get ns NAMESPACE --show-labels
重新啟動 Pod，觸發重新注入程序，讓 Proxy 採用先前版本：
kubectl rollout restart deployment -n NAMESPACE
移除新的
istio-ingressgatewayDeployment。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
移除新版
istiod。請確認下列指令中的修訂版本標籤與您的修訂版本相符。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
移除新版
IstioOperator設定。kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
預期輸出內容如下：
istiooperator.install.istio.io "installed-state-REVISION_2" deleted
移除 CA 密鑰，然後重新啟動新的控制平面
保留密鑰，以備不時之需：
kubectl get secret/cacerts -n istio-system -o yaml > save_file_1 kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
移除與舊 CA 相關聯的叢集中的 CA 密鑰：
kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
重新啟動新安裝的控制層。確保網格中執行的所有工作負載都已清除舊的信任根。
kubectl rollout restart deployment -n istio-system