CPU 負荷は、従来の CPU 使用率メトリックよりもリソースの競合のより正確なインジケーターです。 CPU 使用率が高い場合はリソースの消費量が示されますが、パフォーマンスの問題を示すわけではありません。 Azure Kubernetes Service (AKS) クラスターでは、Pressure Stall Information (PSI) メトリックによる CPU 負荷を理解することで、真のリソース競合の問題を特定するのに役立ちます。
AKS クラスター内のノードで CPU 負荷が発生すると、CPU 使用率が中程度に見えても、アプリケーションのパフォーマンスが低下する可能性があります。 PSI メトリックは、リソースの消費量だけでなく、タスクの遅延を測定することで、実際のリソースの競合に関する分析情報を提供します。
この記事では、PSI メトリックを使用して CPU 負荷を監視し、リソース競合の問題を解決するためのベスト プラクティスを提供します。
症状
次の表は、CPU 負荷の一般的な症状の概要を示しています。
| 症状 | 説明 |
|---|---|
| アプリケーションの待機時間の増加 | CPU 使用率が中程度に見える場合でも、サービスの応答が遅くなります。 |
| スロットル制御されたコンテナー | ノードで CPU リソースを使用できるにもかかわらず、コンテナーの処理に遅延が発生します。 |
| パフォーマンスの低下 | アプリケーションでは、CPU 使用率に関連しない予測できないパフォーマンスの変動が発生します。 |
トラブルシューティング チェックリスト
CPU 負荷の問題を特定して解決するには、次の手順に従います。
手順 1: PSI メトリックを有効にして監視する
PSI メトリックにアクセスするには、次のいずれかの方法を使用します。
- Web ブラウザーで、Azure Monitoring Managed Prometheus またはその他の監視ソリューションを使用して、PSI メトリックのクエリを実行します。
- コンソールで、Kubernetes コマンド ライン ツール (
kubectl) を使用します。
Azure Monitoring Managed Prometheus には、PSI メトリックを監視する方法が用意されています。
「 Prometheus と Grafana を有効にする」の手順に従って、AKS クラスターに対して Azure Monitoring Managed Prometheus を有効にします。
Prometheus に対してカスタマイズされたスクレープ メトリックを有効にするには、「 スクレープ構成」を参照してください。
minumum ingestion profileをfalseに設定し、node-exporterをtrueに設定することをお勧めします。Azure portal から、AKS クラスターに関連付けられている Azure Monitor ワークスペースに移動します。
[監視] で [メトリック] を選びます。
データ ソースとして Prometheus メトリック を選択します。
注
メトリックを使用するには、Azure Monitoring Managed Prometheus でそれらを有効にする必要があります。 これらのメトリックは、Node Exporter または cAdvisor によって公開されます。
Prometheus エクスプローラーで特定の PSI メトリックのクエリを実行します。
ノード レベルの CPU 負荷の場合は、
node_pressure_cpu_waiting_seconds_totalPrometheus クエリ言語 (PromQL) を使用します。
ポッド レベルの CPU 負荷の場合は、
container_cpu_cfs_throttled_seconds_totalPromQL を使用します。
PSI の特定のパーセンテージ（CPU上で少なくとも1つのタスクが停止している時間の割合）を計算します。
rate(node_pressure_cpu_waiting_seconds_total[5m]) * 100
注
container_pressure_cpu_waiting_seconds_totalやcontainer_pressure_cpu_stalled_seconds_totalなどの一部のコンテナー レベルメトリックは、アルファ状態の Kubelet PSI 機能ゲートの一部であるため、AKS では使用できません。 AKS は、ベータ 段階に達すると、機能の使用のサポートを開始します。
手順 2: CPU の負荷を防ぐためのベスト プラクティスを確認する
CPU 負荷を回避するためのベスト プラクティスを実装する方法については、次の表を参照してください。
| ベスト プラクティス | 説明 |
|---|---|
| 使用率ではなく PSI メトリックに重点を置く | リソースの競合の主なインジケーターとして、CPU 使用率ではなく PSI メトリックを使用します。 詳細については、「 PSI - 圧力ストール情報」を参照してください。 |
| CPU 使用率が最も高いポッドを特定する | ほとんどの CPU を使用しているポッドを分離し、圧力を軽減するソリューションを特定します。 詳細については、 AKS クラスターでの CPU 使用率の高いトラブルシューティングを参照してください。 |
| CPU の制限を最小限に抑える | CPU の制限を削除することを検討し、要求に基づいて CPU 共有を持つ Linux の完全に公平なスケジューラ に依存します。 詳細については、「 ポッドとコンテナーのリソース管理」を参照してください。 |
| 適切なサービス品質 (QoS) クラスを使用する | 各ポッドの重要度と競合の感度に基づいて、適切な QoSclass を設定します。 詳細については、「 ポッドのサービス品質の構成」を参照してください。 |
| ポッドの配置を最適化する | ポッドのアフィニティ対策ルールを使用して、CPU 負荷の高いワークロードを同じノードに配置しないようにします。 詳細については、「 ノードへのポッドの割り当て」を参照してください。 |
| 短時間の圧力の急上昇を監視する | 一時的な圧力スパイクは、平均使用率が許容範囲内のように見えても、問題を示す可能性があります。 詳細については、「 リソース メトリック パイプライン」を参照してください。 |
監視する主要な PSI メトリック
注
ノードの CPU 使用率が中程度であっても、ノード上のコンテナーで CFS 調整が発生する場合は、リソース制限を増やすか、削除して Linux の Completely Fair Scheduler (CFS) アルゴリズムに 従います。
ノード レベルの PSI メトリック
-
node_pressure_cpu_waiting_seconds_total: タスクが CPU を待機する累積時間。 -
node_cpu_seconds_total: 比較のための従来の CPU 使用率。
コンテナー レベルの PSI インジケーター
-
container_cpu_cfs_throttled_periods_total: コンテナーが調整される回数。 -
container_cpu_cfs_throttled_seconds_total: コンテナーが制限された合計時間。 - 調整率:
rate(container_cpu_cfs_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m]) * 100
PSI メトリックを使用する理由
AKS では、いくつかの理由から、負荷平均ではなく CPU 負荷のインジケーターとして PSI メトリックが使用されます。
- 特大ノードとマルチコア ノードでは、負荷平均が CPU の飽和度を過少報告することがよくあります。
- チャット層ノードとコンテナー化されたノードでは、負荷平均が過剰に信号を発し、アラートの疲労につながります。
- 負荷平均には cgroup ごとの可視性がないため、ノイズの多いポッドは低いシステム平均の背後に隠れる可能性があります。
リファレンス
- Linux PSI のドキュメント
- Kubernetes リソース管理
- AKS パフォーマンスのベスト プラクティス
- Prometheus と Grafana を有効にする
- Kubernetes のサービス品質
- Linux の完全に公平なスケジューラ
お問い合わせはこちらから
ご質問がある場合は、 Azure コミュニティサポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。