收集及查看控制層指標

本頁面說明如何設定 Google Kubernetes Engine (GKE) 叢集，透過 Google Cloud Managed Service for Prometheus，將 Kubernetes API 伺服器、排程器和控制器管理員發出的指標傳送至 Cloud Monitoring。本頁面也會說明這些指標寫入 Monitoring 時的格式，以及如何查詢指標。

事前準備

開始之前，請確認你已完成下列工作：

• 啟用 Google Kubernetes Engine API。
啟用 Google Kubernetes Engine API
• 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update，取得最新版本。

需求條件

如要將 Kubernetes 控制層元件發出的指標傳送至 Cloud Monitoring，必須符合下列需求：

• 叢集必須啟用系統指標。

設定收集控制層指標

您可以使用 Google Cloud 控制台、gcloud CLI 或 Terraform，在現有 GKE 叢集中啟用控制層指標。

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

配額

控制層指標會耗用 Cloud Monitoring API 的「每分鐘時間序列擷取要求」配額。啟用指標套裝組合前，請先查看該配額的近期用量尖峰。如果同一個專案中有多個叢集，或已接近配額上限，請先要求增加配額上限，再啟用任一可觀測性套件。

定價

GKE 控制層指標會使用 Google Cloud Managed Service for Prometheus，將指標載入 Cloud Monitoring。Cloud Monitoring 會根據擷取的樣本數，收取擷取這些指標的費用。不過，如果專案已啟用 GKE Enterprise 版本，則已註冊的叢集可免費使用這些指標。

詳情請參閱 Cloud Monitoring 定價。

指標格式

寫入 Cloud Monitoring 的所有 Kubernetes 控制層指標，都會使用 prometheus_target 資源類型。每個指標名稱都以 prometheus.googleapis.com/ 為前置字串，並加上後置字串來表示 Prometheus 指標類型，例如 /gauge、/histogram 或 /counter。否則，每個指標名稱都會與開放原始碼 Kubernetes 公開的指標名稱相同。

從 Cloud Monitoring 匯出

您可以使用 Cloud Monitoring API，從 Cloud Monitoring 匯出 Kubernetes 控制層指標。由於所有 Kubernetes 控制層指標都是使用 Google Cloud Managed Service for Prometheus 擷取，因此可以使用 Prometheus 查詢語言 (PromQL) 查詢 Kubernetes 控制層指標。您也可以使用 Monitoring Query Language (MQL) 查詢這些指標。

查詢指標

查詢 Kubernetes 控制層指標時，使用的名稱取決於您是否使用 PromQL，或是以 Cloud Monitoring 為基礎的功能，例如 MQL 或 Metrics Explorer 選單導向介面。

下表列出 Kubernetes 控制層指標，並顯示每個指標名稱的兩個版本：

• PromQL 指標名稱：在 Google Cloud 控制台的 Cloud Monitoring 頁面使用 PromQL，或在 Cloud Monitoring API 的 PromQL 欄位中，請使用 PromQL 指標名稱。
• Cloud Monitoring 指標名稱：使用其他 Cloud Monitoring 功能時，請使用下表中的 Cloud Monitoring 指標名稱。這個名稱必須加上 prometheus.googleapis.com/ 前置字串，但表格中的項目已省略這個字串。

API 伺服器指標

本節列出 API 伺服器指標，並提供解讀及使用指標的相關資訊。

API 伺服器指標清單

啟用 API 伺服器指標後，下表顯示的所有指標都會匯出至 Cloud Monitoring，並與 GKE 叢集位於同一個專案。

這個表格中的 Cloud Monitoring 指標名稱必須加上 prometheus.googleapis.com/ 前置字元。表格中的項目已省略該前置字串。

下列各節提供 API 伺服器指標的額外資訊。

apiserver_request_duration_seconds

您可以使用這項指標監控 API 伺服器的延遲時間。這項指標記錄的要求時間長度包括要求處理的所有階段，從收到要求到伺服器完成對用戶端的回應。具體來說，這項指標包含下列活動所花費的時間：

• 要求的驗證和授權。
• 呼叫與要求相關聯的第三方和系統 Webhook。
• 從記憶體內快取擷取所要求的物件 (適用於指定 resourceVersion 網址參數的要求)，或透過呼叫 etcd API 從以 etcd 或 Spanner 為基礎的叢集狀態資料庫擷取物件 (適用於所有其他要求)。
• 您可以使用 group、version、resource 和 subresource 標籤，找出速度緩慢的要求，以利進一步調查。
• 撰寫給用戶端的回應，並接收用戶端的回應。

如要進一步瞭解如何使用這項指標，請參閱「延遲」。

