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

Container Service for Kubernetes:kube-apiserverのモニタリング指標とダッシュボード

最終更新日:Nov 14, 2024

kube-apiserverコンポーネントは、KubernetesのRESTful APIを提供し、Container Service for Kubernetes (ACK) クラスター内の外部クライアントやその他のコンポーネントがACKクラスターと対話できるようにします。 このトピックでは、kube-apiserverコンポーネントのモニタリングメトリックについて説明します。 このトピックでは、モニタリングダッシュボードの使用方法とメトリック異常の処理方法についても説明します。

使用上の注意

アクセス方法

詳細については、「ACK Proクラスターでの制御プレーンコンポーネントダッシュボードの表示」をご参照ください。

メトリクス

メトリックは、コンポーネントのステータスおよびパラメータ設定を示すことができる。 次の表に、kube-apiserverでサポートされているメトリックを示します。

メトリック

タイプ

説明

apiserver_request_duration_seconds_bucket

ヒストグラム

kube-apiserverに送信されたリクエストと、kube-apiserverによって返されたレスポンスとの間のレイテンシ。

リクエストは、次のディメンションに基づいて分類されます。

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

  • Group: Kubernetes APIの拡張に使用される関連API操作を含むAPIグループ。

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

  • リソース: ポッド、サービス、リースなど、リクエストがアクセスするために送信されるリソースのタイプ。

  • サブリソース: ポッドの詳細やポッドログなど、リソースのサブリソース。

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

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

  • クライアント: 内部コンポーネントまたは外部サービスである可能性がある、要求を送信するクライアント。

のヒストグラムのバケットkube-schedulerを含む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

Counter

kube-apiserverが受信したさまざまなリクエストの数。 リクエストは、動詞、グループ、バージョン、リソース、スコープ、コンポーネント、HTTPコンテンツタイプ、HTTPステータスコード、およびクライアントに基づいて分類されます。

apiserver_request_no_resourceversion_list_total

Counter

kube-apiserverに送信され、resourceVersionパラメーターが指定されていないLISTリクエストの数。 このメトリックは、過剰な数のクォーラム読み取りタイプのLIST要求がkube-apiserverに送信されているかどうかを確認し、そのような要求を送信するクライアントを特定するために使用されます。 これにより、クライアントの動作を最適化し、クラスターのパフォーマンスを向上できます。 リクエストは、グループ、バージョン、リソース、スコープ、およびクライアントに基づいて分類されます。

apiserver_current_inflight_requests

ゲージ

kube-apiserverによって処理されているリクエストの数。 リクエストは次のタイプに分類されます。

  • ReadOnly: このタイプのリクエストでは、クラスターのステータスは変更されません。 ほとんどの場合、このタイプのリクエストは、クエリポッドやクエリノードステータスなど、クラスター内の読み取りリソースに送信されます。

  • 変更: このタイプのリクエストは、クラスターのステータスを変更します。 ほとんどの場合、このタイプの要求は、ポッドの作成やサービスの構成の更新など、リソースの作成、更新、または削除のために送信されます。

apiserver_dropped_requests_total

Counter

kube-apiserverでスロットリングが実行されたときにドロップされるリクエストの数。 429 'Try again later' のHTTPステータスコードが返された場合、リクエストはドロップされます。

etcd_request_duration_seconds_bucket

ヒストグラム

kube-apiserverから送信されたリクエストと、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_admission_controller_admission_duration_seconds_bucket

ゲージ

アドミッションコントローラの処理レイテンシ。 ヒストグラムは、承認コントローラ名、CREATE、UPDATE、またはCONNECTなどの操作、APIリソース、検証または承認などの操作タイプ、および要求が拒否されるかどうかによって識別されます。

ヒストグラムのバケットは、0.005、0.025、0.1、0.5、および2.5を含む。 単位は秒です。

apiserver_admission_webhook_admission_duration_seconds_bucket

ゲージ

承認webhookの処理レイテンシ。 ヒストグラムは、承認コントローラ名、CREATE、UPDATE、またはCONNECTなどの操作、APIリソース、検証または承認などの操作タイプ、および要求が拒否されるかどうかによって識別されます。

ヒストグラムのバケットは、0.005、0.025、0.1、0.5、および2.5を含む。 単位は秒です。

apiserver_admission_webhook_admission_duration_seconds_count

Counter

承認webhookによって処理されたリクエストの数。 ヒストグラムは、承認コントローラ名、CREATE、UPDATE、またはCONNECTなどの操作、APIリソース、検証または承認などの操作タイプ、および要求が拒否されるかどうかによって識別されます。

