すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:大規模クラスターの利用に関する推奨事項

    ドキュメントセンター

    Container Service for Kubernetes:大規模クラスターの利用に関する推奨事項

    最終更新日:Aug 30, 2026

    Container Service for Kubernetes (ACK) クラスターのパフォーマンスと可用性は、クラスターリソースの数、リソースへのアクセス頻度、およびアクセスパターンに影響を受けます。これらの変数の組み合わせが異なると、API サーバーにかかる負荷のレベルも異なり、パフォーマンスも異なります。大規模な ACK Pro クラスター (通常、500 を超えるノードまたは 10,000 を超える Pod を持つクラスター) では、クラスター管理者は実際のビジネス状況に基づいてクラスターを適切に計画および使用し、メトリクスを注意深く監視して、クラスターの安定性と可用性を確保する必要があります。

    本ガイドについて

    このトピックは、ACK Pro クラスターの開発者および管理者を対象としています。大規模クラスターの計画と使用に関する一般的な推奨事項を提供します。実際のクラスター環境とビジネス要件に基づいて調整してください。

    責任共有モデルに基づき、ACK は Kubernetes コントロールプレーンコンポーネントや etcd を含むクラスターコントロールプレーンコンポーネント、および基盤となる Alibaba Cloud インフラストラクチャのセキュリティを管理します。お客様は、ビジネスアプリケーションのセキュリティ保護とクラウドリソースの設定に責任を負います。詳細については、「責任共有モデル」をご参照ください。

    計画段階

    単一クラスターと複数クラスターの比較

    単一の大規模クラスターは、管理オーバーヘッドを削減し、リソース使用率を向上させます。ただし、一部のビジネスシナリオでは、サービスを複数のクラスターに分割する方が合理的です。

    次のような場合は、複数クラスターを検討してください。

    考慮事項 分割を検討するケース
    分離 ある環境 (例：テスト環境) の問題が本番環境に影響を与えるのを防ぎたい場合。クラスターを分割することで、障害のブラスト半径を縮小できます。
    地理的分布 エンドユーザーの可用性とレイテンシの要件を満たすために、特定のリージョンにクラスターをデプロイする必要がある場合。
    単一クラスターのサイズ制限 ACK マネージドコントロールプレーンは、自動スケーリングとクラスターコンポーネントのパフォーマンス最適化を通じて、さまざまな規模のクラスターに適応します。ただし、Kubernetes アーキテクチャには固有のパフォーマンス制限があり、大きすぎるクラスターは可用性とパフォーマンスに影響を与える可能性があります。大規模クラスターを計画する前に、コミュニティのキャパシティ制限とSLOを確認し、[Quota Center] でクォータを確認してください。要件がコミュニティまたは ACK の制限を超える場合は、複数のクラスターに分割する必要があります。

    アプリケーションのデプロイ、トラフィック管理、Job の配布、監視などのタスクで複数のクラスターを管理するには、フリート管理を有効にしてください。

    クラスターを最新バージョンに維持

    新しい Kubernetes バージョンには、大規模クラスターに直接的なメリットをもたらす安定性、パフォーマンス、スケーラビリティの向上が含まれています。注目すべき例は次のとおりです。

    ACK は、コミュニティと同期してサポート対象の Kubernetes バージョンをリリースし、期限切れバージョンのサポートを終了します。これには、新機能のリリース、バグ修正、セキュリティパッチの停止が含まれる一方、期限切れバージョンには限定的な技術サポートのみを提供します。ドキュメント、コンソールの通知、内部メッセージなどのチャネルを通じてバージョンリリースの発表を監視し、潜在的なクラスターのセキュリティと安定性の問題を回避するために、速やかにアップグレードしてください。

    ACK Pro プリセットコントロールプレーンの使用

    ACK Pro クラスターのコントロールプレーンは、自動スケーリングアーキテクチャを使用します。超大規模クラスターや突然の高い同時実行性が発生した場合、エラスティックスケールアウトの応答遅延がビジネスの継続性に影響を与える可能性があります。ACK Pro プリセットコントロールプレーンは、コントロールプレーンリソースを事前に割り当てて固定し、API の同時実行性と Pod のスケジューリング能力を高いレベルで保証します。これは、AI トレーニングや推論、超大規模クラスター、ミッションクリティカルなワークロードに適しています。

    ACK Pro プリセットコントロールプレーンは、コントロールプレーンリソースと API サーバーのベースライン構成を固定することで、事後に追いつくための弾力的なメカニズムに依存するのではなく、エラスティックスケールアウトの不確実性を根本から排除します。これにより、コントロールプレーンのパフォーマンスが常に予測可能になります。

    詳細については、「ACK Pro プリセットコントロールプレーン」をご参照ください。

    クラスターリソース制限の監視

    大規模クラスターで可用性とパフォーマンスを維持するためには、以下の制限内に収めるようにしてください。

    リソース 制限 アクション
    etcd データベースサイズ (DB Size) 8 GB 未満に維持します。etcd データベースが大きすぎると、データの読み取り/書き込みレイテンシ、システムリソースの消費、選出レイテンシなどのパフォーマンスが低下します。また、サービスとデータの復旧はより困難になり、時間も要します。 etcd DB の合計サイズを 8 GB 未満に維持します。

    • クラスターリソースの総量を制御し、未使用のリソースを速やかにクリーンアップしてください。

    • 頻繁に変更されるリソースについては、各オブジェクトのサイズを 100 KB 未満に維持します。etcd のキーバリューペアが更新されるたびに、新しい履歴バージョンが生成されます。大きなオブジェクトが頻繁に更新されるシナリオでは、etcd は履歴バージョンを保存するためにより多くのリソースを消費します。
    etcd 内のリソースタイプごとの合計データ タイプごとに 800 MB 未満に維持します。あるリソースタイプの合計ボリュームが大きすぎると、そのタイプのすべてのリソースをリスト表示するクライアントが大量のシステムリソースを消費します。深刻な場合、API サーバーまたはカスタムコントローラーが初期化に失敗することがあります。 新しい CustomResourceDefinition (CRD) を定義する際は、カスタムリソース (CR) の最終的な数を事前に見積もります。Helm を使用してチャートをデプロイする場合、Helm はデプロイ状況を追跡するためにリリースを作成することに注意してください。デフォルトでは、Helm はリリース情報を Secret に保存します。大規模クラスターでは、大量のリリース情報を Secret に保存すると、Kubernetes の Secret の合計サイズ制限を超える可能性があります。代わりにHelm の SQL ストレージバックエンドを使用してください。
    API サーバーの CLB 接続と帯域幅 最大帯域幅：5,120 Mbps。接続制限については、「CLB インスタンス」をご参照ください。CLB の接続または帯域幅の制限を超えると、ノードが Not Ready 状態になる可能性があります。 1,000 以上のノードを持つクラスターでは、使用量課金制の Classic Load Balancer (CLB) インスタンスを使用してください。大規模クラスターが Default 名前空間の Kubernetes Service にアクセスする場合は、ENI (Elastic Network Interface) ダイレクト接続モードを使用します。2023 年 2 月以降に作成された Kubernetes 1.20 以降のクラスターでは、デフォルトで ENI ダイレクト接続が使用されます。詳細については、「内部エンドポイントを使用して API サーバーにアクセスする」をご参照ください。
    名前空間ごとの Service 数 5,000 未満に維持します。 kubelet は、Service 情報を環境変数として Pod に注入します。名前空間あたりの Service 数が多すぎると、Pod の起動が遅くなったり、起動に失敗したりします。これを回避するには、podSpec で enableServiceLinks: false を設定します。詳細については、「Service へのアクセス」をご参照ください。
    クラスター内の合計 Service 数 合計で 10,000 未満、LoadBalancer タイプの Service は 500 未満に維持します。 Service が多すぎると、kube-proxy が処理するネットワークルールが増加し、パフォーマンスが低下します。LoadBalancer タイプの Service では、数が多いと CLB への同期遅延が数分に達することがあります。
    Service エンドポイントあたりのバックエンド Pod 数 3,000 未満に維持します。 各ノードの kube-proxy は、Service の更新を監視してノードのネットワークルールを更新します。Service に多数のエンドポイントがある場合、その Endpoints オブジェクトは大きくなり、Endpoints オブジェクトが更新されるたびに、API サーバーと kube-proxy の間で大量のトラフィックが転送されます。クラスターが大きくなるほど、このストーム効果は顕著になります。これに対処するため、v1.19 以降のクラスターでは、kube-proxy はデフォルトで EndpointSlices を使用します。大規模クラスターでは、Endpoints の代わりに EndpointSlices を使用してください。EndpointSlices はエンドポイントをより小さなチャンクに分割し、変更ごとに転送されるデータを削減します。Endpoints を直接読み取るカスタムコントローラーを使用している場合、Endpoints オブジェクトあたりの数を 1,000 未満に維持してください。これを超えると、オブジェクトは自動的に切り捨てられます。詳細については、「容量超過のエンドポイント」をご参照ください。
    全 Service にわたる合計エンドポイント数 64,000 未満に維持します。 エンドポイントが多すぎると、API サーバーに過負荷がかかり、ネットワークパフォーマンスが低下します。
    保留中の Pod 10,000 未満に維持します。 保留中の Pod 数が多いと、スケジューラーが繰り返しイベントを生成し、イベントストームを引き起こす可能性があります。
    KMS V1 暗号化を使用するクラスター内の Secret 2,000 未満に維持します。 KMS V1 では、暗号化ごとに新しいデータ暗号化キー (DEK) が生成されます。クラスターの起動時またはアップグレード時に、すべての Secret が順次復号化されます。Secret が多すぎると、起動が大幅に遅くなります。詳細については、「KMS を使用した保管時の暗号化」をご参照ください。

    設定段階

    コントロールプレーンコンポーネントのパラメーター設定

    kube-apiserver

    kube-apiserver は、コントロールプレーンを保護するために同時リクエスト処理を制限します。制限を超えると、HTTP 429 (Too Many Requests) を返し、クライアントに再試行を指示します。サーバーサイドのスロットリングがないと、過剰なリクエストがコントロールプレーンをクラッシュさせる可能性があります。

    スロットリングメカニズム

    Kubernetes のバージョンに応じて、2 つのスロットリングメカニズムが存在します。

    • v1.18 より前：最大同時実行数スロットリングのみ。起動パラメーター --max-requests-inflight と --max-mutating-requests-inflight は、それぞれ読み取りリクエストと書き込みリクエストの同時実行数を制限します。優先順位の区別はなく、低速で優先度の低いリクエストが緊急のリクエストをブロックする可能性があります。ACK Pro クラスターは、これらのパラメーターのカスタマイズをサポートしています。詳細については、「コントロールプレーンコンポーネントのパラメーターのカスタマイズ」をご参照ください。

    • v1.18 以降：API Priority and Fairness (APF) は、きめ細かいトラフィック管理を提供します。APF はリクエストを優先度別に分類・分離し、公平性を維持しつつ、優先度の高いリクエストが先に処理されるようにします。APF は v1.20 でベータ版となり、デフォルトで有効になっています。v1.20 以降を実行しているクラスターでは、合計同時リクエスト容量は --max-requests-inflight と --max-mutating-requests-inflight の合計に等しくなります。APF は、その容量を割り当てるために 2 種類の CRD を使用します。

      • PriorityLevelConfiguration：優先度レベルと、各レベルが受け取る合計同時実行数の割合を定義します。

      • FlowSchema：受信リクエストを PriorityLevelConfiguration にマッピングします。

      kube-apiserver はこれらのオブジェクトを自動的に維持します。現在の設定を表示するには、PriorityLevelConfiguration を表示してください。

      ACK は、ACK コアコンポーネントのために ack-system-leader-election と ack-default を FlowSchema に追加します。残りのエントリは、Kubernetes コミュニティのデフォルトと一致しています。
      kubectl get PriorityLevelConfiguration
