Kubernetes の垂直自動スケーリングはどこに向かっているのでしょうか?

現在、Kubernetes の Pod Horizo​​ntal Autoscaler (HPA) が業界で広く使用されています。ただし、一部の特殊な Pod (一部のステートフル Pod など) の場合、HPA ではリソース不足の問題をうまく解決できません。ここで、Vertical Pod Autoscaler (VPA) について説明します。この記事では主に、Kubernetes コミュニティの Vertical Pod Autoscaler コンポーネントの開発計画について紹介します。

[[284711]]

VPA の定義

Vertical Pod Autoscaler (VPA) は、履歴データ、クラスター内の使用可能なリソースの数、リアルタイム イベント (OMM、つまりメモリ不足など) に基づいて、Pod に必要なリソースを自動的に設定し、実行時にリソースを自動的に調整できる基本サービスです。

導入

背景

• コンピューティングリソース
• リソースサービス品質
• 入場管理者
• 外部アクセスウェブフック

ターゲット

VPA には 2 つの目標があります。

• リソース要求を自動的に構成することで運用コストを削減します。
• これにより、コンテナのメモリ不足や CPU 不足のリスクを最小限に抑えながら、クラスター リソースの使用率が向上します。

関連機能

水平ポッドオートスケーラー (HPA)

HPA は、リアルタイムの CPU 使用率やその他の特定のシグナルに基づいて、レプリケーション コントローラー内の Pod の数を動的に調整する基本サービスです。

通常、ユーザーはステートレス ワークロードには HPA を選択し、ステートフル ワークロードには VPA を選択します。組み合わせて使用​​されるシナリオもいくつかあります。

クラスターオートスケーラー

クラスターの自動スケーリングは、クラスターの全体的なリソース使用率に基づいて Kubernetes クラスターのサイズを動的に調整します。

クラスターの自動スケーリング、HPA、および VPA は、完全な自動スケーリング ソリューションを提供します。

初期リソース

初期リソースは、履歴リソース使用率に基づいて初期リソース要求を提供します。これは Pod が作成された場合にのみトリガーされ、VPA はこの機能を継承して使用することを目的としています。

インプレース更新

インプレース アップグレードは、ノードに十分なリソースがある場合に、既存のコンテナを強制終了せずにリソース要求と制限を調整する計画された機能です。

VPA はこの機能から大きな恩恵を受けますが、最小限の実行可能な製品 (MVP) の妨げになるとは考えられていません。

リソースの見積もり

リソース推定は、実行中のコンテナから未使用のリソースを一時的に再利用することでリソース使用率を向上させることができるもう 1 つの計画されている機能です。

リソース推定は、より短いタイムライン（ローカルの短期履歴データのみに基づく）に基づいており、回復後の品質が低く、初期のリソース予測を提供しないという点で、VPA とは異なります。 VPA とリソース推定は補完的です。

必要

関数

• VPA は、Pod が送信されるときにコンテナ リソース (CPU およびメモリの要求と制限) を設定できます。
• VPA は、特に CPU 不足やメモリ オーバーフローなどのイベントに応答して、既存の Pod のコンテナ リソースを調整できます。
• VPA がポッドを再起動する場合、サービス中断のコストを考慮する必要があります。
• ユーザーは、VPA を構成して、リソースに固定の制限、具体的には最小および最大のリソース要求を課すことができます。
• VPAは少なくともポッドコントローラと互換性がある必要があります

展開

互換性がある。具体的には：

• リソースの更新は、仕様の更新に干渉したり競合したりすることはできません。
• 既存の展開では、VPA ポリシーを展開できます。
• 特に、VPA ポリシーの適用後にのみスケジュールできる一部のポッドについては、ポッドを作成するときにできるだけ早く VPA ポリシーに従うことができるようにします。

可用性

重量級コンポーネント (データベースまたはレコメンダー) の障害によって、既存の Pod の再作成がブロックされることはありません。 Pod 作成パスにとって重要なコンポーネントは、高可用性になるように設計する必要があります。

スケーラビリティ

インプレース アップグレード コンポーネントが開発されると、VPA はそれを使用できるようになります。

デザイン

概要