這項指標的基數非常高。使用這項指標時，請務必使用篩選器或分組功能，找出特定延遲來源。

apiserver_admission_controller_admission_duration_seconds

這項指標會測量內建許可 Webhook 的延遲時間，而非第三方 Webhook。如要診斷第三方 Webhook 的延遲問題，請使用 apiserver_admission_webhook_admission_duration_seconds 指標。

apiserver_admission_webhook_admission_duration_seconds和
apiserver_admission_step_admission_duration_seconds

這些指標會測量外部第三方許可 Webhook 的延遲時間。apiserver_admission_webhook_admission_duration_seconds指標通常是較實用的指標。如要進一步瞭解如何使用這項指標，請參閱「延遲時間」。

apiserver_request_total

您可以使用這項指標監控 API 伺服器的要求流量。您也可以使用這項功能，判斷要求的成功率和失敗率。如要進一步瞭解如何使用這項指標，請參閱「流量和錯誤率」。

這項指標的基數非常高。使用這項指標時，您必須使用篩選器或分組方式找出錯誤來源。

apiserver_storage_objects

這項指標可用來偵測系統飽和度，以及找出潛在的資源流失情況。詳情請參閱「飽和度」。

apiserver_current_inflight_requests

這項指標會記錄過去一秒內主動執行的最大要求數。詳情請參閱「飽和度」。

這項指標不包含「觀看」等長時間執行的要求。

監控 API 伺服器

API 伺服器指標可讓您深入瞭解系統健康狀態的主要信號：

• 延遲時間：處理要求需要多少時間？
• 流量：系統目前的需求量是多少？
• 錯誤率：要求失敗的頻率。
• 飽和度：系統的飽和程度。

本節說明如何使用 API 伺服器指標監控 API 伺服器的健康狀態。

延遲時間

API 伺服器過載時，要求延遲時間會增加。如要測量 API 伺服器的要求延遲時間，請使用 apiserver_request_duration_seconds 指標。如要更具體地找出延遲來源，可以依據 verb 或 resource 標籤將指標分組。

建議單一資源呼叫 (例如 GET、POST 或 PATCH) 的上限為一秒。建議命名空間範圍和叢集範圍的 LIST 呼叫上限為 30 秒。上限期望值是由開放原始碼 Kubernetes 社群定義的 SLO 所設定。詳情請參閱「API 呼叫延遲 SLI/SLO 詳細資料」。

如果 apiserver_request_duration_seconds 指標值超出預期時間範圍，請調查下列可能原因：

• Kubernetes 控制層可能過載。如要查看，請參閱 apiserver_request_total 和 apiserver_storage_objects 指標。
  • 使用 code 標籤判斷要求是否順利處理。如要瞭解可能的值，請參閱「HTTP 狀態碼」。
  • 使用 group、version、resource 和 subresource 標籤，即可識別要求。

• 第三方許可 Webhook 速度緩慢或沒有回應。 如果 apiserver_admission_webhook_admission_duration_seconds 指標的值增加，表示部分第三方或使用者定義的准入 Webhook 速度緩慢或沒有回應。許可 Webhook 的延遲時間可能會導致工作排程延遲。

  • 如要查詢每個 Kubernetes 控制層執行個體的第 99 個百分位數 Webhook 延遲時間，請使用下列 PromQL 查詢：

    sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))
    

    建議您也查看第 50、90、95 和 99.9 個百分位數，方法是修改 0.99 值來調整這項查詢。

  • 外部 Webhook 的逾時限制約為 10 秒。您可以針對 apiserver_admission_webhook_admission_duration_seconds 指標設定快訊政策，在即將發生 Webhook 超時時收到快訊。

  • 您也可以在 name 標籤上將指標分組，診斷特定 Webhook 可能發生的問題。apiserver_admission_webhook_admission_duration_seconds

• 您列出大量物件。預期 LIST 呼叫的延遲時間會隨著特定類型物件的數量 (回應大小) 增加而變長。

• 用戶端問題：

  • 用戶端可能沒有足夠資源，無法及時接收回應。如要檢查，請查看用戶端 Pod 的 CPU 使用率指標。
  • 用戶端的網路連線速度緩慢。如果用戶端在手機等裝置上執行，就可能發生這種情況，但如果用戶端在 Compute Engine 網路上執行，則不太可能發生這種情況。
  • 用戶端意外結束，但 TCP 連線的逾時時間為數十秒。連線逾時前，伺服器的資源會遭到封鎖，這可能會增加延遲時間。

詳情請參閱 Kubernetes 說明文件中的「API 優先順序和公平性使用最佳做法」。

流量和錯誤率

