本文可協助您排解 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 無法提供這些摘要 API 指標,
- 在叢集中,檢查 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 的記憶體要求和限制。
如果是 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
。如要調整所有 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
的記憶體消耗量和使用率指標,確認是否在重新啟動前達到上限。
resourceAttrOverride
欄位中提高記憶體限制。
metrics-server
發生當機迴圈
症狀
水平 Pod 自動調度器和 kubectl top
無法在叢集中運作。
原因和受影響的版本
這個問題並不常見,但如果叢集規模龐大或 Pod 密度高,就可能發生記憶體不足錯誤。
任何版本的 Google Distributed Cloud 都可能發生這個問題。
修正和解決方法
提高指標伺服器資源上限。
在 Google Distributed Cloud 1.13 以上版本中,metrics-server
及其設定的命名空間已從 kube-system
移至 gke-managed-metrics-server
。
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 都可能發生這個問題。
修正和解決方法
建立環境變數,其中包含要保留的所有服務帳戶清單 (以半形逗號分隔)。請用單引號括住每個服務帳戶電子郵件地址,並用雙引號括住整個清單。您可以從以下內容著手:
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'"
執行下列指令,從專案中移除 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
指令來取得會員位置。
這項指令會徹底刪除所有服務帳戶。
只保留您想保留的服務帳戶,重新建立 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 團隊聯絡。如要進一步瞭解支援資源,包括下列項目,請參閱「取得支援」: