以 Canary 為基礎的遷移至 Mesh CA

如要在不遷移控制平面情況下，以最短的停機時間遷移 CA，請參閱「原地 CA 遷移」。

從 Istio CA (也稱為 Citadel) 遷移至 Cloud Service Mesh 憑證授權單位 (Mesh CA) 時，需要遷移信任根。在 Cloud Service Mesh 1.10 之前，如果您想從 Google Kubernetes Engine (GKE) 上的 Istio 遷移至搭配 Mesh CA 的 Cloud Service Mesh，就必須安排停機時間，因為 Cloud Service Mesh 無法載入多個根憑證。因此，在遷移期間，新部署的工作負載會信任新的根憑證，而其他工作負載則會信任舊的根憑證。使用不同根憑證簽署的憑證的工作負載無法相互驗證。也就是說，雙向傳輸層安全標準 (mTLS) 流量會在遷移期間中斷。只有在控制層和所有命名空間中的所有工作負載都使用 Mesh CA 的憑證重新部署時，整個叢集才能完全復原。如果您的網格有包含工作負載的多個叢集，且這些工作負載會將要求傳送至另一個叢集的工作負載，則這些叢集中的所有工作負載也都需要更新。

請在下列用途中使用本指南中的步驟：

• 使用 Mesh CA，從 GKE 上的 Istio 遷移至 Cloud Service Mesh 叢集內控制層。 1.26.4-asm.1
• 從使用 Istio CA 的 Cloud Service Mesh 1.15 或 1.16 修補程式版本 升級至使用 Mesh CA 的 Cloud Service Mesh 1.26.4-asm.1 叢集內控制層。

限制

• 所有 GKE 叢集都必須位於同一個 Google Cloud 專案中。

事前準備

按照「安裝依附工具並驗證叢集」中的步驟操作：

• 安裝必要工具
• 下載 asmcli
• 授予叢集管理員權限
• 驗證專案和叢集

必要工具

在遷移期間，您可以執行 Google 提供的工具 migrate_ca，為叢集中的每個 Pod 驗證下列項目：

• Istio CA 和 Mesh CA 的根憑證。
• 由 Istio CA 和 Mesh CA 核發的工作負載 mTLS 憑證。
• Istio CA 和 Mesh CA 設定的信任網域。

這項工具有下列依附元件：

• awk
• grep
• istioctl 執行 asmcli install 會下載與您要安裝的 Cloud Service Mesh 版本相符的 istioctl 版本。
• jq
• kubectl
• openssl

遷移作業總覽

如要遷移至 Mesh CA，請按照修訂版本遷移程序 (也稱為「測試版升級」) 進行。在以修訂版本為基礎的遷移作業中，系統會同時部署新的控制層修訂版本和現有控制層。接著，您可以逐步將工作負載移至新修訂版本，以便監控遷移程序的效果。在遷移過程中，使用 Mesh CA 的工作負載和使用 Istio CA 的工作負載之間的驗證和授權功能都會正常運作。

以下是遷移至 Mesh CA 的概略說明：

1. 發布 Mesh CA 信任根。

   1. 安裝新的控制平面修訂版本，使用 Istio CA 和可發布 Mesh CA 信任根的選項。

   2. 將工作負載逐一遷移至新的控制層和命名空間，然後測試應用程式。所有工作負載都已成功遷移至新的控制層後，請移除舊的控制層。

2. 遷移至 Mesh CA。由於所有附屬 Proxy 都已設定舊信任根和 Mesh CA 信任根，您可以無需停機即可遷移至 Mesh CA。請再次按照修訂版本遷移程序操作：

   1. 安裝啟用 Mesh CA 的控制層修訂版本。

   2. 將工作負載遷移至新的控制平面修訂版本，並依命名空間逐一測試應用程式。所有工作負載都已成功遷移至新的控制層後，請移除舊的控制層。

   3. 移除叢集中與舊 CA 相關聯的 CA 密鑰，然後重新啟動新的控制平面。

發布 Mesh CA 信任根

