排解 Google Distributed Cloud 觀測能力問題

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

如需其他協助,請與 Cloud Customer Care 團隊聯絡。如要進一步瞭解支援資源,包括下列項目,請參閱「取得支援」:

系統未收集 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 podkubectl get pod -o yaml,並查看錯誤狀態訊息。
  • 檢查 KSM 的記憶體消耗量和使用率指標,確認是否達到限制而重新啟動。

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

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

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

如果是 Google Distributed Cloud,系統會在叢集更新或升級時還原保母設定。您必須重新套用設定變更。如要解決這項限制,請縮減 metrics-server-operator 並手動變更 metrics-server Pod

刪除 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:服務帳戶名稱。

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

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"
    
  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-central1global。你可以執行 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 團隊聯絡。如要進一步瞭解支援資源,包括下列項目,請參閱「取得支援」: