Anthos 服務網格和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

使用 asmcli 佈建代管型 Cloud Service Mesh

總覽

代管 Cloud Service Mesh 搭配 asmcli 是代管控制層和代管資料層，設定簡單。Google 會以回溯相容的方式處理可靠性、升級、資源調度和安全性作業。本指南說明如何使用 asmcli，在單一或多叢集設定中，設定或遷移應用程式至代管 Cloud Service Mesh。

如要瞭解代管 Cloud Service Mesh 支援的功能和限制，請參閱「代管 Cloud Service Mesh 支援的功能」。

必要條件

本指南假設您已具備以下條件：

雲端專案
Cloud Billing 帳戶
取得佈建 Cloud Service Mesh 的必要權限
asmcli 安裝工具、kpt，以及「安裝所需工具」中指定的其他工具

如要加快佈建速度，叢集必須啟用 Workload Identity。如果未啟用 Workload Identity，佈建程序會自動啟用這項功能。

需求條件

一或多個叢集，且叢集使用支援的 GKE 版本，並位於支援的區域。
請注意，受管理 Cloud Service Mesh 會使用 GKE 發布管道，在穩定性和升級速度之間取得平衡。Cloud Service Mesh 叢集內元件 (包括 CNI、MDPC、Proxy 和 Istio CRD) 的新變更，會先推出至訂閱 GKE 快速版的叢集。這些變更展現足夠的穩定性後，就會升級至 GKE 一般版，最後再升級至 GKE 穩定版。
- 最佳做法是在較早的 GKE 發布管道中，佈建部分機群叢集，確保這些叢集會優先收到 Cloud Service Mesh 元件的更新。
- 受管理 Cloud Service Mesh 不支援變更 GKE 發布管道。
- 如果您變更 GKE 發布管道，Cloud Service Mesh 不會阻止這項作業。Cloud Service Mesh 會自動更新叢集內元件 (CNI、MDPC、預設注入的 Proxy 版本和 Istio CRD)，與目前的 GKE 發布管道保持一致。
請確保叢集有足夠的容量，可容納受管理 Cloud Service Mesh 在叢集中安裝的必要元件。
- kube-system 命名空間中的 mdp-controller 部署作業會要求 cpu: 50m、memory: 128Mi。
- kube-system 命名空間中的 istio-cni-node daemonset 會在每個節點上要求 cpu: 100m、memory: 100Mi。
確認機構政策 constraints/compute.disableInternetNetworkEndpointGroup 已停用。如果啟用這項政策，ServiceEntry 可能無法運作。
確認您用於佈建受管理 Cloud Service Mesh 的用戶端電腦，已連上 API 伺服器。
叢集必須註冊至機群。您可以在佈建前單獨執行這個步驟，也可以傳遞 --enable-registration 和 --fleet-id 標記，在佈建時一併完成。
專案必須啟用 Service Mesh 機群功能。您可以傳遞 --enable-gcp-components，在佈建時啟用這項功能，也可以執行下列指令：
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
其中 FLEET_PROJECT_ID 是機群主專案的專案 ID。
GKE Autopilot 僅支援 GKE 1.21.3 以上版本。
Cloud Service Mesh 可在單一專案單一網路環境或多專案單一網路環境中使用多個 GKE 叢集。
- 如果加入的叢集不在同一個專案中，則必須向同一個機群主專案註冊，且叢集必須在同一個網路中，一起採用Shared VPC設定。
- 如果是單一專案的多叢集環境，機群專案可以與叢集專案相同。如要進一步瞭解機群，請參閱「機群總覽」。
- 如果是多專案環境，建議您將機群託管在與叢集專案不同的專案中。如果組織政策和現有設定允許，建議您使用 Shared VPC 專案做為機群主機專案。詳情請參閱「使用 Shared VPC 設定叢集」。
- 如果貴機構使用 VPC Service Controls 並在 GKE 叢集上佈建 Cloud Service Mesh，且版本大於或等於 1.22.1-gke.10，則可能需要執行額外的設定步驟：
  - 如果您在一般或穩定 發布管道上佈建 Cloud Service Mesh，則套用代管控制層時，必須使用額外的 --use-vpcsc 旗標，並按照 VPC Service Controls (預先發布版) 指南操作。否則，佈建作業會因安全控制項而失敗。
  - 如果您是在快速發布管道上佈建 Cloud Service Mesh，則套用代管控制層時無須使用額外的 --use-vpcsc 旗標，但需要遵循 VPC Service Controls (正式版) 指南。