您必須先將網格中的所有 GKE 叢集遷移至 Cloud Service Mesh 1.10 以上版本，並為所有叢集設定控制平面選項，觸發 Mesh CA 信任根，再將其分發至叢集中所有工作負載的 Proxy。程序完成後，每個 Proxy 都會同時設定舊信任根與新信任根。使用這個配置時，當您遷移至 Mesh CA 時，使用 Mesh CA 的工作負載將能夠與使用舊版 CA 的工作負載進行驗證。

安裝新的控制層修訂版本

安裝控制層修訂版本，並使用可發布 Mesh CA 信任根的選項。

1. 請按照「安裝依附工具並驗證叢集」中的步驟，準備使用 Google 提供的工具 asmcli 來安裝新的控制層修訂版本。

2. 請確認您安裝的 asmcli 版本會安裝 Cloud Service Mesh 1.11 以上版本：

   ./asmcli --version
   

3. 執行 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。
• --kubeconfig kubeconfig 檔案的路徑。您可以指定相對路徑或完整路徑。環境變數 $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 重新部署工作負載時，這個選項會觸發新的信任根，並將其分發至工作負載的附屬代理程式。
• REVISION_1：建議。修訂版本標籤是控制平面上設定的鍵/值組合。修訂版本標籤鍵一律為 istio.io/rev。根據預設，這項工具會根據 Cloud Service Mesh 版本設定修訂版本標籤的值，例如：asm-1264-1。建議您加入這個選項，並將 REVISION_1 替換為描述安裝作業的名稱，例如 asm-1264-1-distribute-root。名稱必須是 DNS-1035 標籤，且必須由小寫英數字元或 - 組成，開頭和結尾須為英文字元，並以英數字元結尾 (例如 my-name 或 abc-123)。

將工作負載遷移至新控制層

如要完成新信任根的發布作業，您必須使用修訂版本標籤 istio.io/rev=<var>REVISION_1</var>-distribute-root 為命名空間加上標籤，並重新啟動工作負載。重新啟動工作負載後，您可以執行工具來驗證附加式 Proxy 是否已設定 Mesh CA 的舊和新信任根。

1. 設定 kubectl 的目前背景資訊。如果您有單一區域叢集，請在下列指令中將 --region 變更為 --zone。

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --region=CLUSTER_LOCATION
   

2. 下載驗證工具：

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

3. 在工具上設定可執行位元：

   chmod +x migrate_ca
   

4. migrate_ca 工具會呼叫 istioctl，這取決於版本。asmcli 工具會在您為 --output_dir 指定的目錄中，將符號連結新增至 istioctl。請確認目錄位於路徑的開頭。在下列指令中，將 ISTIOCTL_PATH 替換為包含工具下載的 istioctl 的目錄。

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. 取得 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

   1. 在輸出內容的 REV 欄下，記下新修訂版本的修訂版本標籤值，該值與您執行 asmcli install 時指定的修訂版本標籤相符。在這個範例中，這個值為 asm-1264-1-distribute-root。

   2. 將工作負載移至新修訂版本後，您需要刪除 istiod 的舊修訂版本。請注意舊版 istiod 修訂版本的修訂標籤中的值。範例輸出內容顯示從 Istio 遷移，該服務使用 default 修訂版本。

6. 將修訂版本標籤新增至命名空間，並移除 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 指令都會明確確保只設定一個。

7. 重新啟動 Pod 以觸發重新注入。

   kubectl rollout restart deployment -n NAMESPACE
   

8. 測試應用程式，確認工作負載是否正常運作。

9. 如果您在其他命名空間中擁有工作負載，請重複執行上述步驟，為命名空間加上標籤並重新啟動 Pod。

10. 驗證叢集中所有工作負載的附屬代理伺服器是否已同時設定舊版和新版的根憑證：

    ./migrate_ca check-root-cert
    

    預期輸出內容：

    Namespace: foo
    httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
    sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

