コントロール プレーンの指標を使用する


Google Kubernetes Engine(GKE)クラスタを構成して、Google Cloud Managed Service for Prometheus を使用し、Kubernetes API サーバー、スケジューラ、Controller Manager によって出力された特定の指標を Cloud Monitoring に送信できます。このドキュメントでは、Cloud Monitoring に書き込まれる際の指標の形式とクエリの方法について説明します。このドキュメントでは、各セットの指標の一覧表と、指標の使用方法についても説明します。

コントロール プレーンの指標を使用するには、そのコレクションを有効にする必要があります。

指標の形式

Cloud Monitoring に書き込まれる Kubernetes コントロール プレーンの指標はすべて、リソースタイプ prometheus_target を使用します。各指標名には接頭辞 prometheus.googleapis.com/ が使用され、Prometheus 指標タイプ(/gauge/histogram/counter など)を示す接尾辞が付いています。それ以外の場合、各指標名はオープンソースの Kubernetes によって公開される指標名と同一です。

Cloud Monitoring からのエクスポート

コントロール プレーンの指標は、Cloud Monitoring API を使用して Cloud Monitoring からエクスポートできます。コントロール プレーンのすべての指標が Google Cloud Managed Service for Prometheus を使用して取り込まれるため、Prometheus Query Language(PromQL)を使用してコントロール プレーンの指標をクエリできます。Monitoring Query Language(MQL)を使用してクエリすることもできます。

指標のクエリ

コントロール プレーンの指標をクエリするときに使用する名前は、PromQL と Cloud Monitoring ベースの機能(MQL、Metrics Explorer のメニュー形式のインターフェースなど)のどちらを使用するかによって異なります。

次のコントロール プレーン指標の表では、指標名ごとに 2 つのバージョンを示します。

  • PromQL の指標名: Google Cloud コンソールの Cloud Monitoring ページまたは Cloud Monitoring API の PromQL フィールドで PromQL を使用する場合は、PromQL の指標名を使用します。
  • Cloud Monitoring の指標名: 他の Monitoring 機能を使用する場合は、以下の表の Cloud Monitoring の指標名を使用します。この名前には prometheus.googleapis.com/ を付ける必要があります(表中の項目では省略されています)。

API サーバーの指標

このセクションでは、API サーバーの指標の一覧と、指標の解釈と使用に関する追加情報について説明します。

API サーバー指標のリスト

API サーバーの指標を有効にすると、次の表に示されているすべての指標が、GKE クラスタと同じプロジェクトの Cloud Monitoring にエクスポートされます。

この表の Cloud Monitoring の指標名には、prometheus.googleapis.com/ という接頭辞を付ける必要があります。この接頭辞は、表中の項目では省略されています。

PromQL 指標名リリース ステージ
Cloud Monitoring の指標名
種類、タイプ、単位
モニタリング対象リソース
必要な GKE バージョン
説明
ラベル
apiserver_current_inflight_requests 一般提供
apiserver_current_inflight_requests/gauge
GaugeDouble1
prometheus_target
1.22.13+
この apiserver で現在使用されている処理中のリクエストの上限(過去 1 秒間のリクエストの種類ごと)。

request_kind
apiserver_flowcontrol_current_executing_seatsベータ版
apiserver_flowcontrol_current_executing_seats/gauge
GaugeDouble1
prometheus_target
1.28.3+
API の優先度と公平性のサブシステムで現在実行中のリクエスト(WATCH の場合は最初のステージ、それ以外の場合は任意のステージ)が占有している同時実行数(シート数)。

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requestsベータ版
apiserver_flowcontrol_current_inqueue_requests/gauge
GaugeDouble1
prometheus_target
1.28.3 以降(以前のマイナー バージョンの場合は 1.25.16-gke.1360000 以降、1.26.11 以降、1.27.8 以降)
API 優先度と公平性のサブシステムのキューで現在保留中のリクエストの数。

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seatsベータ版
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ベータ版
apiserver_flowcontrol_rejected_requests_total/counter
CumulativeDouble1
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ベータ版
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 一般提供
apiserver_request_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
動詞、ドライラン値、グループ、バージョン、リソース、サブリソース、スコープ、コンポーネントごとのレスポンスのレイテンシの分布(秒)。

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total 一般提供
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 一般提供
apiserver_response_sizes/histogram
CumulativeDistribution1
prometheus_target
1.22.13+
グループ、バージョン、動詞、リソース、サブリソース、スコープ、コンポーネントごとのレスポンス サイズの分布(バイト単位)。

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects 一般提供
apiserver_storage_objects/gauge
GaugeDouble1
prometheus_target
1.22.13+
最終チェック時に保存されたオブジェクトの数(種類別)。

