收集及查看控制層指標


本頁面說明如何設定 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 叢集中啟用控制層指標。

控制台

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

如要從叢集的「可觀測性」分頁啟用控制層指標,請按照下列步驟操作:

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

    前往「Kubernetes clusters」(Kubernetes 叢集)

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

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

  3. 從功能清單中選取「控制平面」

  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 會根據擷取的樣本數,收取擷取這些指標的費用。不過,如果專案已啟用 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/ 前置字元。表格中的項目已省略該前置字串。

PromQL 指標名稱 推出階段
Cloud Monitoring 指標名稱
種類、類型、單位
受監控的資源
必要 GKE 版本
說明
標籤
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
GaugeDouble1
prometheus_target
1.22.13+
過去一秒內,這個 API 伺服器每種要求類型目前使用的進行中要求數上限。

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
GaugeDouble1
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
GaugeDouble1
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
GaugeDouble1
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
CumulativeDouble1
prometheus_target
1.28.3 以上版本 (先前次要版本為 1.25.16-gke.1360000 以上、1.26.11 以上、1.27.8 以上)
API Priority and Fairness 子系統拒絕的要求數量。

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
CumulativeDistributions
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
CumulativeDistributions
prometheus_target
1.23.6+
每個動詞、試執行值、群組、版本、資源、子資源、範圍和元件的回應延遲時間分布 (以秒為單位)。

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
CumulativeDouble1
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
CumulativeDistribution1
prometheus_target
1.22.13+
各群組、版本、動詞、資源、子資源、範圍和元件的回應大小分布 (以位元組為單位)。

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
GaugeDouble1
prometheus_target
1.22.13+
上次檢查時的已儲存物件數量,並依種類細分。

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
以秒為單位的准入控制器延遲時間直方圖,依名稱識別,並針對每個作業、API 資源和類型 (驗證或允許) 細分。

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

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

name
operation
rejected
type

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

apiserver_request_duration_seconds

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

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

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

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

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 指標。如要更具體地找出延遲來源,可以依據 verbresource 標籤將指標分組。

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

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

  • Kubernetes 控制層可能過載。如要查看,請參閱 apiserver_request_totalapiserver_storage_objects 指標。
    • 使用 code 標籤判斷要求是否順利處理。如要瞭解可能的值,請參閱「HTTP 狀態碼」。
    • 使用 groupversionresourcesubresource 標籤,即可識別要求。
  • 第三方許可 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_requestsapiserver_storage_objects 指標,測量系統的飽和度。

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

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

排程器指標

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

排程器指標清單

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

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

PromQL 指標名稱 推出階段
Cloud Monitoring 指標名稱
種類、類型、單位
受監控的資源
必要 GKE 版本
說明
標籤
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
GaugeDouble1
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
GaugeDouble1
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
GaugeDouble1
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
CumulativeDistribution1
prometheus_target
1.25.1 至 1.29 (先前次要版本的 1.22.17-gke.3100 以上版本、1.23.11 以上版本和 1.24.5 以上版本)
[在 1.29 版中已淘汰;在 1.30 版中已移除,並由 scheduler_pod_scheduling_sli_duration_seconds 取代。] Pod 排程的端對端延遲時間,可能包含多次排程嘗試。

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

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
CumulativeDouble1
prometheus_target
1.22.13+
叢集至今的先占嘗試總次數
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
CumulativeDistribution1
prometheus_target
1.22.13+
選取的搶占受害者數量
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
CumulativeDistribution1
prometheus_target
1.23.6+
排程嘗試延遲時間 (以秒為單位,排程演算法 + 繫結)。

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
CumulativeDouble1
prometheus_target
1.22.13+
排程 Pod 的嘗試次數 (依結果分類)。「無法排程」表示無法安排該 Pod 的時程,「錯誤」則代表內部排程器發生問題。

profile
result

下列各節提供 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 會移至 backoffactive 佇列。這個佇列中的 Pod 表示叢集中沒有任何能使 Pod 進行排程的變更。

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

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

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

scheduler_scheduling_attempt_duration_seconds

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

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

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

scheduler_schedule_attempts_total

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

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

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

scheduler_preemption_attempts_totalscheduler_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 因資源不足而無法排程,請考慮釋出部分現有節點的資源,或增加節點數量。

控制器管理工具指標

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

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

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

zone