Cloud Service Mesh 和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

本頁面由 Cloud Translation API 翻譯而成。

從叢集內遷移至 Managed Canonical Service Controller

注意：Cloud Service Mesh 1.6.8 以上版本會自動支援 Canonical 服務。

本指南說明從叢集內的標準服務控制器遷移至受管理的標準服務控制器的步驟。

叢集內的標準服務控制器已淘汰，且不會再收到更新。雖然叢集內控制器的現有部署作業會繼續運作，但我們強烈建議您遷移至受控的 Canonical Service Controller，以確保與日後版本相容、存取最新功能，並持續提供支援。所有使用 1.25 以上版本 asmcli 安裝的 Cloud Service Mesh 都會透過代管型 Canonical Service 控制器佈建。

1. 啟用 Cloud Service Mesh 車隊功能

在 Cloud Service Mesh 機群功能中，會安裝代管 Canonical Service 控制器，您可以使用下列指令啟用這項功能：

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

將 FLEET_PROJECT_ID 替換為車隊主機專案的 ID。一般來說，FLEET_PROJECT_ID 的名稱會與專案相同。

請注意，如果您打算註冊多個叢集，啟用 Cloud Service Mesh 會在機群層級進行，因此您只需執行這項指令一次。

將權限授予 Cloud Service Mesh 服務帳戶

如果叢集專案與機群主專案不同，您必須允許機群專案中的 Cloud Service Mesh 服務帳戶存取叢集專案。

您只需要為每個叢集專案執行這項操作一次。如果您先前已為這組叢集和機隊專案設定受控的 Cloud Service Mesh，則這些變更已套用，因此您不必執行下列指令。

授予機群專案中服務帳戶存取叢集專案的權限：

  gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

將 CLUSTER_PROJECT_ID 替換為叢集的專案 ID，並將 FLEET_PROJECT_NUMBER 替換為車隊的專案編號。

如要判斷車隊的專案編號，請參閱 Google Cloud 專案文件中的操作說明。

2. 停用叢集中的 Canonical Service Controller

受管理的標準服務控制器無法與叢集內的標準服務控制器並行運作。因此，您必須停用叢集內控制器。

檢查叢集內控制器：確認叢集內是否有標準控制器。

kubectl get deployment canonical-service-controller-manager -n asm-system

刪除叢集內的控制器：如果找到部署作業，您可以執行下列指令刪除該部署作業 (以及整個 asm-system 命名空間)：
```
kubectl delete namespace asm-system
```

3. 確認 Managed Canonical Controller 是否可正常運作

受管理的標準服務控制器會在功能狀態中回報其狀態，因此您可以檢查功能狀態，確認安裝作業是否正常運作：

檢查地圖項目狀態：使用下列指令擷取地圖項目狀態：
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
驗證狀態：檢查叢集狀態，並確認 state.code 為 OK。
- 重要事項：狀態最多可能需要 15 分鐘才會轉換為 OK。請稍待片刻，然後重新執行指令。
- 只有在 state.code 為 OK 時，才繼續執行下一個步驟。
- 如果 state.code 在 15 分鐘後仍未變成 OK，請參閱「解決 Managed Canonical Service Controller 問題」一文，瞭解疑難排解指引。
輸出內容範例：
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
檢查受控標準控制器是否正常運作：透過部署已注入 sidecar 的 Pod，確認受控標準控制器是否正常運作，並檢查控制器是否會自動建立對應的標準服務。
1. 建立啟用自動補充資訊植入功能的命名空間：
```
kubectl create namespace NAMESPACE_NAME
```
  按照「啟用自動補充資訊植入功能」一節的說明，在新建立的命名空間中啟用自動補充資訊植入功能。
2. 建立名為 simple_pod.yaml 的 YAML 檔案，並在其中加入下列內容：
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  app 標籤會決定標準服務的名稱。詳情請參閱「定義標準服務」。
3. 使用下列指令部署 Pod。將「NAMESPACE_NAME」替換為您啟用自動補充植入功能的命名空間名稱。
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. 確認已建立 Pod：
```
kubectl get pods -n NAMESPACE_NAME
```
  輸出內容範例：
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  Note：確認「READY」欄顯示 2/2。這表示主容器和輔助程式 Proxy 都正常執行。如果您看到其他值，表示命名空間可能未啟用自動副檔案注入功能。
5. 驗證標準服務建立作業：執行下列指令，列出命名空間中的所有標準服務。確認已建立標準服務 my-app。
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  輸出內容範例：
```
  NAME          AGE
  my-app        3s
```
6. 清理：刪除 Pod、標準服務和命名空間：
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
疑難排解：
- 如果未建立必要的標準服務，請參閱「在 Cloud Service Mesh 中解決標準服務問題」。
- 如果問題仍未解決，您可以改回叢集內的控制器。請參閱「恢復叢集內標準服務控制器」一文。

改回叢集內標準服務控制器

如果遇到 Managed Canonical Service Controller 相關問題，您可以使用下列指令重新安裝叢集內的控制器：

  kubectl apply -f \
  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.25/asm/canonical-service/controller.yaml

後續步驟

瞭解下列內容：