すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:kube-apiserver: Metrics and dashboard

最終更新日:Sep 11, 2026

Container Service for Kubernetes (ACK) クラスターにおける kube-apiserver の健全性を監視します。このコンポーネントは Kubernetes RESTful API を提供し、外部クライアントやクラスター内の他のコンポーネントがクラスターと対話できるようにします。このトピックのメトリックリスト、ダッシュボードガイダンス、および異常分析を使用して、問題を診断してください。

注意事項

ダッシュボードへのアクセス

「コントロールプレーンコンポーネントのダッシュボードの表示」をご参照ください。

メトリック

メトリックは、コンポーネントがそのステータスとパラメーターを公開する方法の 1 つです。次の表に、kube-apiserver のメトリックを示します。

メトリック

タイプ

説明

apiserver_request_duration_seconds_bucket

ヒストグラム

API サーバーへのクライアントリクエストのレイテンシー分布。

ディメンション:

  • Verb:GET、POST、PUT、DELETE などのリクエストタイプ。

  • Group:API グループ。Kubernetes API を拡張するための関連インターフェイスのコレクション。

  • Version:API バージョン。v1 や v1beta1 など。

  • Resource:ターゲットリソースタイプ。Pod、Service、Lease など。

  • Subresource:ターゲットリソースのサブリソース。Pod の詳細や Pod のログなど。

  • Scope:リクエストのスコープ。namespace-scoped や cluster-scoped など。

  • Component:リクエスト元のコンポーネント。kube-controller-manager、kube-scheduler、cloud-controller-manager など。

  • Client:リクエスト元のクライアント。内部コンポーネントまたは外部サービス。

API サーバーのヒストグラムのバケットしきい値:{0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.25, 1.5, 1.75, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5, 6, 7, 8, 9, 10, 15, 20, 25, 30, 40, 50, 60}。単位:秒。

apiserver_request_total

カウンター

API サーバーへのリクエストの合計。Verb、Group、Version、Resource、Scope、Component、HTTP contentType、HTTP code (レスポンスステータスコード)、Client 別に分類されます。

apiserver_request_no_resourceversion_list_total

カウンター

resourceVersion パラメーターなしで API サーバーに送信された LIST リクエスト。過剰なクォーラムリードの LIST リクエストとそれを送信するクライアントを特定し、クライアントリクエストの動作を最適化してクラスターのパフォーマンスを向上させるのに役立ちます。Group、Version、Resource、Scope、Client 別に分類されます。

apiserver_current_inflight_requests

ゲージ

API サーバーが現在処理中のリクエスト。これらは 2 つのタイプに分類されます:

  • ReadOnly:Pod の一覧表示やノードのステータス照会など、クラスターの状態を変更しないリクエスト。

  • Mutating:Pod の作成や Service 構成の更新など、リソースの作成、更新、削除を行う、クラスターの状態を変更するリクエスト。

apiserver_dropped_requests_total

カウンター

速度制限中は、API サーバーはリクエストを破棄し、 HTTP ステータスコード 429 'Try again later' を返します。

etcd_request_duration_seconds_bucket

ヒストグラム

API サーバーから etcd へのリクエストレイテンシー分布。

操作とオブジェクトタイプ別に分類されます。

バケットしきい値:{0.005, 0.025, 0.05, 0.1, 0.2, 0.4, 0.6, 0.8, 1.0, 1.25, 1.5, 2, 3, 4, 5, 6, 8, 10, 15, 20, 30, 45, 60}。単位:秒。

apiserver_storage_db_size_in_use_quota_bytes

ゲージ

etcd データベースに設定されたストレージクォータ。この制限に達すると、書き込みリクエストは拒否されます。単位:バイト。

apiserver_storage_db_size_in_use_bytes

ゲージ

etcd が現在使用しているデータストレージの量。単位:バイト。

apiserver_flowcontrol_request_concurrency_limit

ゲージ