• 新しい API リソースを提案します: VerticalPodAutoscaler 。これには、ラベル セレクター (一致するポッド)、リソース ポリシー (VPA がリソースを計算する方法を制御)、更新ポリシー (リソースの変更をポッドに適用する方法を制御)、および推奨されるリソース情報が含まれます。
• VPA Recommender は、Metrics Server からクラスター内のすべての Pod のリソース使用率シグナルとメモリ オーバーフロー イベントを考慮する新しいコンポーネントです。
• VPA Recommender はすべての Pod を監視し、各 Pod の新しい推奨リソースを継続的に計算し、それらを VPA オブジェクトに保存します。
• VPA Recommender は、Pod の詳細を取得し、推奨情報を返す同期 API を公開します。
• すべてのポッド作成リクエストは、VPA アドミッション コントローラーを経由します。 Pod がいずれかの VPA オブジェクトと一致する場合、Admission Controller は VPA Recommender によって推奨された値に従ってコンテナのリソースを書き換えます。 Recommender が接続できない場合は、VPA オブジェクトにキャッシュされている推奨情報を返します。
• VPA Updater は、Pod のリアルタイム更新を担当するコンポーネントです。 Pod が VPA の自動モードを使用する場合、Updater は推奨リソースに基づいて更新方法を決定します。 MVP モードでは、これはポッドを削除し、新しいリソースに基づいて再作成することによって実行されます。そのためには、ポッドがレプリカ セット (またはそれを再作成できる他のコンポーネント) に属している必要があります。今後、Updater はインプレース アップグレードを活用する予定です。これは、Pod の再作成または再割り当てはサービスに大きな混乱をもたらすため、最小限に抑える必要があるためです。
• VPA はコンテナのリソース要求のみを制御します。リソース制限を無制限に設定します。リソース要求の計算は、現在の動作状況と過去の動作状況の分析に基づいて行われます。
• 履歴ストレージは、API サーバーからリソース使用率信号とメモリ オーバーフローを取得し、永続的に保存するコンポーネントです。 Recommender はこれらの履歴データを使用して、最初に状態を初期化します。 History Storage の基本的な実装は Prometheus を使用しています。

システムアーキテクチャ

VPA アーキテクチャ図

API

私たちは、容量拡張ターゲット、つまり Pod を一致させるために使用されるラベル セレクターと、更新ポリシーとリソース ポリシーの 2 つのポリシー モジュールを含む、新しいタイプの API オブジェクト VertialPodAutoscaler を提案します。さらに、彼は VPA 計算に関する最新の推奨事項を保持しています。

VPA API オブジェクトの概要

// VerticalPodAutoscalerは垂直ポッドの設定です
// オートスケーラーは、履歴と現在の状況に基づいてポッドリソースを自動的に管理します。  
 //本物 時間リソースの活用。
タイプVerticalPodAutoscaler構造体{
    metav1.TypeMeta
    // 標準オブジェクトメタデータ。
    // 詳細情報: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
    // +オプション
    metav1.オブジェクトメタ
 
    //オートスケーラーの動作の仕様。
    // 詳細情報: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec- and -status。
    // +オプション
    スペック VerticalPodAutoscalerSpec 
 
    //オートスケーラーに関する現在の情報。
    // +オプション
    ステータス VerticalPodAutoscalerStatus
 } 
 
 // VerticalPodAutoscalerSpec は、オートスケーラーの動作の仕様です。
タイプVerticalPodAutoscalerSpec {
    //セットを決定するラベルクエリ オートスケーラーによって制御されるポッド。
    // 詳細情報: https://kubernetes.io/docs/concepts/overview/working- with -objects/labels/#label-selectors
    セレクタ *metav1.LabelSelector 
 
    //ポッドに変更を適用する方法に関するルールを説明します。
    // +オプション
    アップデートポリシーポッドアップデートポリシー
 
    // オートスケーラーが推奨リソースを計算する方法を制御します。
    // +オプション
    リソースポリシー PodResourcePolicy
 } 
 
 // VerticalPodAutoscalerStatus は、オートスケーラーの実行時状態を記述します。
タイプVerticalPodAutoscalerStatus {
    //時間 ステータスが最後に更新された日時。
    最終更新時間 metav1。時間 
    //推奨されるリソースの最新の計算量
    //制御されたポッドの自動スケーラー。
    // +オプション
    推奨事項 推奨ポッドリソース
    //オートスケーラーのステータスを説明する、人間が読める形式の自由形式のメッセージ。
    ステータスメッセージ文字列
}

ラベルセレクター

ラベル セレクターは、指定された VPA 戦略に基づいて、どのポッドをスケーリングする必要があるかを決定します。 Recommender は、特定の VPA に一致するすべてのシグナルを集約するため、ユーザーはラベルを設定して、同様の動作をするポッドを 1 つの VPA の下にグループ化することが重要です。