resource
apiserver_admission_controller_admission_duration_seconds 一般提供
apiserver_admission_controller_admission_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
アドミッション コントローラのレイテンシのヒストグラム(秒単位)。オペレーション、API リソースと種類(検証または承認)ごとに分類されます。

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds 一般提供
apiserver_admission_step_admission_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.22.13+
アドミッション サブステップのレイテンシのヒストグラム(秒単位)。オペレーションごとに API リソースとステップタイプ(検証または承認)で分類されます。

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds 一般提供
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 とシステム Webhook の呼び出し。
  • リクエストされたオブジェクトのメモリ内キャッシュ(resourceVersion URL パラメータを指定するリクエストの場合)または etcd(他のすべてのリクエストの場合)からの取得。
  • groupversionresourcesubresource ラベルを使用すると、低速なリクエストを一意に識別し、さらに詳しく調査できます。
  • クライアントへのレスポンスの書き込みとクライアントのレスポンスの受信

この指標の使用の詳細については、レイテンシをご覧ください。

この指標はカーディナリティが非常に高いため、この指標を使用する場合は、フィルタまたはグループ化を使用して特定のレイテンシの原因を確認する必要があります。

apiserver_admission_controller_admission_duration_seconds

この指標は、サードパーティの Webhook ではなく、組み込みアドミッション Webhook のレイテンシを測定します。サードパーティの Webook でレイテンシの問題を診断するには、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

この指標は、最後の 1 秒間にアクティブに配信されたリクエストの最大数を記録します。詳しくは、飽和度をご覧ください。

指標に「watch」などの長時間実行リクエストは含まれません。

API サーバーのモニタリング

API サーバーの指標から、システムの健全性に関する主なシグナルについて分析情報を得ることができます。

  • レイテンシ: リクエストの処理にはどれくらいの時間がかかるのか。
  • トラフィック: システムにどのくらいの需要があるのか。
  • エラー率: リクエストが失敗した頻度。
  • 飽和度: システムの完全性はどの程度か。

このセクションでは、API サーバーの指標を使用して API サーバーの状態をモニタリングする方法について説明します。

レイテンシ

API サーバーが過負荷になると、リクエストのレイテンシが増加します。API サーバーに対するリクエストのレイテンシを測定するには、apiserver_request_duration_seconds 指標を使用します。レイテンシの原因をより具体的に特定するには、verb ラベルまたは resource ラベルで指標をグループ化します。

GET、POST、PATCH などの単一リソース呼び出しで推奨される上限は 1 秒です。Namespace スコープとクラスタ スコープの両方の 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 ラベルの apiserver_admission_webhook_admission_duration_seconds 指標をグループ化して、特定の Webhook で発生している問題を診断することもできます。

  • 多くのオブジェクトを一覧表示しています。特定のタイプのオブジェクトの数(レスポンス サイズ)が増加すると、LIST 呼び出しのレイテンシが増加します。

  • クライアント側の問題:

    • クライアントに、レスポンスをタイムリーに受信するための十分なリソースがない可能性があります。確認するには、クライアント Pod の CPU 使用率の指標を確認します。
    • クライアントのネットワーク接続が遅くなっています。これは、クライアントがスマートフォンなどのデバイスで実行しているときに発生する可能性がありますが、Compute Engine ネットワークで実行されているクライアントでは可能性がほとんどありません。
    • クライアントが予期せず終了しましたが、TCP 接続のタイムアウト時間が数十秒に設定されています。接続がタイムアウトする前にサーバーのリソースがブロックされるため、レイテンシが増加する可能性があります。

トラフィックとエラー率

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]))
    
  • API サーバーにより Kubernetes コントロール プレーンのインスタンスごとに拒否されたリクエストをクエリするには、次の 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 バージョン
説明
ラベル
scheduler_pending_pods 一般提供
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 以降)
[v. 1.29 で非推奨になり、v. 1.30 で削除され scheduler_pod_scheduling_sli_duration_seconds に置き換えられます。] スケジューリングされる Pod の E2e レイテンシ。複数のスケジューリング試行を含む場合があります。