安裝 Cloud Service Mesh 的必要角色

下表說明安裝代管 Cloud Service Mesh 時所需的角色。

角色名稱	角色 ID	授予位置資訊存取權	說明
GKE Hub 管理員	roles/gkehub.admin	機群專案	具備 GKE Hub 和相關資源的完整存取權限。
服務使用情形管理員	roles/serviceusage.serviceUsageAdmin	機群專案	可啟用、停用及檢查服務狀態、檢查作業，以及消耗消費者專案的配額和帳單。^{(附註 1)}
CA 服務管理員 ^{Beta 版}	roles/privateca.admin	機群專案	具備所有 CA 服務資源的完整存取權限。 ^{(Note 2)}

執行 Cloud Service Mesh 時所需的角色

下表說明服務帳戶執行受管理 Cloud Service Mesh 時所需角色。如果網路或叢集專案與機群主機專案不同，您需要授予機群專案中的服務帳戶在其他專案中存取這些角色的權限。

角色名稱	角色 ID	授予位置資訊存取權	說明
Anthos 服務網格服務代理	roles/anthosservicemesh.serviceAgent	機群專案
網格代管控制層服務代理 (舊版)	roles/meshcontrolplane.serviceAgent	機群專案	這是舊版角色，屬於舊版 Cloud Service Mesh 安裝作業。如果您的安裝項目有這個服務角色，可以保留原狀。新安裝項目不需要這個角色。

限制

建議您查看雲端服務網格支援的功能和限制清單。請特別注意下列事項：

不支援使用 hostNetwork: true 執行的工作負載 Pod。
由於 IstioOperator API 的主要用途是控制叢集內元件，因此不支援這項 API。
附註： 您仍可啟用選用功能，不必使用 IstioOperator API，請參閱在受管理 Cloud Service Mesh 上啟用選用功能。

如果是 GKE Autopilot 叢集，只有 GKE 1.23 以上版本支援跨專案設定。
對於 GKE Autopilot 叢集，為了配合 GKE Autopilot 資源限制，預設的 Proxy 資源要求和限制會設為 500m CPU 和 512 MB 記憶體。您可以使用自訂注入覆寫預設值。
如果是 GKE Autopilot 叢集，在叢集的 NodePool 擴充前，Cloud Service Mesh 元件可能會顯示「DaemonSet has no nodes selected」警告。
在佈建受管理控制層的過程中，系統會在指定叢集中佈建 Istio CRD。如果叢集中已有 Istio CRD，系統會覆寫這些 CRD。
Istio CNI 和 Traffic Director 與 GKE Sandbox 不相容，因此，採用 TRAFFIC_DIRECTOR 實作方式的代管 Cloud Service Mesh 不支援已啟用 GKE Sandbox 的叢集。
asmcli 工具必須有權存取 Google Kubernetes Engine (GKE) 端點。您可以透過「跳躍」伺服器設定存取權，例如虛擬私有雲 (VPC) 內的 Compute Engine VM，並授予特定存取權。

事前準備

設定 gcloud

即使使用 Cloud Shell，也請完成下列步驟。

使用 Google Cloud CLI 進行驗證：

gcloud auth login --project PROJECT_ID