ポッドが複数の VPA ポリシーに同時に一致する場合など、競合をどのように処理するかはまだ決定されていません。

更新ポリシー

更新ポリシーは、VPA が変更を適用する方法を制御します。 MVPでは、モードという1つのフィールドのみが含まれます。

 「更新ポリシー」 {
 "モード" : "" ,
 }

設定できるモードは 3 つあります。

• 初期: VPA は、ポッドの作成時にのみリソースを割り当て、ポッドのライフサイクルの残りの期間中はポッドのリソースを変更しません。
• 自動 (デフォルト): VPA は、ポッドの作成時にリソースを割り当て、ポッドの廃止や再スケジュールなど、他のポッドのライフサイクル中にリソースを更新できます。
• オフ: VPA は Pod リソースを変更しません。 Recommender は引き続き VPA オブジェクト内に推奨事項を生成し、演習で使用できます。

次のいずれかの方法で VPA をオフにできます。

• 更新ポリシーをオフに変更します。
• VPA コンポーネントを削除します。
• VPA ラベル セレクターと一致しないように、Pod のラベルを変更します。

注: VPA を無効にすると、Pod はそれ以上の変更を行うことができなくなりますが、ユーザーが手動で更新するまで Pod の元のリソース状態は復元されません。

 // VerticalPodAutoscalerStatus は、オートスケーラーの実行時状態を記述します。
タイプVerticalPodAutoscalerStatus {
    //時間 ステータスが最後に更新された日時。
    最終更新時間 metav1。時間 
    //推奨されるリソースの最新の計算量
    //制御されたポッドの自動スケーラー。
    // +オプション
    推奨事項 推奨ポッドリソース
    //オートスケーラーのステータスを説明する、人間が読める形式の自由形式のメッセージ。
    ステータスメッセージ文字列
} 
 
 // UpdateMode は、オートスケーラーがポッド リソースに変更を適用するタイミングを制御します。
 UpdateMode 文字列型