API の優先度と公平性 (APF) のスロットリング下で、優先度付きキューが同時に処理できる理論上の最大リクエスト数。API サーバーがトラフィック制御ポリシーを使用して、優先度の高いリクエストが遅延なく処理されるように、優先度付きキュー間でキャパシティをどのように割り当てるかを示します。

Kubernetes 1.30 で非推奨となり、1.31 で削除されました。Kubernetes 1.31 以降を実行しているクラスターでは、代わりに apiserver_flowcontrol_nominal_limit_seats メトリックを使用してください。

apiserver_flowcontrol_current_executing_requests

ゲージ

優先度付きキューで現在実行中のリクエストで、実際の同時実行負荷を表します。同時実行数制限とともに監視して、API サーバーが飽和状態に近づいているかどうかを判断します。

apiserver_flowcontrol_current_inqueue_requests

ゲージ

優先度付きキューで待機中のリクエスト。バックログの増加は、API サーバーへのトラフィック圧力と、キューの過負荷の可能性を示します。

apiserver_flowcontrol_nominal_limit_seats

ゲージ

APF 下での API サーバーにおける名目上の最大同時実行シート数。トラフィック制御ポリシーが優先度付きキュー間でキャパシティをどのように割り当てるかを示します。単位:シート。

apiserver_flowcontrol_current_limit_seats

ゲージ

優先度付きキューに対する現在の APF 同時実行数制限 (シート単位)。動的調整後に許可される最大同時実行シート数です。この値はキューの実際の同時実行キャパシティを反映し、システム負荷やその他の要因によって動的に変化する可能性があります。

nominal_limit_seats とは異なり、この値はグローバルなトラフィック制御ポリシーの影響を受ける可能性があります。

apiserver_flowcontrol_current_executing_seats

ゲージ

優先度付きキューで現在実行中のリクエストによって消費されているシート数で、実際の負荷を反映します。

current_executing_seats が current_limit_seats に近づくと、キューの同時実行リソースがまもなく枯渇する可能性があります。

構成を最適化するには、API サーバーの maxMutatingRequestsInflight と maxRequestsInflight の値を上げてください。詳細については、「ACK Pro マネージドクラスターのコントロールプレーンコンポーネントのパラメーターをカスタマイズする」をご参照ください。

apiserver_flowcontrol_current_inqueue_seats

ゲージ

優先度付きキューで待機中のリクエストが占有するシート数で、保留中のバックログを表します。

apiserver_flowcontrol_request_execution_seconds_bucket

ヒストグラム

リクエストの実行時間 (開始から完了まで)。

バケットしきい値は {0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30} です。単位:秒。

apiserver_flowcontrol_request_wait_duration_seconds_bucket

ヒストグラム

リクエストが実行開始前にキューで待機する時間。

バケットしきい値は {0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30} です。単位:秒。

apiserver_flowcontrol_dispatched_requests_total

カウンター

APF 下で API サーバーによって正常にディスパッチされたリクエストの合計。

apiserver_flowcontrol_rejected_requests_total

カウンター

同時実行数制限またはキューキャパシティを超えたために拒否されたリクエスト。

apiserver_admission_controller_admission_duration_seconds_bucket

ヒストグラム

アドミッションコントローラーの処理レイテンシー。ラベル:コントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ、拒否ステータス (true または false)。操作タイプは、リクエストが有効かどうかをチェックする validate と、有効なリクエストを許可するかどうかを決定する admit があります。

バケットしきい値:{0.005, 0.025, 0.1, 0.5, 2.5}。単位:秒。

apiserver_admission_webhook_admission_duration_seconds_bucket

ヒストグラム

アドミッション Webhook の処理レイテンシー。ラベル:Webhook 名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (admit または validating)、拒否ステータス (true または false)。

バケットしきい値:{0.005, 0.025, 0.1, 0.5, 2.5}。単位:秒。

apiserver_admission_webhook_admission_duration_seconds_count

カウンター

