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によって返されたレスポンスとの間のレイテンシ。 リクエストは、次のディメンションに基づいて分類されます。
のヒストグラムのバケットkube-schedulerを含む |
apiserver_request_total | Counter | kube-apiserverが受信したさまざまなリクエストの数。 リクエストは、動詞、グループ、バージョン、リソース、スコープ、コンポーネント、HTTPコンテンツタイプ、HTTPステータスコード、およびクライアントに基づいて分類されます。 |
apiserver_request_no_resourceversion_list_total | Counter | kube-apiserverに送信され、 |
apiserver_current_inflight_requests | ゲージ | kube-apiserverによって処理されているリクエストの数。 リクエストは次のタイプに分類されます。
|
apiserver_dropped_requests_total | Counter | kube-apiserverでスロットリングが実行されたときにドロップされるリクエストの数。 |
etcd_request_duration_seconds_bucket | ヒストグラム | kube-apiserverから送信されたリクエストと、etcdから返されたレスポンスとの間のレイテンシ。 リクエストは、操作と操作タイプに基づいて分類されます。 ヒストグラム内のバケットは、 |
apiserver_admission_controller_admission_duration_seconds_bucket | ゲージ | アドミッションコントローラの処理レイテンシ。 ヒストグラムは、承認コントローラ名、CREATE、UPDATE、またはCONNECTなどの操作、APIリソース、検証または承認などの操作タイプ、および要求が拒否されるかどうかによって識別されます。 ヒストグラムのバケットは、 |
apiserver_admission_webhook_admission_duration_seconds_bucket | ゲージ | 承認webhookの処理レイテンシ。 ヒストグラムは、承認コントローラ名、CREATE、UPDATE、またはCONNECTなどの操作、APIリソース、検証または承認などの操作タイプ、および要求が拒否されるかどうかによって識別されます。 ヒストグラムのバケットは、 |
apiserver_admission_webhook_admission_duration_seconds_count | Counter | 承認webhookによって処理されたリクエストの数。 ヒストグラムは、承認コントローラ名、CREATE、UPDATE、またはCONNECTなどの操作、APIリソース、検証または承認などの操作タイプ、および要求が拒否されるかどうかによって識別されます。 |
cpu_utilization_core | ゲージ | 使用されるCPUコアの数。 単位: コア。 |
memory_utilization_byte | ゲージ | 使用されたメモリの量。 単位はバイトです。 |
アップ | ゲージ | kube-apiserverが使用可能かどうかを示します。
|
次のリソース使用率メトリックは非推奨です。 これらのメトリックに依存するアラートとモニタリングデータをできるだけ早く削除します。
cpu_utilization_ratio: CPU使用率。
memory_utilization_ratio: メモリ使用率。
ダッシュボードの使用状況ノート
ダッシュボードは、メトリクスとPrometheus Query Language (PromQL) に基づいて生成されます。 次のセクションでは、主要なメトリクス、クラスターレベルの概要、リソース分析、1秒あたりのクエリ数 (QPS) とレイテンシ、アドミッションコントローラーとwebhook、およびクライアント分析のためのkube-apiserverダッシュボードについて説明します。
ほとんどの場合、これらのダッシュボードは次の順序で使用されます。
主要なメトリクスダッシュボードを表示して、クラスターのパフォーマンス統計をすばやく表示します。
クラスターレベルの概要ダッシュボードを表示して、kube-apiserverのレスポンスレイテンシ、kube-apiserverによって処理されているリクエストの数、およびリクエストスロットリングがトリガーされているかどうかを分析します。
リソース分析ダッシュボードを表示して、管理対象コンポーネントのリソース使用状況を確認します。
QPSとレイテンシのダッシュボードを表示して、複数のディメンションに基づいてQPSと応答時間を分析します。
アドミッションコントローラーとwebhookのダッシュボードを表示して、アドミッションコントローラーとwebhookのQPSと応答時間を分析します。
クライアント分析ダッシュボードを表示して、複数のディメンションに基づいてクライアントQPSを分析します。
フィルター
ダッシュボードの上に複数のフィルターが表示されます。 次のフィルターを使用して、動詞とリソースに基づいてkube-apiserverに送信されたリクエストをフィルター処理し、分位数を変更し、PromQLサンプリング間隔を変更できます。
分位数を変更するには、分位数フィルターを使用します。 たとえば、0.9を選択した場合、メトリックのサンプル値の90% がヒストグラムのサンプル値として使用されます。 0.9 (P90) の値は、総サンプル値のほんの一部であるロングテールサンプルの影響を排除するのに役立ちます。 0.99の値 (P99) は、ロングテールサンプルを含む。
次のフィルターを使用して、時間範囲と更新間隔を指定します。
主要な指標
可视性
機能
メトリック | 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に送信されたリクエストの総数に対するドロップされたリクエストの数の比率。 |
クラスターレベルの概要
可视性
機能
メトリック | 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のスロットルレート。 |
リソース分析
可视性
機能
メトリック | PromQL | 説明 |
メモリ使用量 | memory_utilization_byte{container="kube-apiserver"} | kube-apiserverのメモリ使用量。 単位はバイトです。 |
CPU使用率 | cpu_utilization_core{container="kube-apiserver"}* 1000 | kube-apiserverのCPU使用率。 単位: ミリコア。 |
リソースオブジェクトの数 |
|
説明 互換性の問題により、apiserver_storage_objectsとetcd_object_countsの両方のメトリクスがKubernetes 1.22に存在します。 |
QPSとレイテンシ
可视性
機能
メトリック | 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
可视性
機能
メトリック | PromQL | 説明 |
入学コントローラー遅延 [承認] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="admit"}[$interval]))) ) | 承認タイプの承認コントローラーの名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。 ヒストグラムのバケットは、 |
入学コントローラーの遅延 [検証] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="validate"}[$interval]))) ) | 検証タイプのアドミッションコントローラーの名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。 ヒストグラムのバケットは、 |
入場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の名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。 ヒストグラムのバケットは、 |
入会Webhookの遅延 [検証] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="validating"}[$interval]))) ) | 検証タイプの承認webhookの名前、実行された操作、操作が拒否されたかどうか、および操作の期間に関する統計。 ヒストグラムのバケットは、 |
受け入れWebhookリクエストQPS | sum(irate(apiserver_admission_webhook_admission_duration_seconds_count[$interval]))by(name,operation,type,rejected) | 入場ウェブフックのQPS。 |
クライアント分析
可视性
機能
メトリック | 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) |
|
一般的なメトリック異常
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秒より大きい。 |
| すぐに応答できない承認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であれば、異常は発生しません。 |
| リクエストキューがいっぱいです。 問題が一時的なリクエストスパイクまたはすぐに応答できない承認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が不要になった場合は、アンインストールします。
関連ドキュメント
他の制御プレーンコンポーネントのモニタリングメトリックとダッシュボード、およびメトリック異常の処理方法の詳細については、以下のトピックを参照してください。
kube-schedulerのメトリック
kube-controller-managerのメトリック
cloud-controller-managerのメトリック
コンソールまたはAPI操作を使用してPrometheusモニタリングデータを取得する方法の詳細については、「PromQLを使用したPrometheusモニタリングデータのクエリ」をご参照ください。
カスタムPromQLステートメントを使用してManaged Service For Prometheusでアラートルールを作成する方法の詳細については、「Prometheusインスタンスのアラートルールの作成」をご参照ください。