cpu_utilization_core

ゲージ

使用されるCPUコアの数。 単位: コア。

memory_utilization_byte

ゲージ

使用されたメモリの量。 単位はバイトです。

アップ

ゲージ

kube-apiserverが使用可能かどうかを示します。

  • 1: kube-apiserverは利用できます。

  • 0: kube-apiserverは利用できません。

説明

次のリソース使用率メトリックは非推奨です。 これらのメトリックに依存するアラートとモニタリングデータをできるだけ早く削除します。

  • cpu_utilization_ratio: CPU使用率。

  • memory_utilization_ratio: メモリ使用率。

ダッシュボードの使用状況ノート

ダッシュボードは、メトリクスとPrometheus Query Language (PromQL) に基づいて生成されます。 次のセクションでは、主要なメトリクス、クラスターレベルの概要、リソース分析、1秒あたりのクエリ数 (QPS) とレイテンシ、アドミッションコントローラーとwebhook、およびクライアント分析のためのkube-apiserverダッシュボードについて説明します。

ほとんどの場合、これらのダッシュボードは次の順序で使用されます。

  1. 主要なメトリクスダッシュボードを表示して、クラスターのパフォーマンス統計をすばやく表示します。

  2. クラスターレベルの概要ダッシュボードを表示して、kube-apiserverのレスポンスレイテンシ、kube-apiserverによって処理されているリクエストの数、およびリクエストスロットリングがトリガーされているかどうかを分析します。

  3. リソース分析ダッシュボードを表示して、管理対象コンポーネントのリソース使用状況を確認します。

  4. QPSとレイテンシのダッシュボードを表示して、複数のディメンションに基づいてQPSと応答時間を分析します。

  5. アドミッションコントローラーとwebhookのダッシュボードを表示して、アドミッションコントローラーとwebhookのQPSと応答時間を分析します。

  6. クライアント分析ダッシュボードを表示して、複数のディメンションに基づいてクライアントQPSを分析します。

フィルター

ダッシュボードの上に複数のフィルターが表示されます。 次のフィルターを使用して、動詞とリソースに基づいてkube-apiserverに送信されたリクエストをフィルター処理し、分位数を変更し、PromQLサンプリング間隔を変更できます。

説明

分位数を変更するには、分位数フィルターを使用します。 たとえば、0.9を選択した場合、メトリックのサンプル値の90% がヒストグラムのサンプル値として使用されます。 0.9 (P90) の値は、総サンプル値のほんの一部であるロングテールサンプルの影響を排除するのに役立ちます。 0.99の値 (P99) は、ロングテールサンプルを含む。

筛选框

次のフィルターを使用して、時間範囲と更新間隔を指定します。筛选框2

主要な指標

可视性 100

機能

メトリック

PromQL

説明

API QPS

sum(irate(apiserver_request_total[$interval]))

kube-apiserverのQPS。

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

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

kube-apiserverに送信された読み取り要求の成功率。

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

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

kube-apiserverに送信された書き込み要求の成功率。

処理された読み取り要求の数

sum(apiserver_current_inflight_requests{requestKind="readOnly"})

kube-apiserverによって処理されている読み取り要求の数。

処理された書き込み要求の数

sum(apiserver_current_inflight_requests{requestKind="mutating"})

kube-apiserverによって処理されている書き込み要求の数。

リクエスト制限レート

sum(irate(apiserver_dropped_requests_total[$interval]))

kube-apiserverでリクエストスロットリングが実行されたときに、kube-apiserverに送信されたリクエストの総数に対するドロップされたリクエストの数の比率。

クラスターレベルの概要

可视性 50

機能

メトリック

PromQL

説明

GET読み取りリクエスト遅延P[0.9]

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

APIサーバーポッド、GET動詞、リソース、スコープのディメンションに基づいて表示されるGETリクエストの応答時間。

リスト読み取りリクエスト遅延P[0.9]

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

LISTリクエストの応答時間は、APIサーバーポッド、LIST動詞、リソース、およびスコープのディメンションに基づいて表示されます。

書き込みリクエスト遅延P[0.9]

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サーバーポッド、GET、WATCH、LIST、CONNECTなどの動詞、リソース、およびスコープのディメンションに基づいて表示される変更要求の応答時間。

処理された読み取り要求の数

apiserver_current_inflight_requests{request_kind="readOnly"}

kube-apiserverによって処理されている読み取り要求の数。