アドミッション Webhook によって処理されたリクエスト。ラベル:Webhook 名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (admit または validating)、拒否ステータス (true または false)。

cpu_utilization_core

ゲージ

使用中の CPU コア数。単位:コア。

memory_utilization_byte

ゲージ

使用中のメモリ量。単位:バイト。

resource_utilization_level

ゲージ

リソース使用率レベル。

  • resource:リソースタイプ。有効な値:cpu および memory。

  • utilization_level:使用率レベル。有効な値:high (使用率 ≥ 80%) および normal (使用率 < 80%)。

  • container:ターゲットコンテナ。有効な値:kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager、および etcd。

up

ゲージ

サービスが利用可能かどうかを示します。

  • 1:サービスは利用可能です。

  • 0:サービスは利用できません。

説明

以下のリソース使用率メトリックは使用されなくなりました。これらのメトリックに依存するアラートや監視ルールは削除してください:

  • cpu_utilization_ratio:CPU 使用率。

  • memory_utilization_ratio:メモリ使用率。

ダッシュボード

ダッシュボードは、コンポーネントのメトリックと関連する PromQL クエリから構築されます。

最も一般的に使用される順序でのダッシュボードパネル:

  1. 主要メトリック:主要なクラスターメトリックの概要をすばやく把握します。

  2. 概要:API サーバーのレスポンスレイテンシー、処理中のリクエスト数、およびスロットリングイベントを分析します。

  3. リソース分析:マネージドコンポーネントのリソース使用率レベルを確認します。

  4. QPS とレイテンシー:秒間クエリ数 (QPS) とレスポンスタイム (RT) の詳細な多次元分析を実行します。

  5. APF スロットリング:APF メトリックを使用して、API サーバーのリクエストトラフィック分布、スロットリングステータス、およびシステムパフォーマンスのボトルネックを分析します。

  6. アドミッションコントローラーと Webhook:アドミッションコントローラーと Webhook の QPS と RT を分析します。

  7. クライアント分析:クライアント別の QPS の多次元分析を実行します。

フィルター

ダッシュボードの上にあるフィルターを使用して、API サーバーリクエストの Verb、Resource、Quantile、およびパネルが使用する PromQL のサンプリング Interval を設定します。

0.9 (P90) の分位数は、ヒストグラムサンプルの 90% がその値以下であることを示し、ロングテールの外れ値を除外します。0.99 (P99) の分位数は、ロングテールのサンプルを含みます。

Filters

次のフィルターを使用して、時間範囲と更新間隔を選択します。 Filters 2

主要メトリック

ダッシュボードビュー 100

メトリックの詳細

名前

PromQL

説明

API QPS

sum(irate(apiserver_request_total[$interval]))

API サーバーの合計 QPS。

読み取りリクエスト成功率

sum(irate(apiserver_request_total{code=~"20.*",verb=~"GET|LIST"}[$interval]))/sum(irate(apiserver_request_total{verb=~"GET|LIST"}[$interval]))

API サーバーの読み取りリクエスト成功率。

書き込みリクエスト成功率

sum(irate(apiserver_request_total{code=~"20.*",verb!~"GET|LIST|WATCH|CONNECT"}[$interval]))/sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH|CONNECT"}[$interval]))

API サーバーの書き込みリクエスト成功率。

処理済み読み取りリクエスト数

sum(apiserver_current_inflight_requests{requestKind="readOnly"})

現在処理中の読み取りリクエスト。

処理済みの書き込みリクエスト数

sum(apiserver_current_inflight_requests{requestKind="mutating"})

現在処理中の書き込みリクエスト。

リクエスト制限率

sum(irate(apiserver_dropped_requests_total[$interval]))

API サーバーのスロットリングポリシーによってドロップされたリクエストの合計に対する割合。

概要

ダッシュボードビュー 50

メトリックの詳細

名前

PromQL

説明

GET 読み取りリクエストのレイテンシー

histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="GET",resource!="",subresource!~"log|proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le))