其中 PROJECT_ID 是叢集專案的唯一識別碼。執行下列指令來取得 PROJECT_ID：

   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```

更新元件：
```
gcloud components update
```

設定 kubectl 指向叢集。

gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID

下載安裝工具

將工具的最新版本下載至目前的工作目錄：

curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

將工具設為可執行檔：
```
chmod +x asmcli
```

設定每個叢集

請按照下列步驟，為網格中的每個叢集設定受管理 Cloud Service Mesh。

套用代管控制層

套用代管控制層前，請務必選取發布管道。Cloud Service Mesh 管道取決於佈建代管 Cloud Service Mesh 時的 GKE 叢集管道。請注意，系統不支援在同一個叢集中同時使用多個管道。

針對要使用受管理 Cloud Service Mesh 的每個叢集，執行安裝工具。建議您同時提供下列兩種選項：

--enable-registration --fleet_id FLEET_PROJECT_ID 這兩個旗標會將叢集註冊至機群，其中 FLEET_ID 是機群主機專案的專案 ID。如果使用單一專案，FLEET_PROJECT_ID 與 PROJECT_ID 相同，機群主機專案和叢集專案相同。在多專案等較複雜的設定中，建議使用個別的機群主機專案。
--enable-all：這個旗標會啟用必要元件和註冊功能。

asmcli 工具會使用 CLI 工具內的工具和邏輯，直接設定受管理控制層。請根據偏好的 CA 使用下列一組操作說明。

憑證授權

選取要用於網格的憑證授權單位。

Mesh CA

執行下列指令，安裝具有預設功能和網格 CA 的控制平面。在提供的預留位置中輸入值。

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

CA 服務

按照「設定憑證授權單位服務」一文中的步驟操作。
執行下列指令，安裝具有預設功能和憑證授權單位服務的控制層。在提供的預留位置中輸入您的值。

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

這項工具會下載所有檔案，以便將受管理控制層設定為指定的 --output_dir、安裝 istioctl 工具和範例應用程式。本指南中的步驟假設您從執行 asmcli install 時指定的 --output_dir 位置執行 istioctl，且 istioctl 位於其 <Istio release dir>/bin 子目錄中。

如果對同一個叢集重新執行 asmcli，系統會覆寫現有的控制層設定。如要使用相同設定，請務必指定相同的選項和旗標。

確認控制層已佈建完成

幾分鐘後，請確認控制層狀態為 ACTIVE：

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

輸出內容類似如下：

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

如果狀態在幾分鐘內未達到 ACTIVE`，請參閱「檢查代管控制層狀態」，進一步瞭解可能發生的錯誤。

零接觸升級

安裝受管理控制層後，Google 會在新版本或修補程式推出時，自動升級控制層。

代管資料層

如果您使用代管 Cloud Service Mesh，Google 會全面管理 Proxy 升級作業。

啟用受管理資料層功能後，系統會重新啟動工作負載，重新注入新版 Proxy，主動且自動更新 Sidecar Proxy 和注入的閘道，並與受管理控制層同步。這項作業會在控制層升級後開始，通常會在開始後 2 週內完成。

請注意，代管資料層依賴 GKE 發布管道。如果啟用代管資料層時變更 GKE 發布管道，代管 Cloud Service Mesh 會更新所有現有工作負載的 Proxy，就像代管資料層推出一樣。

如果停用，系統會被動管理 Proxy，也就是由叢集中 Pod 的自然生命週期驅動，且必須由使用者手動觸發，才能控制更新頻率。

受管理資料層會逐出執行舊版 Proxy 的 Pod，藉此升級 Proxy。系統會逐步執行驅逐作業，遵守 Pod 中斷預算，並控制變更率。

部署新版 Cloud Service Mesh 資料平面時

代管資料層	觸發新 Cloud Service Mesh 資料平面部署作業的事件
代管資料層	Cloud Service Mesh 主動更新有新版本時，系統會主動更新。¹	建立新 Pod 當您或水平自動調度 Pod 資源部署新的工作負載時，	GKE 維護期間在 GKE 維護期間更換節點時，
已啟用
已停用

¹Cloud Service Mesh 主動更新會自動取代工作負載中的 Pods，但 StatefulSets、Jobs、DaemonSets 和手動插入的 Pods 除外。Cloud Service Mesh 主動更新會遵守 Pod 中斷預算。

低優先順序的更新會在 GKE 維護時段進行。
只要 Cloud Service Mesh 為叢集提供高優先順序的有效更新，系統就會立即套用，不會考量 GKE 維護期間。高優先順序的有效更新通常至少會有一項相關聯的 CVE。

如果您不想自行管理 Cloud Service Mesh 資料層的生命週期，且工作負載可隨時替換 Pod，請啟用受管理資料層。

如要全面掌控所有 Cloud Service Mesh 資料層更新的時間，請停用代管資料層。

系統不會預設傳送維護作業通知。詳情請參閱本文的「為受管理資料層啟用維護通知」。

限制

代管資料層不會管理下列項目：

未插入的 Pod
手動插入的 Pod
工作
StatefulSets
DaemonSets

如果您在舊版叢集上佈建了代管 Cloud Service Mesh，可以為整個叢集啟用資料層管理功能：

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'