如要評估 API 伺服器的流量，以及成功和失敗的要求數量，請使用 apiserver_request_total 指標。舉例來說，如要測量每個 Kubernetes 控制層例項的 API 伺服器流量，請使用下列 PromQL 查詢：

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

• 如要查詢失敗的要求，請使用下列 PromQL 查詢，依 4xx 和 5xx 值篩選 code 標籤：

  sum(rate(apiserver_request_total{code=~"[45].."}[5m]))
  

• 如要查詢成功的要求，請使用下列 PromQL 查詢，依 2xx 值篩選 code 標籤：

  sum(rate(apiserver_request_total{code=~"2.."}[5m]))
  

• 如要查詢每個 Kubernetes 控制層執行個體遭 API 伺服器拒絕的要求，請使用下列 PromQL 查詢，依值 429 (http.StatusTooManyRequests) 篩選 code 標籤：

  sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))
  

飽和度

您可以使用 apiserver_current_inflight_requests 和 apiserver_storage_objects 指標，測量系統的飽和度。

如果 apiserver_storage_objects 指標的值不斷增加，可能是因為自訂控制器建立物件後未刪除，導致發生問題。您可以依據 resource 標籤篩選或分組指標，找出發生問題/ 增加的資源。

請根據 API 優先順序和公平性設定評估 apiserver_current_inflight_requests 指標；這些設定會影響要求的優先順序，因此您無法單從指標值得出結論。詳情請參閱「API 優先順序和公平性」。

排程器指標

本節提供排程器指標清單，以及解讀和使用這些指標的相關資訊。

排程器指標清單

啟用排程器指標後，下表顯示的所有指標都會匯出至與 GKE 叢集相同的專案，並顯示在 Cloud Monitoring 中。

這個表格中的 Cloud Monitoring 指標名稱必須加上 prometheus.googleapis.com/ 前置字元。表格中的項目已省略該前置字串。

下列各節提供 API 伺服器指標的額外資訊。

scheduler_pending_pods

您可以使用 scheduler_pending_pods 指標監控排程器的負載。如果這項指標的值增加，可能代表資源有問題。排程器有三個佇列，這項指標會依佇列回報待處理的要求數。系統支援下列佇列：

• active queue
  • 排程器嘗試排程的 Pod 集合；優先順序最高的 Pod 位於佇列開頭。
• backoff queue
  • 排程器上次嘗試排程時，這組 Pod 無法排程，但下次可能可以排程。
  • 這個佇列中的 Pod 必須等待輪詢期間結束 (最多 10 秒)，之後會移回 active 佇列，再次嘗試排程。如要進一步瞭解 backoff 佇列的管理方式，請參閱實作要求：Kubernetes 問題 75417。

• unschedulable 組

  • 排程器嘗試排程但判定為無法排程的 Pod 集合。佇列中的位置可能表示節點或節點選取器設定有就緒或相容性問題。

    如果資源限制導致無法排定 Pod，系統不會對 Pod 執行退避處理。如果叢集已滿，系統不會排定新 Pod 的時間，而是將其放入 unscheduled 佇列。

  • 如果出現未排程的 Pod，可能表示資源不足或節點設定有問題。在變更叢集狀態的事件發生後，Pod 會移至 backoff 或 active 佇列。這個佇列中的 Pod 表示叢集中沒有任何能使 Pod 進行排程的變更。

  • 親和性 定義 Pod 指派給節點的規則。使用親和性或反親和性規則，可能會導致未排程的 Pod 增加。

  • 部分事件 (例如 PVC/服務新增/更新、Pod 終止或新節點註冊) 會將部分或所有未排程的 Pod 移至 backoff 或 active 佇列。詳情請參閱 Kubernetes 問題 81214。

詳情請參閱「排程器延遲」和「資源問題」。

scheduler_scheduling_attempt_duration_seconds

這項指標會測量排程器內單一排程嘗試的持續時間，並依結果細分：已排程、無法排程或錯誤。這段時間從排程器選取 Pod 開始，到排程器找到節點並將 Pod 放置在節點上、判斷 Pod 無法排程，或發生錯誤為止。排程時間長度包括排程程序中的時間，以及繫結時間。繫結是排程器將節點指派作業傳達給 API 伺服器的程序。詳情請參閱「排程器延遲」。

這項指標不會擷取 Pod 在許可控制或驗證中花費的時間。

如要進一步瞭解排程，請參閱「為 Pod 排程」。

scheduler_schedule_attempts_total

這項指標會測量排程嘗試次數；每次嘗試排程 Pod 時，值就會增加。您可以使用這項指標判斷排程器是否可用：如果值增加，表示排程器正在運作。您可以使用 result 標籤判斷是否成功；Pod 為 scheduled 或 unschedulable。

