升級 Cloud Service Mesh

本頁面說明如何：

• 執行 asmcli，即可從 Cloud Service Mesh 升級至 Cloud Service Mesh1.25.3。

• 視需要部署入口網站閘道。

• 進行 Canary 升級，將工作負載遷移至新的控制層。

您可以從哪個 Cloud Service Mesh 版本升級，這會因平台而異。

事前準備

開始之前，請確認下列事項：

• 詳閱必備條件。
• 詳閱規劃升級作業中的資訊。
• 安裝必要工具。
• 下載 asmcli。
• 授予叢集管理員權限。
• 驗證專案和叢集。

控制層自訂設定

如果您先前曾自訂安裝作業，升級至新版 Cloud Service Mesh 或從 Istio 遷移時，就需要進行相同的自訂設定。如果您透過在 istioctl install 中加入 --set values 標記來自訂安裝作業，則必須將這些設定加入 IstioOperator YAML 檔案 (稱為疊加檔案)。您可以在執行指令碼時，使用 --custom_overlay 選項搭配檔案名稱，指定疊加檔案。指令碼會將疊加層檔案傳遞至 istioctl install。

發證機構

在升級期間變更憑證授權單位 (CA) 會導致服務中斷。升級期間，mTLS 流量會中斷，直到所有工作負載都切換為使用新的控制層和新的 CA 為止。

升級 Cloud Service Mesh

以下概述如何升級 Cloud Service Mesh：

1. 如果您要升級使用 Cloud Service Mesh 憑證授權單位的 GKE 多叢集網格，請執行 asmcli create-mesh，將多叢集網格設為信任車隊工作負載身分，以便在升級期間進行跨叢集負載平衡，不必停機。

2. 執行 asmcli install 即可在單一叢集中安裝 Cloud Service Mesh。如需指令列範例，請參閱下列各節。範例包含您可能會覺得實用的必要引數和選用引數。建議您一律指定 output_dir 引數，以便輕鬆找出 istioctl 等樣本閘道和工具。請參閱右側的導覽列，查看範例清單。

3. 您可以選擇安裝或升級入口閘道。根據預設，asmcli 不會安裝 istio-ingressgateway。建議您分別部署及管理控制層和閘道。如果您需要透過叢集內控制層安裝預設 istio-ingressgateway，請加入 --option legacy-default-ingressgateway 引數。

4. 如要完成 Cloud Service Mesh 設定，您必須啟用自動附加元件注入功能，並部署或重新部署工作負載。

設定多叢集網格，信任機群工作負載身分

如果您要升級在 GKE 上使用 Cloud Service Mesh 憑證授權機構做為憑證授權機構的多叢集網格，則必須先執行 asmcli create-mesh，再升級各個叢集。這項指令會在升級後，將 Cloud Service Mesh 憑證授權單位設定為使用機群工作負載身分集區 FLEET_PROJECT_ID.svc.id.goog 做為信任網域。asmcli create-mesh 指令：

• 將所有叢集註冊至同一個機群。
• 設定 Mesh 信任 Fleet Workload Identity。
• 建立遠端密鑰。

您可以為每個叢集指定 URI，或指定 kubeconfig 檔案的路徑。

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

升級至預設功能和 Mesh CA

本節說明如何執行 asmcli，以平台的預設支援功能升級 Cloud Service Mesh，並將 Cloud Service Mesh 憑證授權機構設為憑證授權機構。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

使用 CA 服務升級預設功能

本節說明如何執行 asmcli，以便使用平台的預設支援功能升級 Cloud Service Mesh，並啟用憑證授權單位服務。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

使用 Istio CA 升級預設功能

本節說明如何執行 asmcli，以便使用平台的預設支援功能升級 Cloud Service Mesh，並啟用 Istio CA。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

升級至含選用功能的版本

覆蓋檔案是包含 IstioOperator 自訂資源 (CR) 的 YAML 檔案，您可以將該檔案傳遞至 asmcli 來設定控制平面。您可以將 YAML 檔案傳遞至 asmcli，藉此覆寫預設控制平面設定，並啟用選用功能。您可以疊加更多覆蓋層，每個覆蓋層檔案都會覆寫先前覆蓋層的設定。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

升級閘道

如果您已部署閘道，也必須升級這些閘道。如要進行簡單升級，請按照「安裝與升級閘道」指南中的「原地升級」一節操作。

切換至新控制層

1. 取得 istiod 上的修訂版本標籤。

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

   指令的輸出結果會與以下內容類似：

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1253-8-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1245-3
   istiod-asm-1253-8-67998f4b55-r76kr           1/1     Running   0          68m   asm-1245-3
   istiod-1245-3-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1253-8
   istiod-1245-3-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1253-8

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

   2. 請注意舊版 istiod 的修訂版本標籤中的值。您需要這個值，才能在工作負載遷移至新版本後刪除舊版 istiod。在範例輸出內容中，舊版修訂版本的修訂標籤值為 asm-1245-3。

2. 將修訂版本標籤新增至應用程式命名空間，並移除 istio-injection 標籤 (如果有的話)。在下列指令中，將 REVISION 變更為與 istiod 新修訂版本相符的值。

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

   如果輸出內容中出現 "istio-injection not found"，您可以忽略這項訊息。這表示命名空間先前沒有 istio-injection 標籤。由於命名空間同時具有 istio-injection 和修訂版本標籤時，自動插入行為未定義，因此 Cloud Service Mesh 說明文件中的所有 kubectl label 指令都會明確確保只設定一個。

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   完成轉換

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

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

   2. 移動預設代碼：

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite
      

   3. 刪除舊版 istiod。您要使用的指令取決於您是要從 Istio 遷移，還是要從先前版本的 Cloud Service Mesh 升級。

      遷移

      如果您是從 Istio 遷移，舊版 istio-ingressgateway 就沒有修訂版本標籤：

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

      升級

      1. 如果您是從舊版 Cloud Service Mesh 升級，請在下列指令中確認 OLD_REVISION 與舊版 istiod 的修訂版本標籤相符：

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

      2. 刪除舊版的 validatingwebhookconfiguration、mutatingWebhookConfiguration、configMap、clusterRole 和 clusterRoleBinding 資源：

         kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
         kubectl delete mutatingWebhookConfiguration istio-sidecar-injector-OLD_REVISION --ignore-not-found
         kubectl delete configMap istio-OLD_REVISION istio-sidecar-injector-OLD_REVISION -n istio-system --ignore-not-found
         kubectl delete clusterRole clusterRoleBinding istio-reader-clusterrole-OLD_REVISION-istio-system istiod-clusterrole-OLD_REVISION-istio-system istiod-gateway-controller-OLD_REVISION-istio-system --ignore-not-found
         

   4. 移除舊版 IstioOperator 設定：

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

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

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

   復原

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

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

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

      kubectl get ns NAMESPACE --show-labels
      

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

      kubectl rollout restart deployment -n NAMESPACE
      

   4. 移除新版 istiod。確認下列指令中的 REVISION 值是否正確。

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

   5. 移除新版 IstioOperator 設定。

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

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

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

   6. 如果您未加入 --disable_canonical_service 旗標，asmcli 會啟用標準服務控制器。建議您保持啟用狀態，但如果需要停用，請參閱「啟用及停用標準服務控制器」一文。

   7. 如果您已部署閘道，請務必變更命名空間或部署作業的修訂版本標籤，以符合先前版本的 istiod。請按照「安裝及升級閘道」指南中「原地升級」一節所述的程序進行。

部署與重新部署工作負載

您必須啟用自動 Sidecar 代理程式注入功能 (自動注入)，安裝 (或升級) 程序才算完成。從 OSS Istio 遷移及升級時，請遵循以修訂為依據的升級程序 (在 Istio 說明文件中稱為「測試群升級」)。透過修訂版本升級，新版控制層會與現有控制層一併安裝。接著，您可以將部分工作負載移至新版本，以便在將所有流量遷移至新版本之前，先監控升級對少部分工作負載的影響。

此指令碼會在 istiod 上以 istio.io/rev=asm-1253-8 格式設定修訂版本標籤。如要啟用自動插入功能，請在命名空間中新增相符的修訂版本標籤。修訂版本標籤會由側邊車注入器 webhook 使用，用於將注入的側邊車與特定 istiod 修訂版本建立關聯。新增標籤後，請重新啟動命名空間中的 Pod，以便注入附屬程式。

