排解 Google Distributed Cloud 觀測能力問題

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

如需其他協助，請與

系統不會收集 Cloud 稽核記錄

除非在叢集設定的 clusterOperations 區段下設定 disableCloudAuditLogging 旗標，否則系統會預設啟用 Cloud 稽核記錄。

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

Cloud 稽核記錄 Proxy 容器會在所有 Google Distributed Cloud 叢集中以 DaemonSet 形式執行。

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

另一個可能原因為專案可能已達到支援的服務帳戶上限，請參閱「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 仍可能成為瓶頸。

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

  • 如果是 1.16.0 之前的版本，如要調整 KSM 的 CPU 和記憶體，請使用 Stackdriver 自訂資源的 resourceOverride kube-state-metrics。

• 減少 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。

如果問題與記憶體不足事件無關，請檢查 gke-metric-agent 的 Pod 記錄。如要調整所有 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 稽核記錄 使用的服務帳戶，包括已刪除的服務帳戶。

原因和受影響的版本

刪除用於 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 稽核記錄功能：

   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]}}}'
   

指標中的中繼資料標籤消失

症狀

中繼資料標籤 (例如 node_name) 不會填入 Cloud Monitoring。

原因和受影響的版本

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

修正方式和解決方法

對 Pod 進行任何變更都會還原中繼資料標籤。例如執行 kubectl rollout restart deployment <workload_name> 等指令。

後續步驟

如需其他協助，請與我們聯絡：