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

Container Service for Kubernetes:kube-apiserver コンポーネントのメトリックとダッシュボード

最終更新日:Nov 09, 2025

kube-apiserver コンポーネントは、Kubernetes の RESTful API を提供します。この API により、外部クライアントやクラスター内の他のコンポーネントが ACK クラスターと対話できます。このトピックでは、kube-apiserver コンポーネントのメトリック、ダッシュボードの使用方法に関するガイダンス、および一般的なメトリックの異常について説明します。

始める前に

アクセス方法

詳細については、「コントロールプレーンコンポーネントをモニタリングするためのダッシュボードの表示」をご参照ください。

メトリックのリスト

メトリックは、コンポーネントのステータスとパラメーターを公開するために使用されます。次の表は、kube-apiserver コンポーネントのメトリックを説明しています。

メトリック

タイプ

説明

apiserver_request_duration_seconds_bucket

ヒストグラム

このメトリックは、API Server クライアントから API Server へのさまざまなリクエストのアクセスレイテンシー分布を追跡するために使用されます。

リクエストのディメンションには、以下が含まれます。

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

  • Group: API グループ。API グループは、Kubernetes API を拡張するために使用される関連 API 操作のコレクションです。

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

  • Resource: pod、service、lease などのリクエストのリソースタイプ。

  • Subresource: pod の詳細や pod のログなど、リソースのサブリソース。

  • Scope: 名前空間スコープのリソースやクラスター-スコープのリソースなど、リクエストのスコープ。

  • Component: kube-controller-managerkube-schedulercloud-controller-manager など、リクエストを開始するコンポーネントの名前。

  • Client: リクエストを開始するクライアント。クライアントは、内部コンポーネントまたは外部サービスの場合があります。