1. 取得 istiod 和 istio-ingressgateway 上的修訂標籤。在下列指令中，將 INGRESS_NAMESPACE 值變更為執行入口網站閘道的命名空間：

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

   如果入口網關名稱為 istio-ingressgateway，指令的輸出內容會與以下內容類似：

   NAME                                                READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-1253-8
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1253-8
   istiod-asm-1253-8-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1245-3
   istiod-asm-1253-8-67998f4b55-r76kr          1/1     Running   0          68m   asm-1245-3
   istiod-asm-1245-3-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1253-8
   istiod-asm-1245-3-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1253-8

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

   2. 請注意舊版 istiod 的修訂版本標籤中的值。當您完成將工作負載遷移至新版本的作業後，就需要這個值來刪除舊版 istiod。在範例輸出內容中，舊版修訂版本的修訂版本標籤值為 asm-1245-3。

2. 將入口網關切換至新修訂版本。在下列指令中，將 REVISION 變更為與新版本修訂版本標籤相符的值。將 INGRESS_NAMESPACE 變更為執行入口網站閘道的命名空間，並將 INGRESS_NAME 變更為入口網站閘道的名稱。

   kubectl patch service -n INGRESS_NAMESPACE INGRESS_NAME --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   預期輸出內容： service/istio-ingressgateway patched

3. 將修訂版本標籤新增至命名空間，並移除 istio-injection 標籤 (如果有的話)。在下列指令中，將 REVISION 變更為與 istiod 新修訂版本相符的值。

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

   如果輸出內容中出現 "istio-injection not found"，您可以忽略這項訊息。這表示命名空間先前沒有 istio-injection 標籤。由於命名空間同時具有 istio-injection 和修訂版本標籤時，自動插入行為未定義，因此 Cloud Service Mesh 說明文件中的所有 kubectl label 指令都會明確確保只設定一個。

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   完成轉換

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

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

   2. 移動預設代碼。

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite
      

   3. 刪除舊的輸入閘道部署作業。您執行的指令取決於您是要從 Istio 遷移，還是從舊版 Cloud Service Mesh 升級：

      遷移

      如果您是從 Istio 遷移，舊版 INGRESS_NAME 就沒有修訂版本標籤。

      kubectl delete deploy/INGRESS_NAME -n INGRESS_NAMESPACE
      

      升級

      如果您是從先前的 Cloud Service Mesh 版本升級，請在下列指令中將 OLD_REVISION 替換為先前版本 INGRESS_NAME 的修訂版本標籤。

      kubectl delete deploy -l app=INGRESS_NAME,istio.io/rev=OLD_REVISION -n INGRESS_NAMESPACE --ignore-not-found=true
      

   4. 刪除舊版 istiod。您要使用的指令取決於您是要從 Istio 遷移，還是要從先前版本的 Cloud Service Mesh 升級。

      遷移

      如果您是從 Istio 遷移，舊版 istiod 就沒有修訂版本標籤。

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

      如果您使用的是舊版控制層 (具有 OLD_REVISION 修訂版本標籤)，請按一下「upgrade」分頁，然後使用 OLD_REVISION 刪除 istiod 控制層。

      升級

      如果您是從舊版 Cloud Service Mesh 升級，請在下列指令中確認 OLD_REVISION 與舊版 istiod 的修訂版本標籤相符。

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

      刪除舊版的 validatingwebhookconfiguration、mutatingWebhookConfiguration、configMap、clusterRole 和 clusterRoleBinding 資源：

      kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
      kubectl delete mutatingWebhookConfiguration istio-sidecar-injector-OLD_REVISION --ignore-not-found
      kubectl delete configMap istio-OLD_REVISION istio-sidecar-injector-OLD_REVISION -n istio-system --ignore-not-found
      kubectl delete clusterRole clusterRoleBinding istio-reader-clusterrole-OLD_REVISION-istio-system istiod-clusterrole-OLD_REVISION-istio-system istiod-gateway-controller-OLD_REVISION-istio-system --ignore-not-found
      

   5. 移除舊版 IstioOperator 設定。

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true
      

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

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

   復原

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

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

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

      kubectl get ns NAMESPACE --show-labels
      

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

      kubectl rollout restart deployment -n NAMESPACE
      

   4. 移除新的 istio-ingressgateway 部署。請確認下列指令中的 REVISION 值是否正確。

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

   5. 移除新版 istiod。確認下列指令中的 REVISION 值是否正確。

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

   6. 移除新版 IstioOperator 設定。

    kubectl delete IstioOperator installed-state-REVISION -n istio-system --ignore-not-found=true
   

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

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

   1. 如果您未加入 --disable_canonical_service 標記，則指令碼會啟用 Canonical Service 控制器。建議您保持啟用狀態，但如果需要停用，請參閱「啟用及停用標準服務控制器」一文。