原地 CA 遷移

如要使用以 Canary 為基礎的方法，從 Istio CA 遷移至 Mesh CA，並且不 (或盡量不) 造成停機時間，請參閱「以 Canary 為基礎的遷移至 Mesh CA」。

如果您的網格中有多個叢集，且其中的工作負載會將要求傳送至另一個叢集的工作負載，請針對所有叢集執行本指南中的所有步驟。

請按照本指南中的步驟，執行下列用途：

• 將叢集內的 Cloud Service Mesh 1.13 以上版本控制層，搭配 Mesh CA 遷移至憑證授權單位服務。
• 在對應至 1.13 以上版本的發布版本中，將代管的 Cloud Service Mesh 控制層遷移至 Mesh CA 到憑證授權單位服務。

限制

原地 CA 遷移和升級作業僅支援 Cloud Service Mesh 1.13 以上版本。針對受管理的控制平面遷移作業，請確認所選管道對應至 1.13 以上版本。

事前準備

在按照本指南中的步驟操作前，請確認您已完成以下事項：

• 已授予叢集管理員權限
• 已設定 gcloud

此外，請確認您目前使用的是 Cloud Service Mesh 1.13 以上版本。

必要工具

在遷移期間，您會執行 Google 提供的工具 migrate_ca。此工具有下列相依項目：

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

下載 migrate_ca 工具前，請按照遷移前的準備工作中的步驟操作。

遷移作業總覽

在遷移期間，使用舊 CA 的工作負載和使用新 CA 的工作負載之間，驗證和授權功能都會完全正常運作。

migrate_ca 遷移工具會建立 Kubernetes 設定對應表，以便追蹤每個已安裝的 Cloud Service Mesh 修訂版本/管道的 CA 遷移狀態。這是在 istio-system 命名空間中安裝的特權資源。

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

遷移工具會先備份 Istio MeshConfig 設定對應項目，再進行修改，並盡可能使用 ProxyConfig CRD 遷移 CA 設定。

以下是 CA 遷移作業的概略說明：

注意： 您必須在網格中的每個叢集上執行遷移步驟。

1. 準備遷移。

2. 初始化新的 CA。

3. 為機群中的所有叢集新增網格層級信任錨點。

4. 遷移 CA。

5. 執行回溯作業。

準備遷移

1. 下載 migrate_ca bash 工具：

   curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
   

2. 將工具設為可執行檔：

   chmod +x migrate_ca
   

3. 設定工作目錄：

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   注意： 如果未指定工作目錄，系統會建立暫時目錄。您必須將其用作後續所有步驟的工作目錄。

4. 將工作目錄變更為上一個步驟指定的 OUTPUT_DIR

   cd OUTPUT_DIR
   

5. 執行下列指令，確保已滿足所有必要條件：

   ./migrate_ca check-prerequisites
   

6. 請記下與要遷移的舊 CA 相關聯的控制層修訂版本 (ASM_REVISION)。所需步驟取決於控制層的類型 (叢集內或受管理)。

   叢集內

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   代管

   參考已安裝的管道。

7. 由於原地 CA 遷移作業需要重新啟動工作負載，請確認Pod 中斷預算已正確設定，且所有需要遷移 CA 的應用程式都設有一個以上的執行中 Pod。

8. 請確認叢集已註冊至機群，且叢集中已啟用工作負載身分。接著，請記下車隊專案 ID (FLEET_ID)，以利後續步驟。

9. 這項工具會接受 kubeConfig 和 kubeContext，用於選取要執行作業的叢集。如果未傳入這些引數，系統會使用預設的內容/設定。

   • 如要將 GKE 叢集的憑證新增至 kubeConfig，請使用下列指令：

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • 如要變更目前的 kubectl 背景資訊，或將背景資訊傳遞至工具，請使用下列指令：

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

初始化新的 CA

1. 初始化新 CA 所需的步驟取決於您要遷移至哪個新 CA。在您要遷移 CA 的每個機群叢集中執行這些步驟。

   Mesh CA

   呼叫公用工具 initialize 子指令。

   如果您要指定自訂 Kubernetes 設定：

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   如果是其他情況：

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   CA 服務

   a. 請按照初始化憑證授權單位服務的必要步驟操作。請記下 CA_POOL。

   b. 呼叫公用工具 initialize 子指令：

   如果您要指定自訂 Kubernetes 設定：

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   如果是其他情況：

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

為機群中的所有叢集新增網格層級信任錨點

1. 針對機群中的所有叢集，針對新 CA 和舊 CA 重複執行下列步驟。

2. 下載 CA 的信任錨點：

   Mesh CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   CA 服務

   將 CA 憑證儲存在檔案中：

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. 新增 CA 的信任錨點：

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. 確認信任錨點已由機隊中的所有工作負載接收。在命名空間引數中，傳遞部署工作負載的所有命名空間：

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   預期輸出內容：

   Check the CA cert in namespace nsa-1-24232                                                                                                                               
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

遷移 CA

1. 遷移 CA 設定。所需的指令取決於您要遷移至的新 CA。

   Mesh CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   CA 服務

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. 重新啟動所有工作負載。

   注意： 如果您已安裝受管理的資料平面，則此為可選步驟。這是因為 Google 會管理 Proxy 生命週期，並在受管理的升級期間自動執行這個步驟。

   為盡可能降低 TLS 流量停機的風險，這個步驟應先影響最少數量的工作負載。只重新啟動與控制平面修訂版本 ASM_REVISION 相關的工作負載。舉例來說，如果 Kubernetes 命名空間 NAMESPACE 中的所有工作負載都與相同的 Cloud Service Mesh 控制平面相關聯。

   kubectl rollout restart deployment -n NAMESPACE
   

3. 請先驗證重新啟動的命名空間中的工作負載與其他工作負載之間的 mTLS 連線是否正常運作，再針對所有命名空間和機隊中的所有叢集重複執行步驟 1 和 2。如果有新的工作負載正在啟動，且網格流量未中斷，請針對機隊中的所有命名空間和叢集重複執行步驟 1 和 2。否則，請繼續執行回溯作業，以便回溯較新的 CA 設定。

4. 確認所有工作負載都使用新的 CA 設定：

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   預期輸出內容：

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

執行回溯

1. 復原 CA 設定，並移除新設定的 trustAnchors：

   ./migrate-ca rollback
   

2. 重新啟動所有工作負載。請務必只重新啟動與控制平面修訂版本 ASM_REVISION 相關聯的工作負載。舉例來說，如果 Kubernetes 命名空間 NAMESPACES 中的所有工作負載都與相同的 Cloud Service Mesh 控制平面相關聯。

   kubectl rollout restart deployment -n NAMESPACES
   

3. (選用) 確認所有工作負載都使用舊版 CA 設定。

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. 針對機群中所有叢集 (工作負載使用 ASM_REVISION 控制平面)，重複執行步驟 1 至 3。

恭喜！您已成功執行原地 CA 遷移作業。