処理された書き込み要求の数

apiserver_current_inflight_requests{request_kind="mutating"}

kube-apiserverによって処理されている書き込み要求の数。

リクエスト制限レート

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

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

kube-apiserverのスロットルレート。 No dataまたは0は、リクエストスロットリングがトリガーされないことを示します。

リソース分析

可视性 资源对象

機能

メトリック

PromQL

説明

メモリ使用量

memory_utilization_byte{container="kube-apiserver"}

kube-apiserverのメモリ使用量。 単位はバイトです。

CPU使用率

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

kube-apiserverのCPU使用率。 単位: ミリコア。

リソースオブジェクトの数

  • max by(resource)(apiserver_storage_objects)

  • max by (リソース)(etcd_object_counts)

  • ACKクラスターがKubernetes 1.22以降を実行する場合、メトリック名はapiserver_storage_objectsです。

  • ACKクラスターがKubernetes 1.22以前に実行されている場合、メトリック名はetcd_object_countsです。

説明

互換性の問題により、apiserver_storage_objectsとetcd_object_countsの両方のメトリクスがKubernetes 1.22に存在します。

QPSとレイテンシ

可视性 48

機能

メトリック

PromQL

説明

分析QPS [すべて] P[0.9] by動詞ディメンション

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

動詞に基づいて計算されたQPS。

QPS [すべて] P[0.9] を動詞リソースディメンションで分析

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

動詞とリソースに基づいて計算されたQPS。

リクエストのレイテンシをVerbディメンションで分析する [すべて] P[0.9]

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

動詞に基づいて計算された応答レイテンシ。

リクエスト遅延をVerbで分析リソースディメンション [すべて] P[0.9]

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

動詞とリソースに基づいて計算された応答レイテンシ。

読み取り要求QPS [5m] for non-2xx戻り値

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

2xx以外のHTTPステータスコード (4xxや5xxなど) が返される読み取り要求のQPS。

QPS [5m] for write request with non-2xx return value

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

2xx以外のHTTPステータスコード (4xxや5xxなど) が返される書き込み要求のQPS。

Apiserverからetcdリクエストのレイテンシ [5m]

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

kube-apiserverからetcdに送信されたリクエストのレイテンシ。

入学コントローラーとwebhook

可视性 47

機能

メトリック

PromQL

説明

入学コントローラー遅延 [承認]

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

承認タイプの承認コントローラーの名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。

ヒストグラムのバケットは、0.005、0.025、0.1、0.5、および2.5を含む。 単位は秒です。

入学コントローラーの遅延 [検証]

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

検証タイプのアドミッションコントローラーの名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。

ヒストグラムのバケットは、0.005、0.025、0.1、0.5、および2.5を含む。 単位は秒です。

入場Webhook delay [admit]

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

承認タイプの承認webhookの名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。

ヒストグラムのバケットは、0.005、0.025、0.1、0.5、および2.5を含む。 単位は秒です。

入会Webhookの遅延 [検証]

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

検証タイプの承認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)

入場ウェブフックのQPS。

クライアント分析

可视性 45

機能

メトリック

PromQL

説明

クライアントディメンションによるQPSの分析

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

クライアントに基づくQPS統計。 これは、kube-apiserverとQPSにアクセスするクライアントの分析に役立ちます。

QPSを動詞リソースクライアントディメンションで分析 [すべて]

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

動詞、リソース、およびクライアントに基づくQPS統計。

Verb Resource ClientディメンションによるLISTリクエストQPSの分析 (resourceVersionフィールドなし)

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

  • 動詞、リソース、およびクライアントに基づくLISTリクエストのQPS。 このようなリクエストでは、resourceVersionパラメーターは指定されていません。

  • kube-apiserverに送信されたLISTリクエストと、etcdからデータを取得するLISTリクエストに基づいて、クライアントが実行するLIST操作を分析および最適化できます。

一般的なメトリック異常

kube-apiserverのメトリックが異常になった場合は、以下のセクションで説明するメトリックの異常が存在するかどうかを確認します。 次のセクションで説明されていないメトリック異常が発生した場合、チケットを起票します。

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

ケースの説明

通常

異常

説明

読み取り要求成功率書き込み要求成功率の値は100% に近い。

読み取り要求成功率および書き込み要求成功率の値は小さい。 例えば、値は90% より小さい。

200以外のHTTPステータスコードが返されるリクエストが多数存在します。

推奨ソリューション