# 想定される出力
NAME              TYPE      ASSUREDCONCURRENCYSHARES   QUEUES   HANDSIZE   QUEUELENGTHLIMIT   AGE
catch-all         Limited   5                          <none>   <none>     <none>             4m20s
exempt            Exempt    <none>                     <none>   <none>     <none>             4m20s
global-default    Limited   20                         128      6          50                 4m20s
leader-election   Limited   10                         16       4          50                 4m20s
node-high         Limited   40                         64       6          50                 4m20s
system            Limited   30                         64       6          50                 4m20s
workload-high     Limited   40                         128      6          50                 4m20s
workload-low      Limited   100                        128      6          50                 4m20s

      FlowSchema の表示：

      kubectl get flowschemas
# 想定される出力
NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE     MISSINGPL
exempt                         exempt            1                    <none>                4d18h   False
probes                         exempt            2                    <none>                4d18h   False
system-leader-election         leader-election   100                  ByUser                4d18h   False
endpoint-controller            workload-high     150                  ByUser                4d18h   False
workload-leader-election       leader-election   200                  ByUser                4d18h   False
system-node-high               node-high         400                  ByUser                4d18h   False
system-nodes                   system            500                  ByUser                4d18h   False
ack-system-leader-election     leader-election   700                  ByNamespace           4d18h   False
ack-default                    workload-high     800                  ByNamespace           4d18h   False
kube-controller-manager        workload-high     800                  ByNamespace           4d18h   False
kube-scheduler                 workload-high     800                  ByNamespace           4d18h   False
kube-system-service-accounts   workload-high     900                  ByNamespace           4d18h   False
service-accounts               workload-low      9000                 ByUser                4d18h   False
global-default                 global-default    9900                 ByUser                4d18h   False
catch-all                      catch-all         10000                ByUser                4d18h   False
    スロットリングへの対応

    スロットリングを検出するには、HTTP 429 応答を確認するか、apiserver_flowcontrol_rejected_requests_total メトリクスを監視します。スロットリングが発生した場合：

    • ACK Pro プリセットコントロールプレーンの使用：プリセットコントロールプレーンは、API サーバーのベースラインリソースを固定し、保証された高い同時実行処理能力を直接提供します。詳細については、「ACK Pro プリセットコントロールプレーン」をご参照ください。

    • PriorityLevelConfiguration の調整：

      • スロットリングされてはならないリクエストについては、新しい FlowSchema を作成し、workload-high や exempt などの高優先度レベルにマッピングします。exempt リクエストは APF によってスロットリングされないため、注意して使用してください。また、高優先度リクエストのために、より高い同時実行性を持つ新しい PriorityLevelConfiguration を作成することもできます。

      • API サーバーに高い負荷をかける低速なクライアントについては、それらのリクエストを低同時実行性の PriorityLevelConfiguration にマッピングする FlowSchema を作成します。

    kube-controller-manager と kube-scheduler

    ACK Pro プリセットコントロールプレーンにアップグレードした後、kube-controller-manager と kube-scheduler が API サーバーとの通信に使用する QPS 関連のパラメーターは、選択されたティアに基づいて自動的に調整されます。

    kubelet

    kube-api-qps のデフォルト値は 5、kube-api-burst のデフォルト値は 10 であり、ほとんどのクラスターで十分です。Pod のステータス更新の遅延、スケジューリングの遅延、または永続ボリュームのマウントの遅延が見られる場合は、これらの値を増やしてください。詳細については、「ノードプールの kubelet 設定のカスタマイズ」をご参照ください。

    重要

    • kubelet の QPS を増やすと、各ノードが API サーバーと通信するレートが上がります。コントロールプレーンの過負荷を避けるために、値を徐々に増やし、API サーバーのパフォーマンスを監視してください。

    • ACK は、ロールアウト中のコントロールプレーンの安定性を保護するために、ノードプールごとの並列 kubelet 更新を バッチあたり 10 ノード以下に制限します。

    大規模ワークロードの計画

    API アクセスを必要としない Pod に対する ServiceAccount トークンの自動マウントの無効化

    kubelet は、Pod にマウントされた各 Secret に対して永続的な Watch 接続を確立します。多数の Watch 接続が、コントロールプレーンのパフォーマンスを低下させます。

    • Kubernetes v1.22 より前：ServiceAccount が指定されていない場合、Kubernetes はデフォルトの ServiceAccount の Secret を自動的にマウントします。API サーバーにアクセスしないバッチ Job やアプリケーション Pod については、automountServiceAccountToken: false を設定してこのマウントをスキップします。これにより、不要な Secret と Watch 接続の作成を回避できます。詳細については、「API 認証情報の自動マウントのオプトアウト」をご参照ください。

    • Kubernetes v1.22 以降：TokenRequest API を使用して、短命で自動的にローテーションされるトークンを取得し、projected ボリュームとしてマウントします。これにより、セキュリティが向上し、kubelet が維持する Watch 接続の数が減少します。詳細については、「ServiceAccount トークンボリュームプロジェクションの使用」をご参照ください。

    Kubernetes オブジェクトの数とサイズの管理

    未使用のリソース (ConfigMap、Secret、PVC) を速やかにクリーンアップすることで、システムオーバーヘッドを削減し、etcd を軽量に保つことができます。

    • デプロイ履歴の制限：revisionHistoryLimit をより低い値に設定して、Kubernetes が保持する古い ReplicaSet の数を制御します。デフォルトは 10 です。頻繁に更新される Deployment が多いクラスターでは、高い履歴保持は kube-controller-manager の管理オーバーヘッドを増加させます。詳細については、「revisionHistoryLimit」をご参照ください。

    • 完了した Job の自動クリーンアップ：ttlSecondsAfterFinished を使用して、完了した Job とその Pod を指定した期間の後に削除します。これにより、多くの CronJob を実行するクラスターで Job オブジェクトが蓄積されるのを防ぎます。詳細については、「完了したリソースの TTL コントローラー」をご参照ください。

    インフォーマーベースのコンポーネントに対する適切なリソース制限の設定

    インフォーマーベースのコンポーネント (コントローラーや kube-scheduler など) は、監視対象リソースのローカルキャッシュを維持します。そのメモリ使用量は、それらのリソースの数とサイズに比例して増加します。

    大規模クラスターでは、メモリ不足 (OOM) エラーを防ぐために、これらのコンポーネントのメモリ消費量に細心の注意を払う必要があります。コンポーネントがメモリ不足になると、強制終了されて再起動します。再起動のたびに新しい List-Watch サイクルがトリガーされ、API サーバーに追加の負荷がかかります。頻繁な再起動は、コントロールプレーンを劣化させるループを引き起こします。

    インフォーマーベースのコンポーネントのメモリ制限を、管理している実際のリソース規模に合わせて増やしてください。

    Webhook と API サービス の適切な設定

    クラスターに Webhook または API サービスが設定されている場合、特定のリソースへのリクエストは Webhook および API サービス サーバーを通過します。カスタム Webhook または API サービスサーバーからの応答が遅いと、API サーバーでリクエストが滞留し、応答が遅くなります。Webhook および API サービスサーバーのリソース使用率を監視し、適時にスケールアウトしてください。

    ランタイム段階

    スケーリングレートの計画

    コントロールプレーンは、大規模クラスターであっても、安定した運用中は通常、低負荷です。リスクは、一度に多くのリソースを作成または削除したり、多くのノードを同時にスケーリングしたりするなど、急速で大規模な変更から生じます。

    たとえば、安定したワークロードを実行している 5,000 ノードのクラスターでは、コントロールプレーンの負荷はほとんど見られないかもしれません。しかし、1,000 ノードのクラスターが 1 分以内に 10,000 の短期間の Job を作成したり、2,000 ノードを同時にスケールアウトしたりすると、コントロールプレーンが限界に達する可能性があります。

    重要

    以下の数値は厳密な制限ではなく、参考ガイドラインです。多くの要因がコントロールプレーンの容量に影響します。常に段階的にスケーリングしてください。コントロールプレーンが正常に応答していることを確認した後にのみ、レートを上げてください。

    ノードのスケーリング：

    2,000 以上のノードを持つクラスターで、ノードプールを介して手動でスケーリングする場合：

    • 単一ノードプール、単一操作：100 ノード以下

    • 複数のノードプールで同時に：合計で 300 ノード以下

    Pod のスケーリング：

    Pod が Service に関連付けられている場合、各スケーリングイベントは Endpoints または EndpointSlice を更新し、その更新をすべてのノードにプッシュします。これにより、クラスター全体のデータ伝播イベントが発生します。大規模クラスターでは、この効果は増幅されます。

    5,000 以上のノードを持つクラスターの場合：

    • Service エンドポイントに関連付けられていない Pod：更新 QPS ≤ 300/s

    • Service エンドポイントに関連付けられている Pod：更新 QPS ≤ 10/s

    ローリングアップデート戦略を使用する Deployment では、maxUnavailable と maxSurge に小さい値を設定して、Pod の置換レートを減らします。

    クライアントアクセスパターンの最適化

    クラスターリソース数が増加するにつれて、頻繁な API サーバーへのリクエストはコントロールプレーンの負荷を増幅させ、連鎖的な障害を引き起こす可能性があります。API サーバーにアクセスするコントローラーやツールを構築する際は、以下のガイドラインに従ってください。

    キャッシュされたデータアクセスのためのインフォーマーの使用：

    • client-go インフォーマーを使用して、API サーバーに直接 List リクエストを発行する代わりに、ローカルキャッシュからリソースを読み取ります。

    • インフォーマーは単一の Watch 接続を維持し、読み取りリクエストをローカルで処理するため、API サーバーの負荷を大幅に削減します。

    API サーバーへの直接リクエストの最適化：

    • List リクエストで resourceVersion=0 を設定することで、etcd を経由せずに API サーバーのキャッシュから読み取ります。これにより、API サーバーと etcd 間のラウンドトリップが減り、応答が高速化されます。

      k8sClient.CoreV1().Pods("").List(context.Background(), metav1.ListOptions{ResourceVersion: "0"})

    • ラベルセレクターとフィールドセレクターを使用することで、List リクエストのスコープを絞り込み、応答ペイロードのサイズを削減します。注意：etcd はキーバリューストアであり、ラベルやフィールドでフィルタリングすることはできません。API サーバーがそのキャッシュからフィルタリングを処理します。etcd に直接ヒットしないように、常にセレクターを resourceVersion=0 と組み合わせてください。

    • CRD 以外のリソースには protobuf を使用する。protobuf は JSON よりも少ないメモリと帯域幅を使用します。Accept ヘッダーに複数のコンテンツタイプを指定して、protobuf が利用できない場合に JSON にフォールバックします。

      Accept: application/vnd.kubernetes.protobuf, application/json

      詳細については、「リソースの代替表現」をご参照ください。

    集中型コントローラー設計の採用：

    各ノードで独立したコントローラーをデプロイし、それぞれがクラスター全体の状態を監視するような設計は避けてください。起動時に、そのようなすべてのコントローラーが同時に List リクエストを発行して状態を同期しようとし、コントロールプレーンをクラッシュさせる可能性があります。

    代わりに、クラスター全体に対して 1 つまたは少数の集中管理されたコントローラーインスタンスを実行します。集中型コントローラーは、起動時に単一の List リクエストを発行し、最小限の Watch 接続を維持するため、API サーバーへの負荷を劇的に削減します。

    可観測性の段階：コントロールプレーンメトリクスの監視

    コントロールプレーンコンポーネントの監視ダッシュボードを使用して、コアメトリクスを追跡し、問題を早期に検出します。詳細については、「コントロールプレーンコンポーネントの監視」をご参照ください。

    コントロールプレーンのリソース使用量

    すべてのコントロールプレーンコンポーネントのリソース使用量を表示できます。関連するメトリクスを次の表に示します。

    メトリクス PromQL 説明
    メモリ使用量 memory_utilization_byte{container="kube-apiserver"} API サーバーのメモリ使用量 (バイト)
    CPU 使用量 cpu_utilization_core{container="kube-apiserver"}*1000 API サーバーの CPU 使用量 (ミリコア)
    API リクエストの同時実行性 sum(apiserver_flowcontrol_current_executing_seats) API サーバーの同時実行性 (シート単位)
    Pod スケジューリングレート rate(scheduler_schedule_attempts_total{result="scheduled"}[2m]) Pod スケジューリングレート (Pod/秒)
    etcd データベースサイズ max(etcd_mvcc_db_total_size_in_use_in_bytes) etcd データベースサイズ (バイト)

    kube-apiserver

    完全なメトリクスリストと表示手順については、「kube-apiserver コンポーネントの監視メトリクス」をご参照ください。

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

    メトリクス PromQL 注意
    リソースオブジェクト数 max by(resource)(apiserver_storage_objects) Kubernetes 1.22 以降
    max by(resource)(etcd_object_counts) Kubernetes 1.22 以前。両方のメトリクスは互換性のために v1.22 で共存します

    リクエストレイテンシ：

    メトリクス 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)) API サーバーの Pod、リソース、スコープごとの GET 応答時間
    LIST リクエストレイテンシ histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le)) API サーバーの Pod、リソース、スコープごとの LIST 応答時間
    書き込みリクエストレイテンシ histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET|WATCH|LIST|CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le)) verb、リソース、スコープごとの変更リクエストの応答時間

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

    メトリクス PromQL 説明
    リクエストスロットリングレート sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name) 読み取りリクエストのスロットリングレート。No data または 0 はスロットリングがないことを意味します
    sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name) 変更リクエストのスロットリングレート

    kube-scheduler

    完全なメトリクスリストと表示手順については、「kube-scheduler コンポーネントの監視メトリクス」をご参照ください。

    保留中の Pod：

    メトリクス PromQL 説明
    スケジューラーの保留中 Pod scheduler_pending_pods{job="ack-scheduler"} タイプ別の内訳：unschedulable (スケジューリング不可)、backoff (失敗して再試行待ち)、active (スケジューリング準備完了)

    リクエストレイテンシ：

    メトリクス PromQL 説明
    kube-apiserver リクエストレイテンシ histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le)) kube-scheduler がリクエストを送信してから kube-apiserver が応答を返すまでの時間 (verb と URL 別)

    kube-controller-manager

    完全なメトリクスリストと表示手順については、「kube-controller-manager コンポーネントの監視メトリクス」をご参照ください。

    ワークキュー：

    メトリクス PromQL 説明
    ワークキューの深さ sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name) 指定された間隔でのワークキューの長さの変化率
    ワークキューの処理遅延 histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le)) イベントがワークキューで待機している時間

    etcd

    完全なメトリクスリストと表示手順については、「etcd コンポーネントの監視メトリクス」をご参照ください。

    キーバリュー数：

    メトリクス PromQL 説明
    合計 KV 数 etcd_debugging_mvcc_keys_total etcd クラスター内のキーバリューペアの総数

    データベースサイズ：

    メトリクス PromQL 説明
    ディスクサイズ etcd_mvcc_db_total_size_in_bytes etcd バックエンドデータベースの合計サイズ
    データベース使用量 etcd_mvcc_db_total_size_in_use_in_bytes etcd バックエンドデータベースの実際の使用サイズ

    関連ドキュメント