定数(
    // UpdateModeOff は、オートスケーラーが Pod リソースを変更しないことを意味します。
    //レコメンダーは推奨リソースを
    // VerticalPodAutoscaler オブジェクト。これは「ドライラン」に使用できます。
    UpdateModeOff UpdateMode = "オフ"  
    // UpdateModeInitial は、オートスケーラーがポッドにのみリソースを割り当てることを意味します
    // 作成時に設定され、ポッドの有効期間中は変更されません。
    UpdateModeInitial UpdateMode = "Initial"  
    // UpdateModeAuto は、ポッドの作成時にオートスケーラーがリソースを割り当てることを意味します
    //さらにポッドの存続期間中に更新することもできます。
    // ポッドの削除/再スケジュールを含みます。
    UpdateModeAuto UpdateMode = "自動"  
 ） 
 
 // PodUpdatePolicy は、変更がポッドに適用される方法に関するルールを記述します。
 PodUpdatePolicy構造体型{
    // オートスケーラーがポッド リソースに変更を適用するタイミングを制御します。
    // +オプション
    アップデートモード アップデートモード
}

リソースポリシー

リソース ポリシーは、VPA が推奨リソースを計算する方法を制御します。 MVP では、各コンテナー要求にオプションの上限と下限が含まれます。リソース戦略は後で追加のスイッチを使用して拡張でき、ユーザーは特定のシナリオに合わせて推奨アルゴリズムを調整できます。

定数(
    // DefaultContainerResourcePolicyは次のように渡されます 
    // コンテナリソースポリシー。名前 デフォルトのポリシーを指定します。
    デフォルトコンテナリソースポリシー = "*"  
 ）
 // ContainerResourcePolicyは、オートスケーラーが推奨値を計算する方法を制御します。
 //特定のコンテナのリソース。
 ContainerResourcePolicy構造体型{
    //名前 コンテナまたはDefaultContainerResourcePolicyの​​
    //ポリシーが独自のポリシーを持たないコンテナによって使用される場合
    // ポリシーが指定されました。
名前文字列
    //コンテナに対して自動スケーラーが有効になっているかどうか。デフォルトは  "の上" 。
    // +オプション
    モード ContainerScalingMode
    //推奨されるリソースの最小量を指定します
    //コンテナ用。
    // +オプション
    最小許可 api.ResourceRequirements
    //推奨されるリソースの最大量を指定します
    //コンテナ用。
    // +オプション
    最大許容値 api.ResourceRequirements
 } 
 
 // PodResourcePolicy はオートスケーラーが推奨リソースを計算する方法を制御します
//ポッドに属するコンテナの場合。
 PodResourcePolicy構造体型{
    // コンテナごとのリソース ポリシー。
    コンテナポリシー []コンテナリソースポリシー
} 
 
 // ContainerScalingMode は、特定のコンテナに対して自動スケーラーを有効にするかどうかを制御します。
 // 容器。
 ContainerScalingMode 文字列型
定数(
    // ContainerScalingModeOn は、コンテナの自動スケーリングが有効になっていることを意味します。
    ContainerScalingModeOn ContainerScalingMode = "オン"  
    // ContainerScalingModeOff は、コンテナの自動スケーリングが無効になっていることを意味します。
    ContainerScalingModeOff ContainerScalingMode = "オフ"  
 ）

おすすめ

VPA リソースには、Recommender によって生成された最新の推奨事項を保持する出力専用フィールドがあります。このフィールドは、レコメンダーが一時的に利用できない場合に最新の推奨事項を取得するために使用できます。この推奨事項には、推奨されるターゲット リソースの量と範囲 (最大、最小) が含まれており、Updater はこれを使用して、Pod をいつ更新するかを決定できます。リソースが不足した場合、Updater は Pod リソースを推奨される最小限まで削減することを決定する場合があります。範囲の幅も推奨される信頼区間に影響します。

 // RecommendedPodResourcesは、計算されたリソースの推奨値です。  
 // オートスケーラー。
タイプ RecommendedPodResources 構造体 {
    //各コンテナに対してオートスケーラーによって推奨されるリソース。
    コンテナの推奨事項 []推奨コンテナリソース
} 
 
 // RecommendedContainerResourcesは、計算されたリソースの推奨値です。  
 //特定のコンテナの自動スケーラー。コンテナリソースポリシーを尊重する
//仕様に存在する場合。
タイプ RecommendedContainerResources 構造体 {
    //名前 コンテナの。
名前文字列
    // 推奨されるリソースの量。
    ターゲット api.ResourceRequirements
    // 推奨されるリソースの最小量。
    //少ないリソースでアプリケーションを実行すると、
    //パフォーマンス/可用性に大きな影響を与えます。
    // +オプション
    推奨最小値 api.ResourceRequirements
    // 推奨されるリソースの最大量。
    // この値を超えて割り当てられたリソースは無駄になる可能性があります。
    // +オプション
    推奨される最大 api.ResourceRequirements
 }

入場管理者

VPA アドミッション コントローラーは、ポッド作成リクエストをインターセプトします。 Pod が VPA 構成と一致し、モードがオフに設定されていない場合、コントローラーは提案されたリソースを Pod 仕様に適用してリソース要求を書き換えます。それ以外の場合、Pod 仕様は変更されません。

コントローラーは、Recommender の /recommendedPodResources から推奨リソースを取得します。呼び出しがタイムアウトするか失敗した場合、コントローラーは VPA オブジェクトにキャッシュされた提案にフォールバックします。これも利用できない場合は、コントローラはリソース要求を許可して、最初に指定されたリソースを配信します。

注: 将来的には、Pod に VPA が必要であるとマークすることで、VPA の使用を強制することができます (オプション)。これにより、対応する VPA 構成が作成されるまで、Pod のスケジュールが無効になります。一致する VPA 構成が見つからない場合、アドミッション コントローラはそのようなポッドを拒否します。この機能は、VPA 構成を作成して Pod を送信するユーザーにとって非常に便利です。

VPA アドミッション コントローラは、外部アドミッション フックとして実装されます。ただし、これは Webhook アドミッション コントローラーの変更に依存することに注意してください。

推薦者

Recommender は VPA の主要コンポーネントです。推奨リソースを計算する役割を担います。起動時に、Recommender はすべての Pod (VPA を使用しているかどうかに関係なく) の履歴リソース使用率と、履歴ストア内の Pod OOM イベントの履歴を取得します。このデータを集約し、メモリに保存します。

通常の操作中、Recommender は Metrics API を介して Metrics Server からリソース使用率と新しいイベントに関するリアルタイムの更新を取得します。さらに、クラスター内のすべてのポッドとすべての VPA オブジェクトを監視します。何らかの VPA セレクターに一致する各ポッドについて、Recommender は推奨リソースを計算し、VPA オブジェクトに推奨事項を設定します。

各 VPA オブジェクトには推奨事項があることを認識することが非常に重要です。ユーザーは、VPA を使用して、同様のリソース使用パターンを持つポッド (通常は単一のワークロードのレプリカまたはシャードのグループ) を制御する必要があります。

Recommender は拡張 API サーバーとして機能し、Podspec と Pod メタデータを取得して推奨リソースを返す同期メソッドを公開します。

レコメンダー API

リクエスト本文: 
 
 「行く」
 // RecommendationQuery はポッドのリソース推奨事項を取得します。
タイプRecommendationQuery構造体{
    metav1.TypeMeta
    // +オプション
    metav1.オブジェクトメタ
 
    // 仕様が入力されました 発信者が推薦を依頼する。
    仕様の推奨事項クエリ仕様
 
    // ステータスが入力されます 推奨されるポッドリソースを持つサーバーによって。
    // +オプション
    ステータス 推奨事項 クエリ ステータス
} 
 
 // RecommendationQuerySpec はポッドの推奨のリクエストです。
タイプRecommendationQuerySpec構造体{
    //推奨を計算するポッド。存在する必要はありません。
    ポッドコア.ポッド
} 
 
 // RecommendationQueryStatus は推奨リクエストへの応答です。
タイプRecommendationQueryStatus{
    // Recommendation にはポッドに推奨されるリソースが保持されます。
    // +オプション
    推奨オートスケーラー。推奨ポッドリソース
    // エラーは推奨事項が利用できなかったことを示します。どちらか
    // 推奨事項またはエラーが存在する必要があります。
    // +オプション
    エラー文字列
}

この API は、既存の Pod だけでなく、まだ作成されていない Pod からも呼び出すことができることに注意してください。

アップデータ

VPA Updater は、既存の Pod に推奨リソースを適用するコンポーネントです。クラスター内のすべての VPA オブジェクトと Pod を監視し、Recommender API を呼び出して、VPA によって制御される Pod の推奨事項を定期的に取得します。推奨されるリソースが実際に構成されたリソースと大幅に異なる場合、Updater は Pod を更新することを決定する場合があります。 MVP では (Pod リソースのインプレース アップグレードが利用可能になるまで)、これは既存の Pod を削除し、推奨リソースを使用して再作成することを意味します。

Updater は、レプリカ セットなどの他のメカニズムに依存して、削除された Pod を再作成します。ただし、そのようなメカニズムが実際に Pod に設定されているかどうかは確認されません。このようなチェックは CLI に実装でき、VPA が Pod と一致する場合にユーザーに警告しますが、Pod は自動的に再起動されません。

Pod を終了することは混乱を招き、一般的には望ましくありませんが、次のような場合には合理的な場合もあります。

• CPU 不足を回避します。
• 複数のポッド間で相関する OOM のリスクをランダムに軽減します。
• 長期的にリソースを節約します。

Updater は、updatePolicy.mod が Auto に設定されている場合にのみ Pod を構成します。

クラスターの現在の状態 (割り当て、ノードで使用可能なスペース、その他のスケジュール制約など) に応じて、Updater は推奨事項をポッドに適用する前に調整する方法も理解する必要があります。そうしないと、ポッドが永久にキャンセルされる可能性があります。そのようなメカニズムはまだ設計されていません。

推奨モデル

VPA はコンテナのリソース要求 (メモリと CPU) を制御します。 MVP では、リソース制限は常に無限に設定されます。 VPA を使用してリソース制限を設定するユースケースがあるかどうかは明らかではありません。

リソース要求は、コンテナーの現在の実行と以前の実行、および同様の属性 (名前、イメージ、コマンド、引数) を持つ他のコンテナーの分析に基づいて計算されます。推奨モデル (MVP) では、メモリと CPU の消費量が、過去 N 日間に観測されたものと等しい分布を持つ独立したランダム変数であると想定しています (週ごとのピークを捕捉するには、N の推奨値は N = 8 です)。将来的には、より高度なモデルが、傾向、周期性、その他の時間関連のパターンを検出しようとするかもしれません。

CPU の場合、目標は、コンテナによって使用される CPU が、コンテナの要求された CPU リソースを高い割合 (95% など) で超過し、特定のしきい値を下回ること (コンテナの CPU 使用率が要求された CPU リソースの 95% を超える時間が 1% のみであることなど) を保証することです。このモデルでは、「CPU 使用率」は短い時間間隔で測定された平均値として定義されます。測定間隔が短いほど、スパイクが多くレイテンシの影響を受けやすいワークロードに対する推奨事項の品質が向上します。最小の適切な間隔は 1 分あたり 1 回であり、1 秒あたり 1 回が推奨されます。

メモリの場合、目標は、特定の時間枠内でコンテナによって使用されるメモリがコンテナによって要求されたメモリ リソースを超える確率を、特定のしきい値未満 (たとえば、24 時間以内に 1% 未満) に保つことです。 OOM によるエビクションがサービス アプリケーションの可用性とバッチ計算の進行に大きな影響を与えないようにするには、ウィンドウを長く (24 時間以上) する必要があります (より高度なモデルでは、ユーザーが SLO を指定してこれを制御できます)。

OOMの処理

使用可能なメモリを超えたためにコンテナが削除された場合、実際のメモリ要件は不明です (消費量によって下限が明らかに決まります)。これは、最後に観測された使用量に「安全マージン」乗数を適用して、OOM イベントを人工的なメモリ使用量サンプルに変換することによってモデル化されます。

履歴ストレージ

VPA は、履歴イベントおよびリソース使用率のプロバイダー向けのデータ アクセス API を定義します。当初は、少なくともリソース使用率の部分については、この API のリファレンス実装として Prometheus を使用し、履歴イベントは Infrastore などの別のソリューションでバックアップできます。ユーザーは独自の実装をプラグインできるようになります。

履歴ストレージには、Recommender と同様に、リアルタイムで更新されたリソース使用率とイベントが継続的に入力されます。少なくとも 8 日間のデータが保持されます。このデータは、起動時にレコメンダーを初期化するためにのみ使用されます。

未解決の質問

複数の VPA オブジェクトが Pod と一致する場合、競合がどのように解決されるか。

特定のコンテナに適用する前に、クラスターの現在の状態 (クォータ、ノードで使用可能なスペース、その他のスケジュール制約など) に基づいて推奨事項を調整する方法。

今後の仕事

Pod の起動時に VPA を統合する

現在の提案では、ポッドのアドミッション時間内にポッドに一致する VPA 構成がない場合、ポッドは元々構成されたリソースを使用してスケジュールされます。これはユーザーが望む動作ではない可能性があります。特に、ユーザーは VPA 構成を作成し、それを同時に Pod に送信したい場合があります。これにより競合状態が発生する可能性があります。結果は、どのリソース (VPA または Pod) が最初に処理されるかによって異なります。

この問題に対処するために、Pod に特別な注釈 (VPA が必要) を付けてマークし、対応する VPA が利用できない場合はアドミッション コントローラーが Pod を許可しないようにすることを提案します。

もう 1 つのアプローチは、同じ目的を果たす VPA 初期化子を導入することです。

垂直スケーリングと水平スケーリングを組み合わせる

原則として、2 つのメカニズムが異なるリソースで動作する限り、単一のワークロード (Pod のグループ) に対して垂直スケーリングと水平スケーリングの両方を使用できます。正しいアプローチは、ボトルネック リソースに基づいて HPA がグループをスケーリングするようにすることです。 VPA は他のリソースを制御できます。例：

• CPU にバインドされたワークロードは、CPU 使用率に基づいて水平方向にスケーリングし、垂直スケーリングを使用してメモリを調整できます。
• IO バウンドのワークロードは、IO スループットに基づいて水平方向にスケーリングでき、垂直スケーリングを使用してメモリと CPU を調整できます。

ただし、これはより高度な形式の自動スケーリングであり、Vertical Pod Autoscaler の MVP バージョンでは十分にサポートされていません。実装の難しさは、インスタンス数の変更がボトルネック リソースの使用率に影響するだけでなく (これが水平拡張の原則です)、VPA によって制御される非ボトルネック リソースにも影響する可能性があることです。履歴リソース使用率を集計して推奨事項を生成するときに、VPA モデルを HPA と組み合わせるには、グループのサイズを考慮して VPA モデルを拡張する必要があります。

バッチワークロード

バッチ ワークロードには、レイテンシの影響を受けやすいワークロードとは異なる CPU 要件があります。要求のレイテンシではなくスループットを重視します。つまり、VPA は CPU 配分の高いパーセンタイルではなく、平均 CPU 消費量に基づいて CPU 要求を決定する必要があります。

TODO: バッチ ワークロードの推奨モデルと、VPA がバッチとサービングを区別する方法を説明します。 1 つの可能なアプローチは、PodSpec.restartPolicy を確認することです。もう 1 つのアプローチは、ユーザーが PodResourcePolicy でワークロードのレイテンシ要件を指定できるようにすることです。