使用 asmcli 佈建代管 Cloud Service Mesh

總覽

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

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

必要條件

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

• Cloud 專案
• 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 穩定版。

  • 受管理的 Cloud Service Mesh 不支援安全變更 GKE 發布管道。
  • 如果您變更 GKE 發布版本管道，Cloud Service Mesh 會自動升級/降級叢集內的元件 (CNI、MDPC、預設插入式 Proxy 版本和 Istio CRD)，以便與目前的 GKE 發布版本管道保持一致。

• 請確保叢集有足夠的容量，可供管理的 Cloud Service Mesh 在叢集中安裝必要元件。

  • kube-system 命名空間中的 mdp-controller 部署要求 CPU：50m，記憶體：128Mi。
  • kube-system 命名空間中的 istio-cni-node DaemonSet 會要求每個節點的 CPU 為 100m，記憶體為 100Mi。

• 確認機構政策 constraints/compute.disableInternetNetworkEndpointGroup 已停用。如果啟用這項政策，ServiceEntry 可能無法運作。

• 請確認您從中佈建代管 Cloud Service Mesh 的用戶端電腦，是否有網路連線可連至 API 伺服器。

• 叢集必須註冊至機群。您可以透過傳遞 --enable-registration 和 --fleet-id 標記，在佈建設定前或在佈建設定的過程中單獨執行這個步驟。

• 專案必須啟用服務網格機群功能。您可以傳遞 --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 叢集。

  • 如果您加入的叢集不在同一個專案中，則必須註冊至同一個機群主機專案，且叢集必須位於同一個網路的共用虛擬私有雲設定中。
  • 對於單一專案的多叢集環境，機群專案可以與叢集專案相同。如要進一步瞭解機群，請參閱「機群總覽」。
  • 如果是多專案環境，建議您將機群託管在與叢集專案不同的專案中。如果您的機構政策和現有設定允許，建議您將共用虛擬私有雲專案用做車隊主機專案。如需更多資訊，請參閱「透過共用虛擬私人雲端設定叢集」。
  • 如果貴機構使用 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 (GA) 指南。

安裝 Cloud Service Mesh 所需的角色

下表說明安裝 Managed Cloud Service Mesh 所需的角色。

執行 Cloud Service Mesh 所需的角色

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

限制

建議您查看 Cloud Service Mesh 支援的功能和限制清單。特別注意下列事項：

• IstioOperator API 的主要用途是控制叢集內的元件，因此不支援此 API。

• 對於 GKE Autopilot 叢集，跨專案設定僅支援 GKE 1.23 以上版本。

• 針對 GKE Autopilot 叢集，為了配合 GKE Autopilot 資源限制，預設的 Proxy 資源要求和限制會設為 500m CPU 和 512 Mb 記憶體。您可以使用自訂插入功能覆寫預設值。

• 在 GKE Autopilot 叢集中，在叢集的 NodePool 擴充前，Cloud Service Mesh 元件可能會出現「DaemonSet 未選取任何節點」的警告。

• 在受管理控制層的佈建程序期間，Istio CRD 會在指定叢集中佈建。如果叢集中已有 Istio CRD，系統會將其覆寫。

• Istio CNI 和 Cloud Service Mesh 與 GKE Sandbox 不相容。因此，採用 TRAFFIC_DIRECTOR 實作的代管 Cloud Service Mesh 不支援已啟用 GKE 沙箱的叢集。

• asmcli 工具必須能存取 Google Kubernetes Engine (GKE) 端點。您可以透過「跳躍」伺服器設定存取權，例如在虛擬私有雲 (VPC) 中提供特定存取權的 Compute Engine VM。

事前準備

設定 gcloud

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

1. 使用 Google Cloud CLI 進行驗證：

   gcloud auth login --project PROJECT_ID
   

   其中 PROJECT_ID 是叢集專案的專屬 ID。執行下列指令，取得 PROJECT_ID：

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

2. 更新元件：

   gcloud components update
   

3. 將 kubectl 設為指向叢集。

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

下載安裝工具

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

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

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

   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，使用下列指示。

憑證授權單位

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

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

  ./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 中斷預算和控制變化率。

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

• 未注入的 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。

服務最多可能需要 10 分鐘才能準備好管理叢集中的 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.'

如果服務未在 10 分鐘內就緒，請參閱受管理資料平面狀態，瞭解後續步驟。

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

如果您要在新叢集中佈建代管的 Cloud Service Mesh，可以完全停用代管資料層，或停用個別命名空間或 Pod。如果是預設或手動停用的現有叢集，管理式資料層仍會繼續停用。

如要在叢集層級停用受管理的資料層，並恢復自行管理附屬 Proxy，請變更註解：

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

如要停用命名空間的受管理資料平面，請按照下列步驟操作：

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 維護期間，才能收到通知。啟用後，系統會在升級作業前至少兩天傳送通知。

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

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

   前往「Communication」(通訊) 頁面

