Azure Kubernetes Service (AKS) でのポッドの垂直方向の自動スケーリング

  • [アーティクル]

この記事では、オープンソース バージョンの Kubernetes に基づく Azure Kubernetes Service (AKS) での、Vertical Pod Autoscaler (VPA) の使用方法の概要について説明します。

VPA を構成すると、過去の使用状況に基づいて、ワークロードごとのコンテナーに対するリソース要求と制限が自動的に設定されます。 VPA は、他のポッド用に CPU とメモリを解放し、AKS クラスターを効果的に利用できるようにします。 ポッドの垂直方向の自動スケーリングは、時間の経過に伴うリソースの使用量に関する推奨事項を提供します。 リソース使用量の急増を管理するには、必要に応じてポッド レプリカの数をスケーリングする Horizontal Pod Autoscaler を使用します。

メリット

Vertical Pod Autoscaler には、次の利点があります。

  • アプリケーションの "適切なサイズ" に合わせてプロセッサとメモリのリソースを分析および調整します。 VPA では、スケールアップだけでなく、時間の経過に伴うリソースの使用に基づいたスケールダウンも行います。
  • スケーリング モードが "自動" または "再作成" に設定されたポッドは、リソース要求を変更する必要がある場合に削除されます。
  • リソース ポリシーを指定することで、個々のコンテナーの CPU とメモリの制約を設定できます。
  • ポッドのスケジュール設定に適切なリソースがノードにあることを確認します。
  • プロセッサまたはメモリ リソースに対して行われた調整の構成可能なログを提供します。
  • クラスター リソースの使用率を向上させ、他のポッドのために CPU とメモリを解放します。

制限と考慮事項

Vertical Pod Autoscaler を使用する場合は、次の制限事項と考慮事項について検討してください。

  • VPA では、1 つのクラスターにつき VerticalPodAutoscaler オブジェクトに関連付けられた最大 1,000 個のポッドがサポートされます。
  • VPA では、クラスターで使用可能なリソースよりも多くのリソースが推奨される場合があります。これにより、リソース不足が原因で、ポッドをノードに割り当てて実行することがができなくなります。 この制限を克服するには、LimitRange を名前空間ごとに利用可能な最大リソースに設定します。これにより、ポッドは指定よりも多くのリソースを要求しなくなります。 VerticalPodAutoscaler オブジェクト内のポッドごとに許容される最大リソースの推奨値を設定することもできます。 VPA は、ノード リソースが不足する問題を完全には解決できません。 この制限範囲は固定ですが、ノード リソースの使用量は動的に変化します。
  • 同じ CPU とメモリ使用量のメトリックに基づいてスケーリングを行う Horizontal Pod Autoscaler (HPA) を VPA と併用することはお勧めしません。
  • VPA レコメンダーは、最大 "8 日間" の履歴データのみを保存します。
  • ワークロードの実際のメモリ使用量の可視性が制限されているため、VPA は JVM ベースのワークロードをサポートしていません。
  • VPA では、ユーザー独自の VPA の実装を並行して実行することはできません。 追加のレコメンダーまたはカスタマイズされたレコメンダーの使用はサポートされています。
  • AKS Windows コンテナーはサポートされていません。

VPA の概要

VPA オブジェクトは、次の 3 つのコンポーネントで構成されます。

  • レコメンダー: レコメンダーは、メトリック履歴、メモリ不足 (OOM) イベント、VPA デプロイ仕様など、現在および過去のリソース消費量を監視し、収集した情報を使用して、コンテナーの CPU およびメモリの要求/制限に推奨される値を提供します。
  • アップデーター: アップデーターはマネージド ポッドを監視して、それらのリソース要求が正しく設定されていることを確認します。 正しく設定されていない場合、それらのポッドを削除して、コントローラーが更新された要求に基づいてポッドを再作成できるようにします。
  • VPA アドミッション コントローラー: VPA アドミッション コントローラーは、アップデーターのアクティビティに基づいてコントローラーによって作成または再作成された新しいポッドに対して、適切なリソース要求を設定します。