11. 如果您需要遷移閘道，請按照「Canary 升級 (進階)」中的步驟，安裝新的閘道部署。請記住以下要點：

    • 使用 REVISION_1 做為修訂版本標籤。
    • 將閘道資源部署在舊版安裝程序的閘道所在的同一命名空間中，以便執行零停機時間遷移。請確認指向舊版閘道的服務資源現在也應包含較新的部署作業。
    • 在確認應用程式運作正常 (下一個步驟後) 之前，請勿刪除舊的閘道部署作業。

12. 如果您認為應用程式運作正常，請繼續按照步驟改用新版 istiod。如果應用程式發生問題，請按照步驟進行回復。

    完成轉換

    如果您認為應用程式運作正常，請移除舊控制平面，完成改用新版本的程序。

    1. 切換至 anthos-service-mesh GitHub 存放區檔案所在的目錄。

    2. 設定驗證 webhook，以便使用新的控制層。

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. 刪除舊的 istio-ingressgateway 部署。您執行的指令取決於您是要從 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
       

    4. 刪除 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
       

    5. 移除舊版 IstioOperator 設定。

       kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
       

       預期的輸出內容會與下列內容相似：

       istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    復原

    如果您在使用新版 istiod 測試應用程式時遇到問題，請按照下列步驟將應用程式回溯至先前版本：

    1. 刪除在步驟 11 中安裝的新閘道部署。

    2. 重新標記命名空間，以便使用先前版本的 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

    3. 確認命名空間的修訂版本標籤與 istiod 舊版的修訂版本標籤相符：

       kubectl get ns NAMESPACE --show-labels
       

    4. 重新啟動 Pod 以觸發重新注入，讓 Proxy 取得先前的版本：

       kubectl rollout restart deployment -n NAMESPACE
       

    5. 移除新的 istio-ingressgateway 部署。

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
       

    6. 移除 istiod 的新修訂版本。

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
       

    7. 移除新的 IstioOperator 設定。

       kubectl delete IstioOperator installed-state-asm-1264-1-distribute-root -n istio-system
       

       預期的輸出內容會與下列內容相似：

       istiooperator.install.istio.io "installed-state-asm-1264-1-distribute-root" deleted

遷移至 Mesh CA

由於所有工作負載的附屬代理程式都已同時設定舊信任根和 Mesh CA 的新信任根，因此遷移至 Mesh CA 的步驟與您發布 Mesh CA 信任根的步驟類似：

安裝啟用 Mesh CA 的新控制層

您使用 asmcli install 安裝已啟用 Mesh CA 的新控制平面修訂版本。

1. 如果您先前已自訂安裝作業，則執行 asmcli install 時，您需要指定相同的疊加檔案。

2. 執行 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。
   • --kubeconfig kubeconfig 檔案的路徑。您可以指定相對路徑或完整路徑。環境變數 $PWD 在這裡無效。
   • --output_dir 加入這個選項，即可指定 asmcli 下載 anthos-service-mesh 套件並擷取安裝檔案的目錄，其中包含 istioctl、範例和資訊清單。否則，asmcli 會將檔案下載至 tmp 目錄。您可以指定相對路徑或完整路徑。環境變數 $PWD 在這裡無效。
   • --enable_all 允許工具執行以下操作：
     • 授予必要的 IAM 權限。
     • 啟用必要的 Google API。
     • 為叢集設定可識別網格的標籤。
     • 如果叢集尚未註冊至機群，請 將叢集註冊。

   • --ca mesh_ca 由於 Mesh CA 信任根已發布，您現在可以切換至 Mesh CA。
   • REVISION_2 建議。將 REVISION_2 替換為描述安裝作業的名稱，例如 asm-1264-1-meshca-ca-migration。名稱必須是 DNS-1035 標籤，且只能使用小寫英數字元或 -，開頭和結尾須為英文字母，並以英數字元結尾 (例如 my-name 或 abc-123)。
   • --option ca-migration-migration 當您重新部署工作負載時，這個選項會將 Proxy 設為使用 Mesh CA 信任根。

將工作負載遷移至新控制層

如要完成安裝作業，您必須為命名空間加上新的修訂版本標籤，並重新啟動工作負載。