attempts
scheduler_pod_scheduling_sli_duration_secondsベータ版
scheduler_pod_scheduling_sli_duration_seconds/histogram
CumulativeDistribution1
prometheus_target
1.30+
Pod がスケジューリング キューに入った時点からの、スケジューリングされる Pod の E2e レイテンシ。複数のスケジューリング試行を含む場合があります。

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
CumulativeDouble1
prometheus_target
1.22.13+
現在までのクラスタ内のプリエンプション試行回数
scheduler_preemption_victims 一般提供
scheduler_preemption_victims/histogram
CumulativeDistribution1
prometheus_target
1.22.13+
選択したプリエンプションの対象数
scheduler_scheduling_attempt_duration_seconds 一般提供
scheduler_scheduling_attempt_duration_seconds/histogram
CumulativeDistribution1
prometheus_target
1.23.6+
スケジューリングのレイテンシ(秒単位)(スケジューリング アルゴリズムとバインディング)。

profile
result
scheduler_schedule_attempts_total 一般提供
scheduler_schedule_attempts_total/counter
CumulativeDouble1
prometheus_target
1.22.13+
Pod のスケジュール設定の試行回数(結果別)。「unschedulable」は、Pod をスケジュールできなかったことを表し、「error」は内部スケジューラの問題を表します。

profile
result

以下のセクションでは、API サーバーの指標について説明します。

scheduler_pending_pods

scheduler_pending_pods 指標を使用して、スケジューラの負荷をモニタリングできます。この指標の値が増加している場合、リソースに問題がある可能性があります。スケジューラには 3 つのキューがあり、この指標はキューごとに保留中のリクエストの数を報告します。次のキューがサポートされています。

  • 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 / Service の追加 / 更新、Pod の終了、新しいノードの登録などのイベントによって、スケジューリングされていない一部またはすべての Pod が backoff キューまたは active キューに移動します。詳細については、Kubernetes の問題 81214 をご覧ください。

詳細については、スケジューラのレイテンシリソースの問題をご覧ください。

scheduler_scheduling_attempt_duration_seconds

この指標は、スケジューラ内での 1 回のスケジューリングの所要時間を測定し、結果(スケジュール済み、スケジュール不可、エラー)で分類されます。この期間は、スケジューラが 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 用のスペースがないためにスケジューリングできない可能性があります。この場合、スケジューラはノード上で実行中の 1 つ以上の Pod をプリエンプトしてリソースを解放します。scheduler_preemption_attempts_total 指標は、スケジューラが Pod をプリエンプトしようとした回数を追跡します。

scheduler_preemptions_victims 指標は、プリエンプション用に選択された Pod をカウントします。

プリエンプションの試行回数は、result ラベルの値が unschedulable のときに scheduler_schedule_attempts_total 指標の値と強い相関関係があります。2 つの値は同じではありません。たとえば、クラスタのノードが 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 がスケジュールされているかどうかを判断するには、scheduler_pending_pods 指標の値を減らします。この指標の値が増加している場合は、ノードの追加が必要になることがあります。

更新やスケーリングなどのイベント中にクラスタ内でワークロードがスケジューリングされる予定の場合、scheduler_pending_pods 指標の値が一時的に急増することがあります。クラスタに十分なリソースがある場合、この急増は一時的なものになります。保留中の Pod の数が減少しない場合は、次の操作を行います。

  • ノードが閉鎖されていないことを確認します。閉鎖されたノードは新しい Pod を受け入れません。
  • 次のスケジューリング ディレクティブを確認します。これらが正しく構成されていないために、Pod をスケジューリングできない可能性があります。
    • ノードのアフィニティとセレクタ。
    • taint と toleration
    • Pod トポロジの分散の制約。

リソース不足で Pod をスケジューリングできない場合は、既存のノードを解放するか、ノード数を増やすことを検討してください。

コントローラ マネージャーの指標

コントローラ マネージャーの指標を有効にすると、次の表に示されているすべての指標が、GKE クラスタと同じプロジェクトの Cloud Monitoring にエクスポートされます。

この表の Cloud Monitoring の指標名には、prometheus.googleapis.com/ という接頭辞を付ける必要があります。この接頭辞は、表中の項目では省略されています。

PromQL 指標名リリース ステージ
Cloud Monitoring の指標名
種類、タイプ、単位
モニタリング対象リソース
必要な GKE バージョン
説明
ラベル
node_collector_evictions_total 一般提供
node_collector_evictions_total/counter
CumulativeDouble1
prometheus_target
1.24+
NodeController の現在のインスタンスの開始後に発生したノード エビクションの数。

zone