2. 在「Cloud Service Mesh 升級」列的「電子郵件」欄下方，選取單選按鈕將維護通知設為「開啟」。

每位使用者都必須分別選擇接收通知。如要為這些通知設定電子郵件篩選器，主旨行請輸入：

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 Amphitheatre Parkway, Mountain View, CA 94043, USA Google Cloud Platform 或您的帳戶有重大異動，系統特此發送這則公告通知您。 如要停止接收維護期間通知，可至下列網址編輯使用者偏好設定：https://console.cloud.google.com/user-preferences/communication?project=${project_id}

設定端點探索功能 (僅限多叢集安裝)

如果您的網格只有一個叢集，請略過這些多叢集步驟，直接進行部署應用程式或遷移應用程式。

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

部署應用程式

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

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

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

使用下列指令驗證命名空間標籤是否正確套用。

  kubectl get namespace -L istio-injection

輸出內容範例：

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

到目前為止，您已成功設定代管型 Cloud Service Mesh。如果標記命名空間中已有任何現有的工作負載，請重新啟動這些工作負載，以便注入 Proxy。

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

自訂插入 (選用)

您可以覆寫預設值並自訂插入設定，但這可能會導致意外的設定錯誤，並導致 sidecar 容器發生問題。自訂注入功能前，請先閱讀範例後方的資訊，瞭解特定設定和建議。

您可以使用每個 Pod 設定，在個別 Pod 上覆寫這些選項。方法是將 istio-proxy 容器新增至 Pod。側載注入會將此處定義的任何設定視為預設注入範本的覆寫值。

舉例來說，下列設定可自訂各種設定，包括降低 CPU 要求、新增音量掛載點，以及新增 preStop 鉤子：

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/proxyCPU，請務必明確設定 sidecar.istio.io/proxyCPULimit。否則，側載程式的 CPU 限制會設為無限制。
• 針對 GKE Standard，如果已設定 sidecar.istio.io/proxyMemory，請務必明確設定 sidecar.istio.io/proxyMemoryLimit。否則，側載程式的記憶體限制會設為無限制。
• 對於 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 中查看控制層和資料層的版本。

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

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

   前往「Metrics Explorer」。

2. 選擇工作區，然後使用下列參數新增自訂查詢：

   • 資源類型：Kubernetes 容器
   • 指標：Proxy 用戶端
   • 篩選器：container_name="cr-REVISION_LABEL"
   • Group By：revision 標籤和 proxy_version 標籤
   • 匯總：加總
   • 時間：1 分鐘

   當您同時使用 Google 管理的控制層和叢集內控制層來執行 Cloud Service Mesh 時，可以透過容器名稱區分指標。舉例來說，已管理指標有 container_name="cr-asm-managed"，而非管理指標則有 container_name="discovery"。如要顯示這兩者的指標，請移除 container_name="cr-asm-managed" 上的「篩選器」。

3. 如要驗證控制層版本和 Proxy 版本，請在 Metrics Explorer 中檢查下列欄位：

   • 「修訂版本」欄位會指出控制層版本。
   • proxy_version 欄位代表 proxy_version。
   • value 欄位會顯示已連結的 Proxy 數量。

   如要瞭解目前管道與 Cloud Service Mesh 版本的對應關係，請參閱「各管道的 Cloud Service Mesh 版本」。

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

準備遷移

如要準備從叢集內的 Cloud Service Mesh 遷移應用程式至受管理的 Cloud Service Mesh，請執行下列步驟：

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

2. (選用) 如果您想使用 Google 代管的資料層，請啟用資料層管理功能：

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

遷移應用程式

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

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

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

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

1. 在命名空間中執行部署的滾動式升級：

   kubectl rollout restart deployment -n NAMESPACE
   

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

3. 如果其他命名空間中有工作負載，請針對每個命名空間重複執行上述步驟。

4. 如果您在多叢集設定中部署應用程式，請在所有叢集中複製 Kubernetes 和 Istio 設定，除非您想將該設定限制在部分叢集。套用至特定叢集的設定是該叢集的真實來源。

如果您認為應用程式運作正常，您可以將所有命名空間切換為受控的控制平面，然後移除叢集內的 istiod，或是將其保留做為備份 - istiod 會自動縮減，以便使用較少的資源。如要移除，請跳至「刪除舊控制平面」一節。

如果遇到問題，您可以參考「解決受控控制平面問題」一文中的資訊來找出問題並加以解決，並視需要將系統還原為先前版本。

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

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

deployment.apps/istio-ingressgateway rolled back

解除安裝

當沒有命名空間使用時，受管理的控制層會自動調降至零。如需詳細步驟，請參閱「解除安裝 Cloud Service Mesh」。

疑難排解

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

後續步驟

• 瞭解發布版本。
• 從 IstioOperator 遷移。
• 將閘道遷移至代管控制層。
• 瞭解如何啟用選用的代管型 Cloud Service Mesh 功能，例如：
  • Envoy 存取記錄
  • 追蹤
  • 無損圖片
  • 使用者驗證