1. 取得 istiod 和 istio-ingressgateway 上的修訂標籤。

   kubectl get pod -n istio-system -L istio.io/rev
   

   輸出結果會與下列內容相似：

   NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-asm-1264-1-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1264-1-distribute-root
   istio-ingressgateway-asm-1264-1-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1264-1-distribute-root
   istio-ingressgateway-asm-1264-1-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1264-1-meshca-ca-migration
   istio-ingressgateway-asm-1264-1-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1264-1-meshca-ca-migration
   istiod-asm-1264-1-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1264-1-distribute-root
   istiod-asm-1264-1-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1264-1-distribute-root
   istiod-asm-1264-1-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1264-1-meshca-ca-migration
   istiod-asm-1264-1-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1264-1-meshca-ca-migration

   1. 在輸出內容的 REV 欄下，記下新版本修訂版本標籤的值。在這個範例中，這個值為 asm-1264-1-meshca-ca-migration。

   2. 請注意舊版 istiod 的修訂版本標籤中的值。當您完成將工作負載遷移至新版本的作業後，就需要這個值來刪除舊版 istiod。在這個範例中，上一個修訂版本的修訂標籤值為 asm-1264-1-distribute-root。

2. 將新修訂版本標籤新增至命名空間。在下列指令中，將 NAMESPACE 替換為要標示的命名空間。

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
   

3. 重新啟動 Pod 以觸發重新注入。

   kubectl rollout restart deployment -n NAMESPACE
   

4. 測試應用程式，確認工作負載是否正常運作。請確認 mTLS 通訊可在舊命名空間和新命名空間的工作負載之間運作。

5. 如果其他命名空間中有工作負載，請重複執行上述步驟，為命名空間加上標籤並重新啟動 Pod。

6. 請按照原地升級中的步驟，將上一節步驟 11 中安裝的舊版閘道部署升級至最新修訂版 REVISION_2。

7. 如果您認為應用程式運作正常，請繼續執行轉換至新控制平面的步驟。如果應用程式發生問題，請按照步驟進行回復。

   完成轉換

   如果您認為應用程式運作正常，請移除舊控制平面，完成改用新版本的程序。

   1. 切換至 anthos-service-mesh GitHub 存放區檔案所在的目錄。

   2. 設定驗證 webhook，以便使用新的控制層。

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. 刪除舊的 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
      

   4. 刪除舊的 istiod 修訂版本。在下列指令中，將 OLD_REVISION 替換為先前版本 istiod 的修訂版本標籤。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. 移除舊的 IstioOperator 設定。

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      預期的輸出內容會與下列內容相似：

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   復原

   如果您在使用新版 istiod 修訂版本測試應用程式時遇到問題，請按照下列步驟還原至先前版本：

   1. 請按照原地升級一節中的步驟，將先前在本節第 6 步驟升級的閘道部署降級至舊版 REVISION_1。

   2. 重新標記命名空間，以便啟用先前 istiod 修訂版本的自動注入功能。

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
      

      預期輸出內容：

      namespace/NAMESPACE labeled

   3. 確認命名空間的修訂版本標籤與 istiod 舊版的修訂版本標籤相符：

      kubectl get ns NAMESPACE --show-labels
      

   4. 重新啟動 Pod 以觸發重新注入，讓 Proxy 取得先前的版本：

      kubectl rollout restart deployment -n NAMESPACE
      

   5. 移除新的 istio-ingressgateway 部署。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
      

   6. 移除新版 istiod。請確認下列指令中的修訂版本標籤與您的修訂版本相符。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
      

   7. 移除新版 IstioOperator 設定。

      kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
      

      預期的輸出內容會與下列內容相似：

      istiooperator.install.istio.io "installed-state-REVISION_2" deleted

移除 CA 密鑰，並重新啟動新的控制平面

1. 保留機密資訊，以備不時之需：

   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
   

2. 移除與舊 CA 相關聯的叢集中的 CA 密鑰：

   kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
   

3. 重新啟動新安裝的控制層。這可確保在網格中執行的所有工作負載都會清除舊信任根。

   kubectl rollout restart deployment -n istio-system