在 Cloud Service Mesh 中解決標準服務問題

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

本節說明常見的 Cloud Service Mesh 問題,以及如何解決這些問題。如需其他協助,請參閱取得支援

網格中的叢集正在執行舊版 Cloud Service Mesh

如果任何叢集執行的是舊版 Cloud Service Mesh (1.6.8 以下),或是叢集執行的是 Cloud Service Mesh,但已停用 Canonical Service 控制器,則這些叢集 (以及叢集中執行的服務) 不會顯示在 Service Mesh UI 中。如要使用 Canonical 服務,您必須將每個叢集升級至 Cloud Service Mesh 1.6.8 以上版本,並使用內含 Canonical 服務控制器的預設安裝選項。如需更多資訊,如果您的叢集位於 GKE 上,請參閱「將 Cloud Service Mesh 升級至最新版本」;如果位於內部,請參閱「在內部升級 Cloud Service Mesh」。

或者,如果您不想在叢集中安裝控制器,可以為網格啟用 Managed Canonical Service Controller (目前處於預覽階段)。

如要進一步瞭解如何啟用 Canonical Service 控制器,請參閱「啟用 Canonical Service 控制器」。

叢集中未安裝 Cloud Service Mesh

如果 Cloud Service Mesh 未安裝在任何叢集上,這些叢集就不會顯示在 Service Mesh UI 中。如要進一步瞭解如何安裝 Cloud Service Mesh,請參閱 Cloud Service Mesh 說明文件

未登入內部部署叢集

如果網狀結構中含有內部部署叢集,但您未登入該叢集,就無法查看與該叢集相對應的服務。如要在資訊主頁中查看這些服務,您必須登入叢集。如要進一步瞭解如何登入叢集,請參閱「透過 Cloud 控制台登入叢集」。

無法連線至您的內部部署叢集

如果網格中有內部部署叢集,但無法透過連線代理程式存取,您就無法查看與該叢集相對應的服務。如要在資訊主頁中查看這些服務,請確認叢集是否正在執行,且已連線至 Google Cloud。如要進一步瞭解如何將叢集連結至 Google Cloud,請參閱「Connect 總覽」。

已定義服務等級目標的服務並未與標準服務 1:1 對應

在轉換為 Canonical Service 之前,Cloud Service Mesh 會顯示 Kubernetes 服務的資訊主頁。雖然 Kubernetes 服務和預設 Canonical 服務通常會對應,但 Kubernetes 服務可能無法自動比對至對應的 Canonical 服務,或是您不想要預設 Canonical 服務的邊界。

如果您在現有服務上設定的服務等級目標 (SLO) 無法自動比對至預設的標準服務,就無法遷移。如要開始使用標準服務,您必須刪除有問題服務的 SLO。如有需要,您可以為最符合該服務的標準服務建立新的 SLO,然後再刪除舊的 SLO。

資訊主頁沒有我預期的內容

服務網格服務資訊主頁的範圍各自為服務網格中的標準服務,其中標準服務是涵蓋所有相關工作負載、區域等的高階邏輯服務概念。

根據預設,每個工作負載例項 (Pod 或 WorkloadEntry) 中的現有標籤會定義標準服務,並依下列規則依序降低優先順序:

  1. service.istio.io/canonical-name 標籤已明確設定。我們不會採取進一步行動。
  2. 否則會新增 service.istio.io/canonical-name 標籤,並將其值設為 app.kubernetes.io/name 標籤的值。
  3. 否則會新增 service.istio.io/canonical-name 標籤,並將其值設為 app 標籤的值。
  4. 否則,系統會新增 service.istio.io/canonical-name 標籤,並將其值設為擁有工作負載的 name。如果是單獨部署 Pod 的情況,則為「擁有的工作負載」;如果是使用較高層級的調度作業,則為部署作業、StatefulSet 等。

對於大多數 Kubernetes 和 Kube Run / Knative 的慣用使用者而言,這些規則會直接對應至您現有的服務和工作負載管理方式。

不過,在某些較為自訂或較複雜的用途中,預設的推論法無法適當擷取您的服務,因此您看到的 Cloud Service Mesh 資訊主頁不會包含預期的內容。

您可以手動定義標準服務範圍來修正這個問題。

手動定義服務的範圍

建議您盡可能使用自動預設分組機制。不過,如果您想覆寫這些預設分組,可以將 service.istio.io/canonical-name Kubernetes 標籤套用至 Kubernetes Pod 和 WorkloadEntry 設定。

詳情請參閱「手動定義 Canonical 服務」。

解決受管理的標準控制器問題

1. 檢查功能狀態:執行下列指令,其中 FLEET_PROJECT_ID 是車隊主機專案的 ID。一般來說,系統會預設建立 FLEET_PROJECT_ID,且名稱與專案相同。

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID
  

輸出內容範例:

      membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description: 
              Revision(s) ready for use: istiod-asm-183-2.
              All Canonical Services have been reconciled successfully.

2. 根據 state.code 採取行動:

在功能狀態輸出內容中,查看叢集的狀態。檢查 state.code 的值,有助於瞭解受管理的 CSC 目前的狀態。根據 state.code 的值,實作對應的動作:

  • MISSING

    1. 請等待一小時,以便初始化作業順利進行。
    2. 重新執行 gcloud container fleet mesh describe --project <FLEET_PROJECT_ID> 指令。如果 state.code 仍未出現,請與 Google Cloud 支援團隊聯絡尋求協助。
  • WARNING/ERROR

    1. 請查看 servicemesh.conditions 瞭解錯誤詳細資訊。
    2. 如果找到條件 CANONICAL_SERVICE_ERROR,表示受管理的標準服務控制器發生問題。如果不是,問題很可能是標準服務控制器以外的因素造成。
    3. 無論是哪種情況,請與 Google Cloud 支援團隊聯絡,進一步排除問題
  • OK請參閱下表,瞭解如何根據 state.description 文字採取行動:

State.Description 必要行動
已成功協調所有 Canonical 服務 CSC 運作正常。因此無須採取進一步行動。
由 Managed Canonical Service Controller 產生的控制器會讓位給叢集內的控制器 請按照這份指南的說明,從叢集內的控制器遷移
`state.description` 中未提及標準化服務的具體資訊
  1. 如果叢集沒有任何 sidecar 注入的 Pod 或服務項目,就可能發生這種情況。如要確認代管標準控制器的運作狀態,請按照「代管控制器是否可運作」一節所述步驟操作。
  2. 如果仍缺少必要的標準服務,請確認標準服務定義正確無誤。請參閱「定義標準服務 」。