排解 Google Distributed Cloud 觀測能力問題

本文可協助您排解 Google Distributed Cloud 中的可觀測性問題。如果遇到上述任一問題，請參閱建議的修正方式和解決方法。

如需其他協助，請與 Cloud Customer Care 團隊聯絡。

如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：

• 提出支援案件的規定。
• 工具，例如記錄和指標，可協助您排解問題。
• Google Distributed Cloud for VMware (僅限軟體) 的支援元件、版本和功能。

系統未收集 Cloud 稽核記錄

檢查叢集設定的 cloudAuditLogging 專區是否已啟用 Cloud 稽核記錄。確認專案 ID、位置和服務帳戶金鑰已正確設定。專案 ID 必須與 gkeConnect 下的專案 ID 相同。

如果已啟用 Cloud 稽核記錄，權限就是記錄檔未收集到的最常見原因。在此情境中，Cloud 稽核記錄 Proxy 容器會顯示權限遭拒的錯誤訊息。

Cloud 稽核記錄 Proxy 容器會以下列其中一種方式執行：

• 管理員或獨立叢集中的靜態 Pod。
• 做為 kube-apiserver Pod 中的補充容器。

如果看到權限錯誤，請按照步驟排解及解決權限問題。

另一個可能原因為專案可能已達到支援的服務帳戶上限，請參閱「Cloud 稽核記錄服務帳戶外洩」。

kube-state-metrics 未收集指標

kube-state-metrics (KSM) 會以叢集中的單一副本部署作業形式執行，並產生叢集中幾乎所有資源的指標。如果 KSM 和 gke-metrics-agent 在同一個節點上執行，所有節點上的指標代理程式就更有可能發生中斷。

KSM 指標的命名模式為 kube_<ResourceKind>，例如 kube_pod_container_info。開頭為 kube_onpremusercluster_ 的指標來自地端叢集控制器，而非 KSM。

如果缺少 KSM 指標，請按照下列疑難排解步驟操作：

• 在 Cloud Monitoring 中，使用摘要 API 指標 (例如 kubernetes.io/anthos/container/... ) 檢查 KSM 的 CPU、記憶體和重新啟動次數。這是 KSM 的獨立管道。確認 KSM Pod 沒有資源不足的問題。
  • 如果 KSM 無法提供這些摘要 API 指標，gke-metrics-agent 同一個節點可能也會發生相同問題。
• 在叢集中，檢查 KSM Pod 和與 KSM 位於同一節點的 gke-metrics-agent Pod 狀態和記錄。

kube-state-metrics 發生當機迴圈

症狀

Cloud Monitoring 不提供 kube-state-metrics (KSM) 的指標。

原因

這種情況較常發生在大型叢集，或資源量大的叢集。KSM 會以單一副本 Deployment 形式執行，並列出叢集中的幾乎所有資源，例如 Pod、Deployment、DaemonSet、ConfigMap、Secret 和 PersistentVolume。系統會在每個資源物件上產生指標。如果任何資源有大量物件 (例如叢集有超過 10,000 個 Pod)，KSM 可能會記憶體不足。

受影響的版本

任何版本的 Google Distributed Cloud 都可能發生這個問題。

在過去幾個 Google Distributed Cloud 版本中，預設的 CPU 和記憶體限制已增加，因此這些資源問題應該較不常見。

修正和解決方法

如要確認問題是否因記憶體不足而起，請按照下列步驟操作：

• 使用 kubectl describe pod 或 kubectl get pod -o yaml，並查看錯誤狀態訊息。
• 檢查 KSM 的記憶體消耗量和使用率指標，確認是否達到限制而重新啟動。

如果確認是記憶體不足的問題，請使用下列任一解決方案：

