收集及查看控制層指標

本頁說明如何設定 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 指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文件中的指令。

需求條件

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

設定控制層指標的收集作業

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

控制台

如要為叢集啟用控制層指標，可以前往叢集的「Observability」(可觀測性) 分頁，或是叢集的「Details」(詳細資料) 分頁。使用「可觀測性」分頁時，您可以先預覽可用的圖表和指標，再啟用指標套件。

如要從叢集的「Observability」(觀測能力) 分頁啟用控制層指標，請按照下列步驟操作：

  1. 在 Google Cloud 控制台中，前往「Kubernetes clusters」(Kubernetes 叢集) 頁面：

    前往「Kubernetes clusters」(Kubernetes 叢集)

    如果您是使用搜尋列尋找這個頁面，請選取子標題為「Kubernetes Engine」的結果。

  2. 按一下叢集名稱，然後選取「可觀測性」Observability分頁標籤。

  3. 從功能清單中選取「Control Plane」(控制層)。

  4. 按一下「啟用套件」。

    如果控制層指標已啟用，您會看到一組控制層指標圖表。

如要從叢集的「詳細資料」分頁啟用控制層指標，請按照下列步驟操作：

  1. 在 Google Cloud 控制台中，前往「Kubernetes clusters」(Kubernetes 叢集) 頁面：

    前往「Kubernetes clusters」(Kubernetes 叢集)

    如果您是使用搜尋列尋找這個頁面，請選取子標題為「Kubernetes Engine」的結果。

  2. 按一下叢集名稱。

  3. 在標示為「Cloud Monitoring」的「功能」列中，按一下「編輯」圖示。

  4. 在隨即顯示的「Edit Cloud Monitoring」(編輯 Cloud Monitoring) 對話方塊中，確認已選取「Enable Cloud Monitoring」(啟用 Cloud Monitoring)。

  5. 在「元件」下拉式選單中，選取要收集指標的控制層元件：API 伺服器、排程器或控制器管理工具。

  6. 按一下 [確定]。

  7. 按一下 [儲存變更]。

gcloud

更新叢集，收集 Kubernetes API 伺服器、排程器和控制器管理工具發出的指標：

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

更改下列內容：

Terraform

如要使用 Terraform 設定 Kubernetes 控制層指標的收集作業，請參閱 google_container_cluster 的 Terraform 登錄檔中的 monitoring_config 區塊。如要瞭解如何搭配使用 Google Cloud 與 Terraform，請參閱「Terraform with Google Cloud」。

配額

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

定價

GKE 控制層指標會使用 Google Cloud Managed Service for Prometheus，將指標載入 Cloud Monitoring。Cloud Monitoring 會根據擷取的樣本數，收取擷取這些指標的費用。

詳情請參閱「Cloud Monitoring 定價」。

指標格式

寫入 Cloud Monitoring 的所有 Kubernetes 控制層指標，都會使用資源類型 prometheus_target。 每個指標名稱都以 prometheus.googleapis.com/ 為前置字串，並以 /gauge、/histogram 或 /counter 等後置字串表示 Prometheus 指標類型。否則，每個指標名稱都與開放原始碼 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/ 前置字元。表格中的項目已省略該前置字元。

PromQL 指標名稱推出階段
Cloud Monitoring 指標名稱
種類、類型、單位
受監控資源
必要的 GKE 版本		 說明
標籤
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.23.6+ 		准入控制器延遲時間直方圖 (以秒為單位)，依名稱識別，並依各項作業、API 資源和類型 (驗證或准入) 細分。

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.22.13+ 		以秒為單位的許可子步驟延遲時間直方圖，按照各項作業、API 資源和步驟類型 (驗證或許可) 細分。

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.22.13 以上版本 		許可 Webhook 延遲時間直方圖 (以秒為單位)，依名稱識別，並針對每個作業、API 資源和類型 (驗證或許可) 細分。

name
operation
rejected
type
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge、Double、1
prometheus_target
1.22.13 以上版本 		過去一秒內，這個 API 伺服器目前使用的每個要求種類，其進行中要求數上限。

request_kind
apiserver_flowcontrol_current_executing_seats Beta 版
apiserver_flowcontrol_current_executing_seats/gauge
Gauge、Double、1
prometheus_target
1.28.3+ 		API Priority and Fairness 子系統中，目前執行的要求 (WATCH 的初始階段，否則為任何階段) 所占用的並行數 (席位數)。

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests Beta 版
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge、Double、1
prometheus_target
1.28.3 以上版本 (舊子版本為 1.25.16-GKE.1360000 以上、1.26.11 以上、1.27.8 以上) 		目前在 API Priority and Fairness 子系統佇列中待處理的要求數。

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats Beta 版
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge、Double、1
prometheus_target
1.28.3+ (1.26.11+、1.27.8+ 適用於先前的子版本) 		為每個優先順序層級設定的執行席位名義數量。