這項指標與 scheduler_pending_pods 指標有很強的關聯性：如果待處理的 Pod 數量很多，您可能會看到許多排定 Pod 的嘗試。詳情請參閱「資源問題」。

如果排程器沒有要排程的 Pod，這項指標就不會增加，這可能是因為您有自訂的次要排程器。

scheduler_preemption_attempts_total 和 scheduler_preemptions_victims

您可以運用搶占指標，判斷是否需要新增資源。

您可能會有優先順序較高的 Pod，但由於沒有空間，因此無法排程。在這種情況下，排程器會先占用節點上的一或多個執行中 Pod，藉此釋出資源。scheduler_preemption_attempts_total 指標會追蹤排程器嘗試先佔 Pod 的次數。

scheduler_preemptions_victims 指標會計算選取要搶占的 Pod。

當 result 標籤的值為 unschedulable 時，先占用嘗試次數與 scheduler_schedule_attempts_total 指標值有很強的關聯性。這兩個值並不相等。舉例來說，如果叢集有 0 個節點，就不會嘗試搶占資源，但可能會嘗試排程，卻以失敗告終。

詳情請參閱「資源問題」。

監控排程器

排程器指標可協助您深入瞭解排程器的成效：

• 排程器延遲時間：排程器是否正在執行？排程 Pod 需要多久時間？
• 資源問題：排定 Pod 行程時是否遇到資源限制？

本節說明如何使用排程器指標監控排程器。

排程器延遲

排程器的工作是確保 Pod 執行，因此您會想知道排程器何時停滯或執行緩慢。

• 如要確認排程器是否正在執行及排程 Pod，請使用 scheduler_schedule_attempts_total 指標。

• 如果排程器執行速度緩慢，請調查下列可能原因：

  • 待處理的 Pod 數量增加。使用 scheduler_pending_pods 指標監控待處理 Pod 的數量。下列 PromQL 查詢會傳回叢集中每個佇列的待處理 Pod 數量：

    sum by (queue)
    (delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))
    

  • 排程 Pod 的個別嘗試速度緩慢。使用 scheduler_scheduling_attempt_duration_seconds 指標監控排程嘗試的延遲時間。

    建議您至少觀察第 50 和第 95 百分位數的指標。下列 PromQL 查詢會擷取第 95 個百分位數的值，但您可以調整：

    sum by (instance) (histogram_quantile(0.95, rate(
    scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))
    

資源相關問題

排程器指標也有助於評估資源是否充足。如果 scheduler_preemption_attempts_total 指標的值正在增加，請使用下列 PromQL 查詢檢查 scheduler_preemption_victims 的值：

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

如有優先順序較高的 Pod 要排程，先佔嘗試次數和先佔受害者人數都會增加。先占指標不會告訴您觸發先占的高優先順序 Pod 是否已排定時間，因此當您看到先占指標值增加時，也可以監控 scheduler_pending_pods 指標的值。如果待處理的 Pod 數量也增加，則您可能沒有足夠的資源來處理優先順序較高的 Pod；您可能需要擴充可用資源、建立資源聲明減少的新 Pod，或變更節點選取器。

• 如果遭搶占的 Pod 數量沒有增加，表示沒有可移除的低優先順序 Pod。在這種情況下，請考慮新增更多節點，以便分配新的 Pod。

• 如果搶占受害者的數量增加，表示有優先順序較高的 Pod 等待排程，因此排程器會搶占部分正在執行的 Pod。搶占指標不會顯示優先順序較高的 Pod 是否已成功排程。

  如要判斷優先順序較高的 Pod 是否正在排程，請查看 scheduler_pending_pods 指標的值是否正在減少。如果這個指標的值不斷增加，您可能需要新增更多節點。

當叢集要排定工作負載時 (例如更新或擴縮期間)，scheduler_pending_pods 指標的值可能會暫時飆升。如果叢集資源充足，這些尖峰用量只是暫時現象。 如果待處理 Pod 的數量沒有減少，請採取下列行動：

• 確認節點未遭封鎖；遭封鎖的節點無法接受新的 Pod。
• 請檢查下列排程指令，這些指令可能設定錯誤，導致 Pod 無法排程：
  • 節點相依性和選取器。
  • Taint 和容許條件。
  • Pod 拓撲散布限制。

如果 Pod 因資源不足而無法排程，請考慮釋出部分現有節點的資源，或增加節點數量。

控制器管理工具指標

啟用控制器管理員指標後，下表顯示的所有指標都會匯出至 Cloud Monitoring，並與 GKE 叢集位於同一個專案。

這個表格中的 Cloud Monitoring 指標名稱必須加上 prometheus.googleapis.com/ 前置字元。表格中的項目已省略該前置字串。