• 提高 KSM 的記憶體要求和限制。

  注意： 即使資源增加後 KSM 變得穩定，從 KSM 擷取大量指標時，同一節點上的 gke-metrics-agent 仍可能成為瓶頸。

  如要調整 KSM 的 CPU 和記憶體，請按照下列步驟操作：

  • 如果是 Google Distributed Cloud 1.16.0 以上版本，Google Cloud Observability 會管理 KSM。如要更新 KSM，請參閱「覆寫 Stackdriver 元件的預設 CPU 和記憶體要求與限制」。

  • 如果是 Google Distributed Cloud 1.10.7 以上版本、1.11.3 以上版本、1.12.2 以上版本，以及 1.13 以上版本，但低於 1.16.0，請建立 ConfigMap 來調整 CPU 和記憶體：

    1. 在 kube-system 命名空間中建立名為 kube-state-metrics-resizer-config 的 ConfigMap (適用於 1.13 以上版本)，並使用下列定義。gke-managed-metrics-server視需要調整 CPU 和記憶體數量：

         apiVersion: v1
         kind: ConfigMap
         metadata:
           name: kube-state-metrics-resizer-config
           namespace: kube-system
         data:
           NannyConfiguration: |-
             apiVersion: nannyconfig/v1alpha1
             kind: NannyConfiguration
             baseCPU: 200m
             baseMemory: 1Gi
             cpuPerNode: 3m
             memoryPerNode: 20Mi
         ```
       

    2. 建立 ConfigMap 後，請使用下列指令刪除 KSM Pod，藉此重新啟動 KSM 部署作業：

       kubectl -n kube-system rollout restart deployment kube-state-metrics
       

  • 適用於 Google Distributed Cloud 1.9 以下、1.10.6 以下、1.11.2 以下和 1.12.1 以下版本：

    • 沒有良好的長期解決方案 - 如果您編輯 KSM 相關資源，monitoring-operator 會自動還原變更。
    • 您可以將 monitoring-operator 縮減至 0 個副本，然後編輯 KSM Deployment 來調整資源限制。不過，叢集不會透過 monitoring-operator 接收新修補程式版本提供的安全漏洞修補程式。叢集升級至修正後的較新版本後，請記得monitoring-operator調度資源。

• 減少 KSM 的指標數量。

  在 Google Distributed Cloud 1.13 中，KSM 預設只會公開少數指標，稱為核心指標。這表示資源用量比舊版更少，但您仍可按照相同程序進一步減少 KSM 指標數量。

  如果是 1.13 之前的 Google Distributed Cloud 版本，KSM 會使用預設旗標。這項設定會公開大量指標。

gke-metrics-agent 發生當機迴圈

如果 gke-metrics-agent 只在 kube-state-metrics 所在的節點上發生記憶體不足問題，原因就是 kube-state-metrics 指標數量過多。如要解決這個問題，請縮減 stackdriver-operator，並修改 KSM，只公開一小組必要指標，如上一節所述。叢集升級至 Google Distributed Cloud 1.13 後，請記得調高 stackdriver-operator，因為 KSM 預設會公開較少的 Core Metrics。

如果問題與記憶體不足事件無關，請檢查 Pods 記錄檔的 gke-metric-agent。如要調整所有 gke-metrics-agent Pod 的 CPU 和記憶體，請將 resourceAttrOverride 欄位新增至 Stackdriver 自訂資源。

stackdriver-metadata-agent 發生當機迴圈

症狀

在 Cloud Monitoring 中篩選指標時，無法使用系統中繼資料標籤。

原因

最常見的 stackdriver-metadata-agent 異常終止迴圈案例，是因記憶體不足事件所致。這項活動與 kube-state-metrics 類似，雖然 stackdriver-metadata-agent 並未列出所有資源，但仍會列出相關資源類型 (例如 Pod、Deployment 和 NetworkPolicy) 的所有物件。代理程式會以單一副本部署項目執行，如果物件數量過多，記憶體不足事件的風險就會增加。

受影響的版本

任何版本的 Google Distributed Cloud 都可能發生這個問題。

在過去幾個 Google Distributed Cloud 版本中，預設的 CPU 和記憶體限制已提高，因此這些資源問題應該會較不常見。

修正和解決方法

如要確認問題是否因記憶體不足而起，請按照下列步驟操作：

• 使用 kubectl describe pod 或 kubectl get pod -o yaml，並查看錯誤狀態訊息。
• 檢查 stackdriver-metadata-agent 的記憶體消耗量和使用率指標，確認是否在重新啟動前達到上限。

如果確認是記憶體不足導致問題，請在 Stackdriver 自訂資源的 resourceAttrOverride 欄位中提高記憶體限制。

metrics-server 發生當機迴圈

症狀

水平 Pod 自動調度器和 kubectl top 無法在叢集中運作。

原因和受影響的版本

這個問題並不常見，但如果叢集規模龐大或 Pod 密度高，就可能發生記憶體不足錯誤。

任何版本的 Google Distributed Cloud 都可能發生這個問題。

修正和解決方法

提高指標伺服器資源上限。 在 Google Distributed Cloud 1.13 以上版本中，metrics-server 及其設定的命名空間已從 kube-system 移至 gke-managed-metrics-server。

刪除 Cloud 稽核記錄服務帳戶時，並非所有資源都會一併移除

刪除用於 Cloud 稽核記錄的服務帳戶時，並非所有 Google Cloud資源都會遭到刪除。如果您經常刪除及重新建立用於 Cloud 稽核記錄的服務帳戶，最終稽核記錄會開始失敗。

症狀

Cloud 稽核記錄 Proxy 容器中會顯示「權限遭拒」錯誤訊息。

如要確認稽核記錄失敗是否是由這個問題所致，請執行下列指令：

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

將 PROJECT_NUMBER 替換為專案編號。

回應會傳回專案中所有搭配 Cloud Audit Logs 使用的服務帳戶，包括已刪除的服務帳戶。

原因和受影響的版本

刪除用於 Cloud Audit Logs 的服務帳戶時，並非所有 Google Cloud 資源都會移除，最終專案會達到 1000 個服務帳戶的上限。

任何版本的 Google Distributed Cloud 都可能發生這個問題。

修正和解決方法

1. 建立環境變數，其中包含要保留的所有服務帳戶清單 (以半形逗號分隔)。請用單引號括住每個服務帳戶電子郵件地址，並用雙引號括住整個清單。您可以從以下內容著手：

   SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"
   

   更改下列內容：

   • PROJECT_ID：您的專案 ID。
   • SERVICE_ACCOUNT_NAME：服務帳戶名稱。

   完成的清單應類似下列範例：

   "'[e-mail]','[e-mail]','[e-mail]'"
   

2. 執行下列指令，從專案中移除 Cloud 稽核記錄功能：

   curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging
   

   更改下列內容：

   • PROJECT_NUMBER：專案編號。
   • FLEET_REGION：叢集的車隊成員位置。這可以是特定區域，例如 us-central1 或 global。你可以執行 gcloud container fleet memberships list 指令來取得會員位置。

   這項指令會徹底刪除所有服務帳戶。

3. 只保留您想保留的服務帳戶，重新建立 Cloud Audit Logs 功能：

   curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
       -H "Content-Type: application/json" \
       https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
       -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'
   

後續步驟

如需其他協助，請與 Cloud Customer Care 團隊聯絡。

如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：

• 提出支援案件的規定。
• 工具，例如記錄和指標，可協助您排解問題。
• Google Distributed Cloud for VMware (僅限軟體) 的支援元件、版本和功能。