priority_level
apiserver_flowcontrol_rejected_requests_total Beta 版
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative、Double、1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+、1.26.11+、1.27.8+ 適用於先前的子版本) 		API 優先順序和公平性子系統拒絕的要求數量。

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds Beta 版
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+、1.26.11+、1.27.8+ 適用於先前的子版本) 		要求在佇列中等待的時間長度。

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.23.6+ 		各個動詞、模擬測試值、群組、版本、資源、子資源、範圍和元件的回應延遲時間分布情形 (以秒為單位)。

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative、Double、1
prometheus_target
1.22.13 以上版本 		依據每個動詞、模擬執行值、群組、版本、資源、範圍、元件和 HTTP 回應代碼細分的 apiserver 要求計數器。

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative、Distribution、1
prometheus_target
1.22.13 以上版本 		各群組、版本、動詞、資源、子資源、範圍和元件的回應大小分布 (以位元組為單位)。

component
group
resource
scope
subresource
verb
version
apiserver_storage_events_received_total Beta 版
apiserver_storage_events_received_total/counter
Cumulative、Int64、1
prometheus_target
1.36.0-gke.1759000+ 		收到的 etcd 事件數 (依類型劃分)。

group
resource
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge、Double、1
prometheus_target
1.22.13 以上版本 		上次檢查時的已儲存物件數量，按種類劃分。

resource
apiserver_storage_size_bytes GA
apiserver_storage_size_bytes/gauge
Gauge、Int64、By
prometheus_target
1.36.0-gke.1759000+ 		以位元組為單位，實際配置的儲存空間資料庫檔案大小。

storage_cluster_id
apiserver_watch_list_duration_seconds Beta 版
apiserver_watch_list_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.36.0-gke.1759000+ 		監控清單要求的回應延遲時間分布 (以秒為單位)，並依群組、版本、資源和範圍細分。

group
resource
scope
version

下列各節提供 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

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

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

監控 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 標籤將 apiserver_admission_webhook_admission_duration_seconds 指標分組，診斷特定 Webhook 的可能問題。

  • 您列出許多物件。可以預期的是，隨著特定類型的物件數量 (回應大小) 增加，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 查詢，篩選 code 標籤的 4xx 和 5xx 值：

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

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

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

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

    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 優先順序和公平性」。

排程器指標

本節列出排程器指標，並提供解讀及使用指標的額外資訊。

排程器指標清單

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

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

PromQL 指標名稱推出階段
Cloud Monitoring 指標名稱
種類、類型、單位
受監控資源
必要的 GKE 版本		 說明
標籤
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
Gauge、Double、1
prometheus_target
1.31.1-gke.1621000+ 		叢集上工作負載的資源限制，按 Pod 細分。 這會顯示排程器和 kubelet 預期每個 Pod 的資源用量，以及資源單位 (如有)。

namespace
node
pod
priority
resource
scheduler
unit
kube_pod_resource_request GA
kube_pod_resource_request/gauge
Gauge、Double、1
prometheus_target
1.31.1-gke.1621000+ 		叢集上工作負載要求的資源，依 Pod 細分。 這會顯示排程器和 kubelet 預期每個 Pod 的資源用量，以及資源單位 (如有)。

namespace
node
pod
priority
resource
scheduler
unit
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge、Double、1
prometheus_target
1.22.13+ 		待處理的 Pod 數量 (依佇列類型)。「active」是指 activeQ 中的 Pod 數量；「backoff」是指 backoffQ 中的 Pod 數量；「unschedulable」是指 unschedulablePods 中的 Pod 數量。

queue
scheduler_pod_scheduling_duration_seconds 已淘汰
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative、Distribution、1
prometheus_target
1.25.1 至 1.29 (1.22.17-gke.3100+、1.23.11+ 和 1.24.5+ 適用於先前的子版本) 		[v. 1.29 版已淘汰；v. 1.30 版已移除，並由 scheduler_pod_scheduling_sli_duration_seconds 取代。]排定 Pod 排程的端對端延遲時間，可能包含多次排程嘗試。

attempts
scheduler_pod_scheduling_sli_duration_seconds Beta 版
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative、Distribution、1
prometheus_target
1.30 以上版本 		Pod 排程的端對端延遲時間，從 Pod 進入排程佇列開始計算，可能涉及多次排程嘗試。

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative、Double、1
prometheus_target
1.22.13+ 		叢集目前為止的先占嘗試總次數
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative、Distribution、1
prometheus_target
1.22.13 以上版本 		選取的搶占受害者數量
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative、Distribution、1
prometheus_target
1.23.6+ 		排程嘗試延遲時間 (以秒為單位，排程演算法 + 繫結)。

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative、Double、1
prometheus_target
1.22.13 以上版本 		排程器嘗試安排 Pod 時程的次數，按照結果細分。「無法排程」表示無法安排該 Pod 的時程，「錯誤」則代表排程器發生內部錯誤。

profile
result

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

scheduler_pending_pods

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

  • active 佇列
    • 排程器嘗試排程的 Pod 集合；優先順序最高的 Pod 位於佇列開頭。
  • backoff 佇列
    • 排程器上次嘗試排程時，這組 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，請使用 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，請考慮釋出部分現有節點，或增加節點數量。

控制器管理工具指標

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

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

PromQL 指標名稱推出階段
Cloud Monitoring 指標名稱
種類、類型、單位
受監控資源
必要的 GKE 版本		 說明
標籤
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative、Double、1
prometheus_target
1.24+ 		自 NodeController 目前的執行個體啟動以來，發生的節點逐出次數。

zone

後續步驟