GET リクエストのレスポンスタイム。API サーバーの Pod、リソース、スコープ別に分類されます。

LIST 読み取りリクエストのレイテンシー

histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le))

LIST リクエストのレスポンスタイム。API サーバーの Pod、リソース、スコープ別に分類されます。

書き込みリクエストのレイテンシー

histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET|WATCH|LIST|CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le))

Mutating リクエストのレスポンスタイム。API サーバーの Pod、Verb (GET、WATCH、LIST、CONNECT を除く)、リソース、スコープ別に分類されます。

処理済みの読み取りリクエスト数

apiserver_current_inflight_requests{request_kind="readOnly"}

API サーバーが現在処理中の読み取りリクエスト。

処理済みの書き込みリクエスト数

apiserver_current_inflight_requests{request_kind="mutating"}

API サーバーが現在処理中の書き込みリクエスト。

リクエスト制限レート

sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name)

sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name)

API サーバーのリクエスト制限率。No data または 0 はスロットリングがないことを示します。

リソース分析

ダッシュボードビュー

image

メトリックの詳細

名前

PromQL

説明

メモリ使用量

memory_utilization_byte{container="kube-apiserver"}

API サーバーのメモリ使用量。単位:バイト。

CPU 使用量

cpu_utilization_core{container="kube-apiserver"}*1000

API サーバーの CPU 使用量。単位:ミリコア。

リソースオブジェクト数

  • max by(resource)(apiserver_storage_objects)

  • max by(resource)(etcd_object_counts)

  • v1.22 以降を実行している ACK クラスターの場合、メトリック名は apiserver_storage_objects です。

  • v1.22 以前を実行している ACK クラスターの場合、メトリック名は etcd_object_counts です。

互換性の問題により、バージョン 1.22 には apiserver_storage_objects と etcd_object_counts の両方が存在します。

メモリ使用率レベル

  • resource_utilization_level{resource="memory",container="kube-apiserver",utilization_level="high"}

  • resource_utilization_level{resource="memory",container="kube-apiserver",utilization_level="normal"}

  • resource_utilization_level{utilization_level="high",...} が 1 の場合、コンテナのリソース使用率は ≥ 80% です。

  • resource_utilization_level{utilization_level="normal",...} が 1 の場合、コンテナのリソース使用率は < 80% です。

CPU 使用率レベル

  • resource_utilization_level{resource="cpu",container="kube-apiserver",utilization_level="high"}

  • resource_utilization_level{resource="cpu",container="kube-apiserver",utilization_level="normal"}

QPS とレイテンシー

ダッシュボードビュー 48

メトリックの詳細

名前

PromQL

説明

Verb 別の QPS 分析

sum(irate(apiserver_request_total{verb=~"$verb"}[$interval]))by(verb)

Verb 別に分類されたリクエスト QPS。

Verb とリソース別の QPS 分析

sum(irate(apiserver_request_total{verb=~"$verb",resource=~"$resource"}[$interval]))by(verb,resource)

Verb とリソース別に分類されたリクエスト QPS。

Verb 別のリクエストレイテンシー分析

histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT",resource!=""}[$interval])) by (le,verb))

Verb 別に分類されたリクエストレイテンシー。

Verb とリソース別のリクエストレイテンシー分析

histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT", resource=~"$resource",resource!=""}[$interval])) by (le,verb,resource))

Verb とリソース別に分類されたリクエストレイテンシー。

2xx 以外のレスポンスを持つ読み取りリクエストの QPS