API Server ヒストグラムのバケットのしきい値は {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 Server へのさまざまなリクエストのカウンター。リクエストのディメンションには、Verb、Group、Version、Resource、Scope、Component、HTTP contentType、HTTP code (応答の HTTP ステータスコード)、および Client が含まれます。

apiserver_request_no_resourceversion_list_total

カウンター

resourceVersion パラメーターが設定されていない API Server への LIST リクエストのカウンター。Quorum Read タイプの LIST リクエストを評価することで、このタイプの過剰なリクエストとそれを開始したクライアントを特定できます。これにより、クライアントのリクエスト動作を最適化し、クラスターのパフォーマンスを向上させることができます。リクエストのディメンションには、Group、Version、Resource、Scope、および Client が含まれます。

apiserver_current_inflight_requests

ゲージ

API Server が現在処理しているリクエストの数。リクエストには次の 2 つのタイプがあります。

  • ReadOnly: これらのリクエストはクラスターの状態を変更しません。通常、Pod のリストの取得やノードのステータスのクエリなどの読み取り操作です。

  • Mutating: これらのリクエストはクラスターの状態を変更します。通常、Pod の作成やサービス構成の更新など、リソースを作成、更新、または削除する操作です。

apiserver_dropped_requests_total

カウンター

スロットリング中に API Server が積極的にドロップするリクエストの数。HTTP の戻り値は 429 'Try again later' です。

etcd_request_duration_seconds_bucket

ヒストグラム

このメトリックは、API Server から etcd へのリクエストのレイテンシー分布をカウントします。

リクエストのディメンションには、Operation と Type (操作オブジェクトのタイプ) が含まれます。

バケットのしきい値は {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_flowcontrol_request_concurrency_limit

ゲージ

API 優先度と公平性 (APF) リクエストの同時実行数制限。これは、優先度付きキューの最大同時実行数制限を示します。これは、キューが理論的に同時に処理できるリクエストの最大数です。これにより、API Server がスロットリングポリシーを使用して、異なる優先度のキューにリソースを割り当て、高優先度のリクエストが迅速に処理されるようにする方法を理解するのに役立ちます。

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

apiserver_flowcontrol_current_executing_requests

ゲージ

優先度付きキューで現在実行されているリクエストの数。これは、キューの実際の同時ペイロードを示します。これにより、API Server の実際のペイロードを理解し、システムが最大同時実行数制限に近づいているかどうかを判断して、過負荷を防ぐのに役立ちます。

apiserver_flowcontrol_current_inqueue_requests

ゲージ

優先度付きキューで処理を待っているリクエストの数。これは、キューのリクエストバックログを示します。これにより、API Server のトラフィックプレッシャーと、キューが過負荷になっているかどうかを理解するのに役立ちます。

apiserver_flowcontrol_nominal_limit_seats

ゲージ

APF の公称同時実行数制限シートの数。これは、シート単位で測定された API Server の理論的な (公称) 最大同時処理能力です。これにより、API Server がスロットリングポリシーを使用して、異なる優先度のキューにリソースを割り当てる方法を理解するのに役立ちます。

apiserver_flowcontrol_current_limit_seats

ゲージ

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

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

apiserver_flowcontrol_current_executing_seats

ゲージ

APF のために現在実行されているシートの数。これは、優先度付きキューで現在実行されているリクエストに対応するシートの数を示します。これは、キューで消費されている同時リソースを反映しています。これにより、キューの実際の負荷を理解するのに役立ちます。

current_executing_seats が current_limit_seats に近い場合、キューの同時リソースが枯渇寸前である可能性があります。

API Server の maxMutatingRequestsInflight および maxRequestsInflight パラメーターの値を増やすことで、構成を最適化できます。構成ページへのアクセス方法とパラメーター値については、「Pro マネージドクラスターのコントロールプレーンコンポーネントのパラメーターをカスタマイズする」をご参照ください。

apiserver_flowcontrol_current_inqueue_seats

ゲージ

APF のために現在キューに入っているシートの数。これは、優先度付きキューで処理を待っているリクエストに対応するシートの数を示します。これは、キューで処理を待っているリクエストによって占有されているリソースを反映しています。これにより、キューのバックログを理解するのに役立ちます。

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

カウンター

正常にスケジュールされ、処理されたリクエストの数。これは、API Server によって正常に処理されたリクエストの総数を反映しています。

apiserver_flowcontrol_rejected_requests_total

カウンター

同時実行数制限またはキュー容量を超えたために拒否されたリクエストの数。

apiserver_admission_controller_admission_duration_seconds_bucket

ヒストグラム

アドミッションコントローラーの処理レイテンシー。ラベルには、アドミッションコントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (validate または admit)、およびリクエストが拒否されたかどうか (true または false) が含まれます。

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

apiserver_admission_webhook_admission_duration_seconds_bucket

ヒストグラム

アドミッション Webhook の処理レイテンシー。ラベルには、アドミッションコントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (validate、リクエストの有効性をチェックするため、または admit、有効な場合にリクエストを許可するかどうかを決定するため)、およびリクエストが拒否されたかどうか (true または false) が含まれます。

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

apiserver_admission_webhook_admission_duration_seconds_count

カウンター

アドミッション Webhook によって処理されたリクエストのカウンター。ラベルには、アドミッションコントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (validate または admit)、およびリクエストが拒否されたかどうか (true または false) が含まれます。

cpu_utilization_core

ゲージ

CPU 使用率。単位: コア。

memory_utilization_byte

ゲージ

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

up

ゲージ

サービスの可用性。

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

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

説明

ダッシュボード使用ガイド

ダッシュボードは、コンポーネントのメトリックと関連する Prometheus Query Language (PromQL) クエリを使用して構築されています。これには、主要メトリック、概要、リソース分析、QPS とレイテンシー、APF スロットリング、アドミッションコントローラーと Webhook、およびクライアント分析のセクションが含まれます。

次の手順は、一般的なワークフローを説明しています。

  1. 主要メトリック: クラスターの主要メトリックをすばやく表示します。

  2. 概要: API Server の応答時間、処理中のリクエスト数、およびスロットリングが発生したかどうかを分析します。

  3. リソース分析: マネージドコンポーネントのリソース使用量を表示します。

  4. QPS とレイテンシー: 複数のディメンションから QPS と応答時間 (RT) を詳細に分析します。

  5. APF スロットリング: APF メトリックを使用して、API Server のリクエストトラフィック分布とスロットリングステータスを分析し、システムのパフォーマンスボトルネックを特定できます。

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

  7. クライアント分析: 複数のクライアントディメンションから QPS を分析します。

[フィルターペイン]

ダッシュボードの上部にあるフィルターペインで、Verb、Resource、Quantile、および Interval (PromQL サンプリング期間) パラメーターを設定して、API Server リクエストをフィルターできます。

説明

Quantile を調整すると、値 0.9 は、ダッシュボードがヒストグラムメトリックの 90 パーセンタイルの値を表示することを示します。分位数 0.9 (P90) は、総サンプルのごく一部を占めるロングテールサンプルの影響を除去できます。分位数 0.99 (P99) は、ロングテールサンプルの影響を含みます。

筛选框

次のフィルターペインで、時間範囲とページの更新間隔を選択できます。筛选框2

[主要メトリック]

可観測性表示100

機能分析

名前

PromQL

説明

API QPS

sum(irate(apiserver_request_total[$interval]))

API Server の合計 QPS。

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

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

API Server が読み取りリクエストを処理する際の成功率。

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

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 Server が書き込みリクエストを処理する際の成功率。

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

sum(apiserver_current_inflight_requests{requestKind="readOnly"})

API Server が現在処理している読み取りリクエストの数。

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

sum(apiserver_current_inflight_requests{requestKind="mutating"})

API Server が現在処理している書き込みリクエストの数。

リクエストスロットリング率

sum(irate(apiserver_dropped_requests_total[$interval]))

ドロップされたリクエスト率。

スロットリング中に API Server によって積極的にドロップされたリクエストの総リクエスト数に対する比率。

[概要]

可観測性表示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 Server Pod、Verb (GET)、Resources、および Scope が含まれます。

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

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

LIST リクエストの応答時間を表示します。ディメンションには、API Server Pod、Verb (LIST)、Resources、および Scope が含まれます。

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

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

変更リクエストの応答時間を表示します。ディメンションには、API Server Pod、Verb (GET、WATCH、LIST、CONNECT を除く)、Resources、および Scope が含まれます。

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

apiserver_current_inflight_requests{request_kind="readOnly"}

API Server が処理している読み取りリクエストの数。

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

apiserver_current_inflight_requests{request_kind="mutating"}

API Server が処理している書き込みリクエストの数。

リクエストスロットリング率

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 Server のスロットリング率。No data または 0 は、スロットリングが発生していないことを示します。

[リソース分析]

可観測性表示资源对象

機能分析

名前

PromQL

説明

メモリ使用量

memory_utilization_byte{container="kube-apiserver"}

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

CPU 使用率

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

API Server の CPU 使用率。単位: ミリコア。

リソースオブジェクト数

  • max by(resource)(apiserver_storage_objects)

  • max by(resource)(etcd_object_counts)

  • ACK バージョンが 1.22 以降の場合、メトリック名は apiserver_storage_objects です。

  • ACK バージョンが 1.22 より前の場合、メトリック名は etcd_object_counts です。

説明

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

[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 と Resource 別にリクエストの 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 と Resource 別にリクエストレイテンシーを分析します。

2xx 以外の戻り値を持つ読み取りリクエストの QPS

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

2xx 以外の戻り値を持つ読み取りリクエストの QPS をカウントします。2xx 以外の戻り値は、4xx や 5xx などの失敗を示します。

2xx 以外の戻り値を持つ書き込みリクエストの QPS

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

2xx 以外の戻り値を持つ書き込みリクエストの QPS をカウントします。2xx 以外の戻り値は、4xx や 5xx などの失敗を示します。

API Server から Etcd へのリクエストレイテンシー

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

API Server から etcd へのリクエストレイテンシーをカウントします。

APF スロットリング

説明

APF スロットリングメトリックのモニタリングは段階的リリースです。

可観測性表示

image

image

機能分析

次の表の一部のメトリックは、PL、Instance、および FS ディメンションによって収集されます。

  • PL: 優先度レベルディメンション。メトリックは、さまざまな優先度に基づいて収集されます。

  • Instance: API Server インスタンスディメンション。メトリックは、API Server インスタンスに基づいて収集されます。

  • FS: フロー スキーマディメンション。メトリックは、リクエストの分類に基づいて収集されます。

APF と前述のディメンションの詳細については、APF ドキュメントをご参照ください。

名前

PromQL

説明

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

sum by(priority_level) (apiserver_flowcontrol_request_concurrency_limit)

PL 別または Instance と PL 別に APF リクエストの同時実行数制限をカウントします。これは、優先度付きキューが理論的に同時に処理できるリクエストの最大数です。

apiserver_flowcontrol_request_concurrency_limit メトリックは Kubernetes v1.30 で非推奨となり、v1.31 で削除されますKubernetes 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)

FS と PL 別、または Instance、FS、PL 別に現在実行中の APF リクエストの数をカウントします。

現在の 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_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 Server にアクセスするクライアントとその QPS を分析するために使用されます。

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

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

Verb、Resource、Client 別に QPS を分析します。

Verb、リソース、クライアント別の LIST リクエスト QPS 分析 (ResourceVersion フィールドなし)

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

  • resourceVersion フィールドなしで、Verb、Resource、Client 別に LIST リクエストの QPS を分析します。

  • API Server へのすべての LIST リクエストの中から、etcd への一部の LIST リクエストを分析できます。これは、API Server クライアントの LIST 動作を特定し、最適化するのに役立ちます。

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

コンポーネントの一般的なメトリックが異常な場合は、次の説明を参照して、その動作が予期されたものかどうかを判断してください。

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

説明

法線

異常

説明

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

[読み取りリクエスト成功率][書き込みリクエスト成功率] は、たとえば 90% 未満など、低いパーセンテージのままです。

200 以外の戻り値を持つリクエストが多数あります。

推奨される解決策

ダッシュボードを使用して、[2xx 以外の戻り値を持つ読み取りリクエストの QPS] および [2xx 以外の戻り値を持つ書き込みリクエストの QPS] チャートで 2xx 以外の戻り値の原因となるリクエストタイプとリソースを特定します。これらのリクエストが予期されたものであるかどうかを評価し、それらを最適化するための措置を講じます。たとえば、[GET/deployment 404] が表示された場合、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 秒としてカウントされます。ただし、Pod へのログインリクエスト (POST pod/exec) やログ読み取りリクエストは長期間の接続を確立します。これらのリクエストは通常 60 秒以上かかります。トラブルシューティング中にこれらのタイプのリクエストは無視できます。

[処理中の読み取り/書き込みリクエストとリクエストスロットリング率]

説明

法線

異常

説明

一般的に、[処理中の読み取りリクエスト数][処理中の書き込みリクエスト数] が 100 未満で、[リクエストスロットリング率] が 0 であれば正常です。

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

  • [リクエストスロットリング率] は 0 より大きいです。

リクエストを処理するキューにバックログがある場合、リクエストの急増や遅い Webhook 呼び出しによる処理遅延などの要因を除外する必要があります。キューの長さを超えると、API Server はリクエストをスロットリングします。これにより、[リクエストスロットリング率] が 0 より大きくなり、クラスターの安定性に影響します。

推奨される解決策

  • QPS とレイテンシー および クライアント分析 セクションを参照して、上位のリクエストを分析し、それらが予期されたものであるかどうかを評価します。リクエストがアプリケーションによって開始された場合は、リクエスト数を減らす必要があるかどうかを判断します。

  • アドミッション Webhook レイテンシー を参照して、遅い Webhook 実行が API Server リクエスト処理を遅くしているかどうかを分析します。

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

説明

法線

異常

説明

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

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

遅い Webhook 応答は、API Server の応答時間に影響します。

推奨される解決策

Webhook のログやその他の情報を確認して、その動作が予期されたものかどうかを判断します。Webhook が不要な場合は、アンインストールしてください。

参考資料