VPA アドミッション コントローラー

VPA アドミッション コントローラーは、自身を Mutating Admission Webhook として登録するバイナリです。 新しいポッドが作成されると、VPA アドミッション コントローラーは、API サーバーから要求を取得し、一致する VPA 構成があるかどうかを評価するか、対応する VPA 構成を見つけて、現在の推奨事項を使用してポッドにリソース要求を設定します。

スタンドアロン ジョブ overlay-vpa-cert-webhook-check が VPA アドミッション コントローラーの外部で実行されます。 overlay-vpa-cert-webhook-check ジョブは、証明書を作成および更新し、VPA アドミッション コントローラーを MutatingWebhookConfiguration として登録します。

VPA オブジェクトの動作モード

リソース要件を自動計算させるコントローラーごとに、Vertical Pod Autoscaler リソース (最も一般的には "デプロイ") が挿入されます。

VPA には 4 つの動作モードがあります。

  • Auto: VPA は、ポッドの作成中にリソース要求を割り当てて、優先更新メカニズムを使用して既存のポッドを更新します。 Auto は Recreate と同等であり、既定のモードです。 ポッド要求の再起動不要 ("インプレース") の更新が使用可能になると、Auto モードではそれを優先更新メカニズムとして使用できます。 Auto モードでは、VPA は、ポッドのリソース要求を変更する必要が生じるとそれを削除します。 これにより、ポッドが一斉に再起動される場合があり、アプリケーションの不整合が生じる可能性があります。 このような状況で再起動を制限し、一貫性を維持するには、PodDisruptionBudget を使用します。
  • Recreate: VPA はポッドの作成中にリソース要求を割り当てます。また、要求されたリソースが新しい推奨事項と大幅に異なる場合は、既存のポッドを削除することでポッドを更新します (PodDisruptionBudget が定義されている場合は、それが考慮されます)。 このモードは、リソース要求が変更されるたびに必ずポッドを再起動する必要がある場合にのみ使用してください。 それ以外の場合は、使用可能になったときに再起動不要の更新を利用する Auto モードを使用することをお勧めします。
  • Initial: VPA はポッドの作成中にのみリソース要求を割り当てます。 既存のポッドは更新しません。 このモードは、実行中のポッドに影響を与えずに VPA の動作をテストし、理解するのに役立ちます。
  • Off: VPA はポッドのリソース要件を自動的に変更しません。 推奨事項は計算され、VPA オブジェクトで調べることができます。

アプリケーション開発のデプロイ パターン

VPA に慣れていない場合は、アプリケーションの開発中に以下のデプロイ パターンを実行して、VPA 固有のリソース使用特性を特定し、VPA をテストして適切に機能していることを確認し、他の Kubernetes コンポーネントと一緒にテストしてクラスターのリソース使用率を最適化することをお勧めします。

  1. 実稼働クラスターで UpdateMode = "Off" を設定し、推奨モードで VPA を実行することで、VPA をテストし、VPA の扱い方に慣れることができます。 UpdateMode = "Off" により、停止を引き起こす可能性のある構成の誤りが発生するのを防ぐことができます。
  2. まず、一定の期間にわたって実際のリソース使用率テレメトリを収集することで、監視を確立します。これにより、実行中のワークロードの影響を受けるコンテナーおよびポッド リソースの動作および問題の兆候を把握できます。
  3. 監視データに精通して、パフォーマンスの特性を理解します。 この分析情報に基づいて、必要な要求/制限を適宜設定し、次のデプロイまたはアップグレードでそれを適用します。
  4. 要件に応じて、updateMode 値を Auto、Recreate、または Initial に設定します。

次のステップ

AKS クラスターで Vertical Pod Autoscaler を設定する方法については、「AKS で Vertical Pod Autoscaler を使用する」を参照してください。