sum(irate(apiserver_request_total{verb=~"GET|LIST",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code)

4xx や 5xx などの 2xx 以外のステータスコードを返した読み取りリクエストの QPS。

2xx 以外のレスポンスを持つ書き込みリクエストの QPS

sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH",verb=~"$verb",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code)

4xx や 5xx などの 2xx 以外のステータスコードを返した書き込みリクエストの QPS。

API サーバーから etcd へのリクエストレイテンシー

histogram_quantile($quantile, sum(irate(etcd_request_duration_seconds_bucket[$interval])) by (le,operation,type,instance))

API サーバーから etcd へのリクエストのレイテンシー。

APF スロットリング

説明

APF スロットリングメトリックの監視はカナリアリリースです。

  • APF 関連のメトリックは、Kubernetes 1.20 以降を実行している ACK クラスターでのみ利用可能です。クラスターをアップグレードするには、「ACK クラスターを手動でアップグレードする」をご参照ください。

  • APF メトリックダッシュボードには、以下のアドオンのアップグレードも必要です:

    • コンテナクラスター監視アドオン:0.06 以降。

    • ack-arms-prometheus アドオン:v1.1.31 以降。

    • マネージドプローブアドオン:v1.1.31 以降。

    これらのアドオンをアップグレードするには、「監視コンポーネントのアップグレード」をご参照ください。

ダッシュボードビュー

image

image

メトリックの詳細

次の表の一部のメトリックは、PL、Instance、FS 別に分類されます。

  • PL:優先度レベルディメンション。メトリックを優先度レベル別に分類します。

  • Instance:API サーバーインスタンス。

  • FS:フロー スキーマディメンション。メトリックをリクエスト分類別に分類します。

APF とディメンションの詳細については、Kubernetes のドキュメント「API Priority and Fairness」をご参照ください。

名前

PromQL

説明

APF リクエスト同時実行数制限 (PL 別)

sum by(priority_level) (apiserver_flowcontrol_request_concurrency_limit)

PL または Instance + PL 別に分類された APF リクエスト同時実行数制限。優先度付きキューごとの理論上の最大同時実行リクエスト数を表します。

apiserver_flowcontrol_request_concurrency_limit は Kubernetes 1.30 で非推奨となり、1.31 で削除されました。v1.31 以降を実行しているクラスターでは、代わりに apiserver_flowcontrol_nominal_limit_seats を使用してください。

APF リクエスト同時実行数制限 (Instance + PL 別)

sum by(instance,priority_level) (apiserver_flowcontrol_request_concurrency_limit)

現在の APF 実行中リクエスト数 (FS + PL 別)

sum by(flow_schema,priority_level) (apiserver_flowcontrol_current_executing_requests)

APF 下で現在実行中のリクエスト。FS + PL または Instance + FS + PL 別に分類されます。

現在の APF 実行中リクエスト数 (Instance + FS + PL 別)

sum by(instance,flow_schema,priority_level)(apiserver_flowcontrol_current_executing_requests)

現在の APF キュー内リクエスト数 (FS + PL 別)

sum by(flow_schema,priority_level) (apiserver_flowcontrol_current_inqueue_requests)

キューで待機中のリクエスト。FS + PL または Instance + FS + PL 別に分類されます。

現在の APF キュー内リクエスト数 (Instance + FS + PL 別)

sum by(instance,flow_schema,priority_level) (apiserver_flowcontrol_current_inqueue_requests)

APF 公称制限シート

sum by(instance,priority_level) (apiserver_flowcontrol_nominal_limit_seats)

Instance + PL 別の APF シートメトリック:

  • 名目上の制限シート数:優先度付きキューごとの名目上の最大同時実行シート数。

  • 現在の制限シート数:優先度付きキューごとの動的調整後の最大同時実行シート数。

  • 実行中シート数:優先度付きキューごとに現在実行中のリクエストによって消費されるシート数。

  • キュー内シート数:優先度付きキューごとに待機中のリクエストによって消費されるシート数。

APF 現在の制限シート数

sum by(instance,priority_level) (apiserver_flowcontrol_current_limit_seats)

APF 現在の実行中シート数

sum by(instance,priority_level) (apiserver_flowcontrol_current_executing_seats)

APF 現在のキュー内シート数

sum by(instance,priority_level) (apiserver_flowcontrol_current_inqueue_seats)

APF リクエスト実行時間

histogram_quantile($quantile, sum(irate(apiserver_flowcontrol_request_execution_seconds_bucket[$interval])) by (le,instance, flow_schema,priority_level))

リクエスト実行開始から完了までの時間。

APF リクエスト待機時間

histogram_quantile($quantile, sum(irate(apiserver_flowcontrol_request_wait_duration_seconds_bucket[$interval])) by (le,instance, flow_schema,priority_level))

リクエストが実行前にキューで待機する時間。

正常にディスパッチされた APF リクエストの QPS

sum(irate(apiserver_flowcontrol_dispatched_requests_total[$interval]))by(instance,flow_schema,priority_level)

正常にディスパッチされたリクエストの QPS。

拒否された APF リクエストの QPS

sum(irate(apiserver_flowcontrol_rejected_requests_total[$interval]))by(instance,flow_schema,priority_level)

同時実行数制限またはキューキャパシティを超えたために拒否されたリクエストの QPS。

アドミッションコントローラーと Webhook

ダッシュボードビュー 47

メトリックの詳細

名前

PromQL

説明

アドミッションコントローラーのレイテンシー [admit]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="admit"}[$interval])) )