或者，您也可以為特定控制層修訂版本、命名空間或 Pod 加上相同註解，有選擇性地啟用受管理資料層。如果您選擇性地控制個別元件，則優先順序為控制層修訂版本，然後是命名空間，最後是 Pod。

服務最多可能需要十分鐘，才能管理叢集中的 Proxy。請執行下列指令來檢查狀態：

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

預期的輸出內容：

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

如果服務在十分鐘內未準備就緒，請參閱「受管理資料平面狀態」一文，瞭解後續步驟。

停用受管理資料層 (選用)

如果您要在新叢集上佈建受管理的 Cloud Service Mesh，可以完全停用受管理資料層，或針對個別命名空間或 Pod 停用。對於預設或手動停用受管理資料層的現有叢集，系統會繼續停用該層。

如要在叢集層級停用受管理資料層，並還原為自行管理 Sidecar Proxy，請找出每個 controlplanerevision，然後變更每個註解。

找出所有控制層修訂版本：

kubectl get controlplanerevisions -n istio-system

變更註解：

kubectl annotate --overwrite controlplanerevision CONTROL_PLANE_REVISION_NAME -n istio-system mesh.cloud.google.com/proxy='{"managed":"false"}'

針對每個控制層修訂版本重複這個步驟。

將 CONTROL_PLANE_REVISION_NAME 替換為上一個指令的輸出內容。

如要為命名空間停用代管資料層，請按照下列步驟操作：

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

如要停用 Pod 的代管資料層，請按照下列步驟操作：

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

為受管理資料層啟用維護期間

如果您已設定 GKE 維護期間，系統會在下一個可用的維護期間開始時啟動升級作業，並持續進行，直到所有受管理 Pod 都更新完畢為止 (通常需要 12 小時)。與 CVE 相關的推出作業不會遵守維護期間。

Cloud Service Mesh 會使用 GKE 維護期間，與 GKE 保持一致。

啟用受管理資料層的維護通知

您可以要求在維護期間內排定的代管資料平面維護作業開始前一週收到通知。根據預設，系統不會傳送維護通知。您也必須先設定 GKE 維護期間，才能收到通知。啟用後，系統會在升級作業前至少兩天發送通知。

如要啟用代管資料平面維護通知，請按照下列步驟操作：

前往「Communication」(通訊) 頁面。

前往「Communication」(通訊) 頁面
在「Cloud Service Mesh Upgrade」列的「Email」欄下方，選取單選按鈕，將維護通知設為「ON」。

如要接收通知，每位使用者都必須個別選擇啟用。如要為這類通知設定電子郵件篩選器，請使用以下主旨行：

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"。

以下範例顯示典型的受管理資料平面維護通知：

主旨：Cloud Service Mesh 叢集「<location/cluster-name>」即將升級

Cloud Service Mesh 使用者，您好：

叢集 ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) 中的 Cloud Service Mesh 元件已排定於 ${scheduled_date_human_readable} ${scheduled_time_human_readable} 升級。