kube-apiserverが2xx以外のHTTPステータスコードを返す原因となるリクエストタイプとリソースについては、Read request QPS [5m] for non-2xx return valuesおよびQPS [5m] for write request with non-2xx return valuesをチェックします。 そのようなリクエストが期待を満たすかどうかを評価し、評価結果に基づいてリクエストを最適化します。 たとえば、GET/deployment 404が存在する場合、HTTPステータスコード404が返されるGET Deploymentリクエストが存在します。 これにより、読み取り要求成功率の値が減少します。

GET/LISTリクエストのレイテンシと書き込みリクエストのレイテンシ

ケースの説明

通常

異常

説明

GETリードリクエスト遅延P[0.9]LISTリードリクエスト遅延P[0.9] 、およびライトリクエスト遅延P[0.9] の値は、クラスタ内でアクセスされるリソースの量とクラスタサイズに応じて異なります。 したがって、異常を識別するために特定の閾値を使用することはできない。 ワークロードに悪影響がなければ、すべてのケースが受け入れられます。 たとえば、特定のタイプのリソースにアクセスするために送信されるリクエストの数が増加すると、LISTリクエストのレイテンシが増加します。 ほとんどの場合、GET読み取り要求遅延P[0.9] および書き込み要求レイテンシ遅延P[0.9] の値は1秒より小さく、LIST読み取り要求遅延P[0.9] の値は5秒より大きい。

  • GET読み取り要求遅延P[0.9] および書き込み要求待ち時間遅延P[0.9] の値は1秒より大きい。

  • LIST読み取り要求遅延P[0.9] の値は5秒より大きい。

すぐに応答できない承認webhookまたはリソースにアクセスするクライアントから送信されたリクエストの増加により、応答遅延が増加するかどうかを確認します。

推奨ソリューション

  • kube-apiserverが2xx以外のHTTPステータスコードを返す原因となるリクエストタイプとリソースについては、GET read request delay P[0.9]LIST read request delay P[0.9]Write request latency delay P[0.9] を確認します。 そのようなリクエストが期待を満たすかどうかを評価し、評価結果に基づいてリクエストを最適化します。

    apiserver_request_duration_seconds_ バケットメトリックの上限は60秒です。 60秒より長い応答待ち時間は、60秒に切り捨てられる。 ポッドアクセス要求POST Pod /execおよびログ取得要求は、永続的な接続を作成します。 これらのリクエストのレスポンスレイテンシは60秒以上です。 したがって、リクエストを分析するときにこれらのリクエストを無視できます。

  • kube-apiserverの応答遅延が、すぐに応答できない承認webhookのために増加するかどうかを分析します。 詳細については、このトピックの「Admission webhook latency」セクションをご参照ください。

処理中の読み取りまたは書き込み要求とドロップされた要求の数

ケースの説明

通常

異常

説明

ほとんどの場合、Number of read Request processedまたはNumber of write Request processedの値が100より小さく、Request Limit Rateの値が0であれば、異常は発生しません。

  • [読み取り要求の処理数] および [書き込み要求の処理数] の値が100より大きい。

  • リクエスト制限レートの値は0より大きい。

リクエストキューがいっぱいです。 問題が一時的なリクエストスパイクまたはすぐに応答できない承認webhookによって引き起こされているかどうかを確認します。 保留中のリクエストの数がキューの長さを超える場合、kube-apiserverはリクエストのスロットリングをトリガーし、リクエスト制限率の値は0を超えます。 その結果、クラスタの安定性が影響を受ける。

推奨ソリューション

  • QPSとレイテンシおよびクライアント分析ダッシュボードを表示します。 上位のリクエストが必要かどうかを確認します。 リクエストがワークロードによって生成される場合は、同様のリクエストの数を減らすことができるかどうかを確認します。

  • kube-apiserverの応答遅延が、すぐに応答できない承認webhookのために増加するかどうかを分析します。 詳細については、このトピックのAdmission webhook latencyセクションを参照してください。

  • リクエスト制限レートの値が0より大きい場合、チケットを起票テクニカルサポートのしてください。

Admission webhookレイテンシ

ケースの説明

通常

異常

説明

Admission Webhook Delayの値が0.5秒未満です。

Admission Webhook Delayの値は0.5秒より大きいままです。

承認webhookがすぐに応答できない場合、kube-apiserverの応答レイテンシが増加します。

推奨ソリューション

承認webhookログを分析し、webhookが期待どおりに機能するかどうかを確認します。 webhookが不要になった場合は、アンインストールします。

関連ドキュメント