admit タイプのアドミッションコントローラーの名前、操作、拒否ステータス、および実行時間。

ヒストグラムバケット:{0.005, 0.025, 0.1, 0.5, 2.5}。単位:秒。

アドミッションコントローラーのレイテンシー [validate]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="validate"}[$interval])) )

validate タイプのアドミッションコントローラーの名前、操作、拒否ステータス、および実行時間。

ヒストグラムバケット:{0.005, 0.025, 0.1, 0.5, 2.5}。単位:秒。

アドミッション Webhook のレイテンシー [admit]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="admit"}[$interval])) )

admit タイプの Webhook の名前、操作、拒否ステータス、および実行時間。

ヒストグラムバケット:{0.005, 0.025, 0.1, 0.5, 2.5}。単位:秒。

アドミッション Webhook のレイテンシー [validating]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="validating"}[$interval])) )

validating タイプの Webhook の名前、操作、拒否ステータス、および実行時間。

ヒストグラムバケット:{0.005, 0.025, 0.1, 0.5, 2.5}。単位:秒。

アドミッション Webhook のリクエスト QPS

sum(irate(apiserver_admission_webhook_admission_duration_seconds_count[$interval]))by(name,operation,type,rejected)

アドミッション Webhook のリクエスト QPS。

クライアント分析

ダッシュボードビュー 45

メトリックの詳細

名前

PromQL

説明

クライアント別の QPS 分析

sum(irate(apiserver_request_total{client!=""}[$interval])) by (client)

クライアント別の QPS。API サーバーにアクセスしているクライアントを示します。

Verb、リソース、クライアント別の QPS 分析

sum(irate(apiserver_request_total{client!="",verb=~"$verb", resource=~"$resource"}[$interval]))by(verb,resource,client)

API サーバーリクエストの QPS。Verb、リソース、クライアント別に分類されます。

resourceVersion のない LIST リクエストの QPS

sum(irate(apiserver_request_no_resourceversion_list_total[$interval]))by(resource,client)

  • resourceVersion フィールドを含まない LIST リクエストの QPS。リソースとクライアント別に分類されます。

  • etcd に到達する API サーバーへの LIST リクエストの割合を分析します。このメトリックを使用して、クライアントの LIST 動作を特定し、最適化します。

一般的なメトリックの異常

以下のセクションを使用して、メトリックの異常が想定内のものであるかどうかを判断します。

読み取り/書き込みリクエスト成功率

説明

正常

異常

説明

[読み取りリクエスト成功率] と [書き込みリクエスト成功率] は 100% に近い値であるべきです。

[読み取りリクエスト成功率] と [書き込みリクエスト成功率] が低いパーセンテージ、例えば 90% 未満で推移します。

多くのリクエストが 2xx 以外のステータスコードを返します。

推奨ソリューション