如想瞭解本次更新內容，可以查看版本資訊 (https://cloud.google.com/service-mesh/docs/release-notes)。

如果這項維護作業取消，您會收到另一封電子郵件。

祝一切順心！

Cloud Service Mesh 團隊敬上

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043, USA Google Cloud Platform 或您的帳戶設定有重大變更，系統特此發送這則公告通知您。如要停用維護期間通知，請編輯使用者偏好設定： https://console.cloud.google.com/user-preferences/communication?project=${project_id}

設定端點探索 (僅適用於多叢集安裝作業)

如果網格只有一個叢集，請略過這些多叢集步驟，並繼續部署應用程式或遷移應用程式。

繼續操作前，請確認每個叢集都已設定 Cloud Service Mesh。

公開叢集

設定公有叢集之間的端點探索

如果您在公開叢集 (非私人叢集) 上運作，可以設定公開叢集之間的端點探索，或更簡單地啟用公開叢集之間的端點探索。

私人叢集

設定私人叢集之間的端點探索

使用 GKE 私人叢集時，您必須將叢集控制層端點設為公開端點，而非私人端點。請參閱「設定私人叢集之間的端點探索」。

如需包含兩個叢集的範例應用程式，請參閱「HelloWorld 服務範例」。

部署應用程式

啟用要用於注入的命名空間。步驟取決於控制層實作方式。

代管 (TD)

將預設插入標籤套用至命名空間：

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

受管理 (Istiod)

建議：執行下列指令，將預設的插入標籤套用至命名空間：

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

如果您是使用受管理 Istiod 控制層的現有使用者： 建議您使用預設注入功能，但系統也支援以修訂版本為準的注入功能。請按照下列操作說明進行：

執行下列指令，找出可用的發布管道：
```
kubectl -n istio-system get controlplanerevision
```
輸出結果會與下列內容相似：
```
NAME                AGE
asm-managed-rapid   6d7h
```
注意：如果上述清單中出現兩個控制層修訂版本，請移除其中一個。叢集不支援多個控制層通道。

在輸出內容中，「NAME」欄位下方的值是修訂版本標籤，對應 Cloud Service Mesh 版本的可用發布管道。

將修訂版本標籤套用至命名空間：

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

使用下列指令，確認命名空間標籤已正確套用。

  kubectl get namespace -L istio-injection

輸出內容範例：

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

此時，您已成功設定代管 Cloud Service Mesh。如果標籤命名空間中已有任何工作負載，請重新啟動這些工作負載，以便注入 Proxy。

如果您在多叢集設定中部署應用程式，請在所有叢集中複製 Kubernetes 和控制層設定，除非您打算將特定設定限制在叢集子集中。套用至特定叢集的設定，就是該叢集的可靠資料來源。

自訂插入內容 (選用)

您可以覆寫預設值並自訂插入設定，但這可能會導致無法預期的設定錯誤，以及連帶容器的問題。自訂注入程序前，請先閱讀範例後方的資訊，瞭解特定設定和建議。

您可以透過每個 Pod 的設定，覆寫個別 Pod 的這些選項。方法是在 Pod 中新增 istio-proxy 容器。Sidecar 插入作業會將這裡定義的任何設定，視為預設插入範本的覆寫項目。

舉例來說，下列設定會自訂各種設定，包括降低 CPU 要求、新增磁碟區掛接，以及新增 preStop hook：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

一般來說，您可以設定 Pod 中的任何欄位。不過，請務必注意下列欄位：

Kubernetes 要求在執行插入作業前設定 image 欄位。雖然您可以設定特定映像檔來覆寫預設映像檔，但建議您將 image 設為 auto，讓 Sidecar 注入器自動選取要使用的映像檔。
containers 中的部分欄位取決於相關設定。舉例來說，必須小於或等於 CPU 限制。如果這兩個欄位都未正確設定，Pod 可能無法啟動。
Kubernetes 可讓您為 Pod spec 中的資源設定 requests 和 limits。GKE Autopilot 只會考量 requests。詳情請參閱「在 Autopilot 中設定資源上限」。

此外，您也可以透過 Pod 上的註解設定特定欄位，但建議使用上述方法自訂設定。請特別注意下列註解：

如果是 GKE Standard，請務必明確設定 sidecar.istio.io/proxyCPULimit，sidecar.istio.io/proxyCPU否則，系統會將 Sidecar 的 CPU 限制設為無上限。
如果是 GKE Standard，如果已設定 sidecar.istio.io/proxyMemory，請務必明確設定 sidecar.istio.io/proxyMemoryLimit。否則，Sidecar 的記憶體限制會設為無限制。
如果是 GKE Autopilot，使用註解設定資源 requests 和 limits 可能會過度佈建資源。請使用映像檔範本方法來避免這種情況。請參閱 Autopilot 中的資源修改範例。

例如，請參閱下列資源註解：

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

驗證控制層指標

您可以在 Metrics Explorer 中查看控制層和資料層的版本。

如要確認設定是否正常運作，請按照下列步驟操作：

在 Google Cloud 控制台中，查看控制層指標：

前往「Metrics Explorer」。
選擇工作區，然後使用下列參數新增自訂查詢：
- 資源類型：Kubernetes 容器
- 指標：Proxy 用戶端
- 篩選器：container_name="cr-REVISION_LABEL"
- 依據分組：revision 標籤和 proxy_version 標籤
- 匯總器：sum
- 週期：1 分鐘
同時使用 Google 代管和叢內控制層執行 Cloud Service Mesh 時，您可以根據容器名稱區分指標。舉例來說，代管指標會顯示 container_name="cr-asm-managed"，而非代管指標則會顯示 container_name="discovery"。如要同時顯示這兩者的指標，請移除 container_name="cr-asm-managed" 的篩選條件。
在 Metrics Explorer 中檢查下列欄位，驗證控制層版本和 Proxy 版本：
- revision 欄位會指出控制層版本。
- proxy_version 欄位會指出 proxy_version。
- value 欄位會指出連線的 Proxy 數量。
如要瞭解目前管道對應的 Cloud Service Mesh 版本，請參閱「各管道的 Cloud Service Mesh 版本」。

將應用程式遷移至代管 Cloud Service Mesh

為遷移作業做好準備

如要準備將應用程式從叢集內 Cloud Service Mesh 遷移至代管型 Cloud Service Mesh，請完成下列步驟：

按照「套用 Google 管理的控制層」一節的說明執行工具。

(選用) 如要使用 Google 管理的資料層，請啟用資料層管理：

  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

遷移應用程式

如要將應用程式從叢內 Cloud Service Mesh 遷移至代管 Cloud Service Mesh，請執行下列步驟：

取代目前的命名空間標籤。步驟取決於控制層實作方式。

代管 (TD)

將預設插入標籤套用至命名空間：

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

受管理 (Istiod)

建議：執行下列指令，將預設的插入標籤套用至命名空間：

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

如果您是使用受管理 Istiod 控制層的現有使用者： 建議您使用預設注入功能，但系統也支援以修訂版本為準的注入功能。請按照下列操作說明進行：

執行下列指令，找出可用的發布管道：
```
kubectl -n istio-system get controlplanerevision
```
輸出結果會與下列內容相似：
```
NAME                AGE
asm-managed-rapid   6d7h
```
注意：如果上述清單中出現兩個控制層修訂版本，請移除其中一個。叢集不支援多個控制層通道。

在輸出內容中，「NAME」欄位下方的值是修訂版本標籤，對應 Cloud Service Mesh 版本的可用發布管道。

將修訂版本標籤套用至命名空間：

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

對命名空間中的部署執行滾動升級：

kubectl rollout restart deployment -n NAMESPACE

測試應用程式，確認工作負載是否正常運作。
如果其他命名空間也有工作負載，請針對每個命名空間重複執行上述步驟。
如果您在多叢集設定中部署應用程式，請在所有叢集中複製 Kubernetes 和 Istio 設定，除非您只想將該設定限制在部分叢集。套用至特定叢集的設定，就是該叢集的真理來源。

確認應用程式運作正常後，您可以將所有命名空間切換至代管控制層，然後移除叢集內 istiod，或保留做為備份。istiod 會自動縮減規模，以減少資源用量。如要移除，請跳至「刪除舊控制層」。

如果遇到問題，可以參考「解決受管理控制層問題」一文中的資訊找出並解決問題，必要時還原至先前版本。

刪除舊的控制層

安裝並確認所有命名空間都使用 Google 管理的控制層後，即可刪除舊的控制層。

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

如果您使用 istioctl kube-inject 而非自動插入，或安裝了其他閘道，請檢查控制層的指標，並確認連線端點數量為零。

復原

如要還原至先前的控制平面版本，請按照下列步驟操作：

更新工作負載，以便注入舊版控制層。在下列指令中，修訂版本值 asm-191-1 僅做為範例。請將範例值替換為先前控制層的修訂版本標籤。
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
重新啟動 Pod，觸發重新注入程序，讓 Proxy 採用先前的版本：
```
kubectl rollout restart deployment -n NAMESPACE
```

如果沒有使用，受管理控制層會自動縮減至零，不會使用任何資源。變動 Webhook 和佈建作業會保留，且不會影響叢集行為。

閘道現已設為「asm-managed」修訂版本。如要復原，請重新執行 Cloud Service Mesh 安裝指令，系統會重新部署閘道，並將其指向叢集內控制層：

kubectl -n istio-system rollout undo deploy istio-ingressgateway

成功時的預期輸出內容：

deployment.apps/istio-ingressgateway rolled back

解除安裝

如果沒有命名空間使用代管控制層，系統會自動將其資源調度降至零。如需詳細步驟，請參閱「解除安裝 Cloud Service Mesh」。

疑難排解

如要找出並解決使用代管控制層時的問題，請參閱「解決代管控制層問題」。