[2xx 以外のレスポンスを持つ読み取りリクエストの QPS] および [2xx 以外のレスポンスを持つ書き込みリクエストの QPS] パネルを確認して、2xx 以外のレスポンスを引き起こしているリクエストタイプとリソースを特定します。例えば、[GET/deployment 404] は、GET Deployment リクエストが 404 を返し、[読み取りリクエスト成功率] を低下させていることを意味します。この動作が想定内のものであるかどうかを判断し、リクエストを最適化するための対策を講じます。

GET/LIST 読み取りおよび書き込みリクエストのレイテンシー

説明

正常

異常

説明

[GET 読み取りリクエストのレイテンシー]、[LIST 読み取りリクエストのレイテンシー]、および [書き込みリクエストのレイテンシー] は、クラスターのサイズとアクセスされるリソースの数と相関します。固定のしきい値はなく、アプリケーションに影響を与えない限り、レイテンシーは許容範囲内です。例えば、クライアントがアクセスするリソースのボリュームが大きいほど、LIST リクエストにかかる時間は長くなります。通常、[GET 読み取りリクエストのレイテンシー] と [書き込みリクエストのレイテンシー] が 1 秒未満、[LIST 読み取りリクエストのレイテンシー] が 5 秒未満であれば正常です。

  • [GET 読み取りリクエストのレイテンシー] または [書き込みリクエストのレイテンシー] が 1 秒を超えます。

  • [LIST 読み取りリクエストのレイテンシー] が 5 秒を超えます。

リクエストのレイテンシーが高い場合は、多数のクラスターリソースや遅い Webhook 呼び出しなどの要因が寄与しているかどうかを確認します。

推奨ソリューション

  • ダッシュボードを確認して、レイテンシーの高いリクエストタイプとリソースを特定します。[GET 読み取りリクエストのレイテンシー]、[LIST 読み取りリクエストのレイテンシー]、および [書き込みリクエストのレイテンシー] のメトリックを確認し、修正措置を講じます。

    apiserver_request_duration_seconds_bucket メトリックの上限は 60 秒です。60 秒を超えるリクエストは 60 秒として記録されます。POST pod/exec やログの読み取りなどの永続的な接続リクエストは、通常このしきい値を超え、トラブルシューティング時には無視できます。

処理中の読み取り/書き込みリクエストとリクエスト制限率

説明

正常

異常

説明

通常、[処理中の読み取りリクエスト数] と [処理中の書き込みリクエスト数] は 100 未満で、[リクエスト制限率] は 0 です。

  • [読み取りリクエストの処理数] または [書き込みリクエストの処理数] が 100 を超えています。

  • [リクエスト制限率] が 0 より大きいです。

リクエストキューにバックログがある場合は、急なリクエストの急増や遅い Webhook などの要因を除外します。キューのキャパシティを超えると、API サーバーはリクエストをスロットリングし、[リクエスト制限率] が 0 を超え、クラスターの安定性に影響を与えます。

推奨ソリューション

  • QPS とレイテンシーダッシュボードおよびクライアント分析ダッシュボードを確認して、ボリューム別のトップリクエストを特定し、それらが想定内のものであるかを評価します。リクエストがご利用のアプリケーションからのものである場合は、そのボリュームを削減できるかどうかを判断します。

  • アドミッション Webhook のレイテンシーを確認して、遅い Webhook が API サーバーのリクエスト処理を遅くしていないかを判断します。

アドミッション Webhook のレイテンシー

説明

正常

異常

説明

[アドミッション Webhook のレイテンシー] は 0.5 秒未満であるべきです。

[アドミッション Webhook のレイテンシー] が持続的に 0.5 秒を超えます。

遅い Webhook のレスポンスは、API サーバーのレスポンスレイテンシーに影響を与えます。

推奨ソリューション

Webhook のログを確認して、その動作が想定内のものであるかどうかを判断します。不要になった Webhook はアンインストールしてください。

参考