2.5. Vertical Pod Autoscaler を使用した Pod リソースレベルの自動調整
OpenShift Container Platform Vertical Pod Autoscaler Operator (VPA) は、Pod 内のコンテナーにおける CPU およびメモリーリソースの履歴と現在の情報を自動的に確認します。VPA は、学習した使用状況の値に基づいて、リソースの制限と要求を更新できます。個別のカスタムリソース (CR) を使用することで、VPA は組み込みのワークロードオブジェクトに関連付けられているプロジェクト内のすべての Pod を更新します。これには、次のオブジェクトタイプのリストが含まれます。
-
Deployment
-
DeploymentConfig
-
StatefulSet
-
ジョブ
-
DaemonSet
-
ReplicaSet
-
ReplicationController
VPA は、Pod を管理する特定のカスタムリソースオブジェクトを更新することもできます。詳細は、Vertical Pod Autoscaler のカスタムリソースの例 を参照してください。
VPA は、Pod に最適な CPU およびメモリーの使用状況を理解するのに役立ち、Pod のライフサイクルを通じて Pod のリソースを自動的に維持します。
2.5.1. Vertical Pod Autoscaler Operator について リンクのコピーリンクがクリップボードにコピーされました!
Vertical Pod Autoscaler Operator (VPA) は、API リソースおよびカスタムリソース (CR) として実装されます。CR は、プロジェクト内のデーモンセット、レプリケーションコントローラーなどの特定のワークロードオブジェクトに関連付けられた Pod に対して VPA が実行するアクションを決定します。
VPA は 3 つのコンポーネントで構成され、各コンポーネントは VPA namespace に独自の Pod を持ちます。
- レコメンダー
- VPA レコメンダーは、現在のリソース消費量と過去のリソース消費量を監視します。このデータに基づいて、VPA レコメンダーは、関連付けられたワークロードオブジェクト内の Pod に最適な CPU およびメモリーリソースを決定します。
- アップデーター
- VPA アップデーターは、関連付けられたワークロードオブジェクト内の Pod に正しいリソースがあるか確認します。リソースが正しい場合、アップデーターは何も行いません。リソースが正しくない場合、アップデーターは Pod を強制終了し、Pod のコントローラーが更新されたリクエストでリソースを再作成できるようにします。
- アドミッションコントローラー
- VPA アドミッションコントローラーは、関連付けられたワークロードオブジェクト内の各新しい Pod に正しいリソース要求を設定します。これは、Pod が新規であるか、または VPA アップデーターアクションによりコントローラーが Pod を再作成したかに関係なく適用されます。
デフォルトのレコメンダーを使用することも、独自の代替レコメンダーを使用して独自のアルゴリズムに基づいて自動スケーリングを実行することもできます。
デフォルトのレコメンダーは、これらの Pod 内のコンテナーの CPU とメモリーの過去および現在の使用状況を自動的に計算します。デフォルトのレコメンダーはこのデータを使用して、最適化されたリソース制限とリクエストを決定し、これらの Pod が常に効率的に動作するようにします。たとえば、デフォルトレコメンダーは使用している量よりも多くのリソースを要求する Pod のリソースを減らし、十分なリソースを要求していない Pod のリソースを増やします。
VPA は、一度に 1 つずつ、これらの推奨値で調整されていない Pod を自動的に削除するため、アプリケーションはダウンタイムなしに継続して要求を提供できます。その後、ワークロードオブジェクトが、元のリソース制限および要求を使用して Pod を再デプロイします。VPA は変更用のアドミッション Webhook を使用して、Pod がノードに許可される前に最適化されたリソース制限および要求で Pod を更新します。VPA が Pod を削除する必要がない場合は、VPA リソース制限および要求を表示し、必要に応じて Pod を手動で更新できます。
デフォルトで、ワークロードオブジェクトは、VPA が Pod を自動的に削除できるようにするためにレプリカを 2 つ以上指定する必要があります。この最小値よりも少ないレプリカを指定するワークロードオブジェクトは削除されません。これらの Pod を手動で削除すると、ワークロードオブジェクトが Pod を再デプロイするときに、VPA は推奨内容に基づいて新規 Pod を更新します。この最小値は、VPA の最小値の変更 に記載されているとおり、VerticalPodAutoscalerController
オブジェクトを変更して変更できます。
たとえば、CPU の 50% を使用する Pod が 10% しか要求しない場合、VPA は Pod が要求よりも多くの CPU を消費すると判別してその Pod を削除します。レプリカセットなどのワークロードオブジェクトは Pod を再起動し、VPA は推奨リソースで新しい Pod を更新します。
開発者は VPA を使用して、各 Pod に適切なリソースを持つノードに Pod をスケジューリングすることにより、需要が高い期間に Pod がアクティブであることを確認できます。
管理者は VPA を使用して、クラスターリソースをより適切に活用できます。たとえば、必要以上の CPU リソースを Pod が予約できないようにします。VPA は、ワークロードが実際に使用しているリソースをモニターし、他のワークロードで容量を使用できるようにリソース要件を調整します。VPA は、初期のコンテナー設定で指定された制限と要求の比率も維持します。
VPA の実行を停止するか、クラスターの特定の VPA CR を削除する場合、VPA によってすでに変更された Pod のリソース要求は変更されません。ただし、新しい Pod は、VPA による以前の推奨内容ではなく、ワークロードオブジェクトで定義されたリソースを取得します。
2.5.2. Vertical Pod Autoscaler Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して Vertical Pod Autoscaler Operator (VPA) をインストールすることができます。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub をクリックします。 - 利用可能な Operator のリストから VerticalPodAutoscaler を選択し、Install をクリックします。
-
Install Operator ページで、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の
openshift-vertical-pod-autoscaler
namespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。 - Install をクリックします。
検証
VPA コンポーネントをリスト表示してインストールを確認します。
-
Workloads
Pods に移動します。 -
ドロップダウンメニューから
openshift-vertical-pod-autoscaler
プロジェクトを選択し、4 つの Pod が実行されていることを確認します。 -
Workloads
Deployments に移動し、4 つのデプロイメントが実行されていることを確認します。
-
Workloads
オプション: 以下のコマンドを使用して、OpenShift Container Platform CLI でインストールを確認します。
oc get all -n openshift-vertical-pod-autoscaler
$ oc get all -n openshift-vertical-pod-autoscaler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、4 つの Pod と 4 つのデプロイメントが表示されます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3. Vertical Pod Autoscaler Operator コンポーネントの移動 リンクのコピーリンクがクリップボードにコピーされました!
Vertical Pod Autoscaler Operator (VPA) と各コンポーネントには、コントロールプレーンノードの VPA namespace に独自の Pod があります。VPA Operator およびコンポーネント Pod は、ノードセレクターを VPA サブスクリプションおよび VerticalPodAutoscalerController
CR に追加してインフラストラクチャーまたはワーカーノードに移動できます。
インフラストラクチャーノードを作成して使用し、インフラストラクチャーコンポーネントのみをホストできます。たとえば、デフォルトルーター、統合コンテナーイメージレジストリー、クラスターメトリクスとモニタリングのコンポーネントなどです。これらのインフラストラクチャーノードは、環境の実行に必要なサブスクリプションの合計数にカウントされません。詳細は、インフラストラクチャーマシンセットの作成 を参照してください。
組織の状況に応じて、コンポーネントを同じノードまたは別のノードに移動できます。
以下の例は、VPA Pod のコントロールプレーンノードへのデフォルトのデプロイメントを示しています。
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-master-1 <none> <none> vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-master-1 <none> <none> vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-master-0 <none> <none> vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-master-1 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-master-1 <none> <none>
vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-master-1 <none> <none>
vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-master-0 <none> <none>
vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-master-1 <none> <none>
手順
VPA Operator の
サブスクリプション
カスタムリソース (CR) にノードセレクターを追加して、VPA Operator Pod を移動します。CR を編集します。
oc edit Subscription vertical-pod-autoscaler -n openshift-vertical-pod-autoscaler
$ oc edit Subscription vertical-pod-autoscaler -n openshift-vertical-pod-autoscaler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VPA Operator Pod をインストールするノードのノードロールラベルと一致するノードセレクターを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記infra ノードが taint を使用する場合は、toleration を
Subscription
CR に追加する必要があります。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VPA Operator Pod を移動するノード上の taint の toleration を指定します。
VerticalPodAutoscaler
カスタムリソース (CR) にノードセレクターを追加して、各 VPA コンポーネントを移動します。CR を編集します。
oc edit VerticalPodAutoscalerController default -n openshift-vertical-pod-autoscaler
$ oc edit VerticalPodAutoscalerController default -n openshift-vertical-pod-autoscaler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VPA コンポーネントをインストールするノード上のノードロールラベルと一致するようにノードセレクターを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ターゲットノードが taint を使用する場合は、
VerticalPodAutoscalerController
CR に toleration を追加する必要があります。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを使用して、Pod が移動したことを確認できます。
oc get pods -n openshift-vertical-pod-autoscaler -o wide
$ oc get pods -n openshift-vertical-pod-autoscaler -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod はコントロールプレーンノードにデプロイされなくなりました。次の出力例では、ノードはコントロールプレーンノードではなく、インフラノードになっています。
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-infra-eastus3-2bndt <none> <none> vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-infra-eastus1-lrgj8 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z 1/1 Running 0 7m59s 10.128.2.24 c416-tfsbj-infra-eastus3-2bndt <none> <none> vpa-admission-plugin-default-6cb78d6f8b-rpcrj 1/1 Running 0 5m37s 10.129.2.22 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-recommender-default-66846bd94c-dsmpp 1/1 Running 0 5m37s 10.129.2.20 c416-tfsbj-infra-eastus1-lrgj8 <none> <none> vpa-updater-default-db8b58df-2nkvf 1/1 Running 0 5m37s 10.129.2.21 c416-tfsbj-infra-eastus1-lrgj8 <none> <none>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
2.5.4. Vertical Pod Autoscaler Operator の使用について リンクのコピーリンクがクリップボードにコピーされました!
Vertical Pod Autoscaler Operator (VPA) を使用するには、クラスター内にワークロードオブジェクトの VPA カスタムリソース (CR) を作成します。VPA は、そのワークロードオブジェクトに関連付けられた Pod に最適な CPU およびメモリーリソースを確認し、適用します。VPA は、デプロイメント、ステートフルセット、ジョブ、デーモンセット、レプリカセット、またはレプリケーションコントローラーのワークロードオブジェクトと共に使用できます。VPA CR は、チェックする Pod と同じプロジェクト内にある必要があります。
VPA CR を使用してワークロードオブジェクトを関連付け、VPA が動作するモードを指定します。
-
Auto
およびRecreate
モードは、Pod の有効期間中は VPA CPU およびメモリーの推奨事項を自動的に適用します。VPA は、推奨値で調整されていないプロジェクトの Pod を削除します。ワークロードオブジェクトによって再デプロイされる場合、VPA はその推奨値で新規 Pod を更新します。 -
Initial
モードは、Pod の作成時にのみ VPA の推奨値を自動的に適用します。 -
Off
モードでは、推奨されるリソース制限と要求のみが提供されます。その後、推奨値を手動で適用できます。Off
モードは Pod を更新しません。
CR を使用して、VPA 評価および更新から特定のコンテナーをオプトアウトすることもできます。
たとえば、Pod には以下の制限および要求があります。
Auto
に設定された VPA を作成すると、VPA はリソースの使用状況を確認して Pod を削除します。再デプロイ時に、Pod は新規のリソース制限および要求を使用します。
次のコマンドを使用して、VPA の推奨値を表示できます。
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml
数分後に、出力には、以下のような CPU およびメモリー要求の推奨値が表示されます。
出力例
出力には、target
(推奨リソース)、lowerBound
(最小推奨リソース)、upperBound
(最大推奨リソース)、および uncappedTarget
(最新の推奨リソース) が表示されます。
VPA は lowerBound
および upperBound
の値を使用して、Pod の更新が必要か判別します。Pod のリソース要求が lowerBound
値より少ないか upperBound
値より大きい場合、VPA は Pod を終了し、target
値で Pod を再作成します。
2.5.4.1. VPA の最小値の変更 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、ワークロードオブジェクトは、VPA が Pod を自動的に削除し、更新できるようにするためにレプリカを 2 つ以上指定する必要があります。そのため、2 つ未満を指定するワークロードオブジェクトの場合 VPA は自動的に機能しません。VPA 外部のプロセスによって Pod が再起動された場合、VPA はこれらのワークロードオブジェクトから新しい Pod を更新します。このクラスター全体の最小値の変更は、VerticalPodAutoscalerController
カスタムリソース (CR) の minReplicas
パラメーターを変更して実行できます。
たとえば、minReplicas
を 3
に設定する場合、VPA は 2 レプリカ以下のレプリカを指定するワークロードオブジェクトの Pod を削除せず、更新しません。
minReplicas
を 1
に設定する場合、VPA は 1 つのレプリカのみを指定するワークロードオブジェクトの Pod のみを削除できます。VPA が Pod を削除してリソースを調整するたびに、ワークロードがダウンタイムを許容できる場合にのみ、1 つのレプリカオブジェクトでこの設定を使用します。1 つのレプリカオブジェクトで不要なダウンタイムを回避するには、podUpdatePolicy
を Initial
に設定して VPA CR を設定します。これにより、VPA 外部のプロセスが再起動した場合にのみ Pod が自動的に更新されます。または、Off
に設定すると、アプリケーションの適切なタイミングで Pod を手動で更新できます。
VerticalPodAutoscalerController
オブジェクトの例
- 1
- 動作させる VPA のワークロードオブジェクトのレプリカの最小数を指定します。最低数に満たない数のレプリカを持つオブジェクトは、VPA によって自動的に削除されません。
2.5.4.2. VPA の推奨事項の自動適用 リンクのコピーリンクがクリップボードにコピーされました!
VPA を使用して Pod を自動的に更新するには、updateMode
が Auto
または Recreate
に設定された特定のワークロードオブジェクトの VPA CR を作成します。
Pod がワークロードオブジェクト用に作成されると、VPA はコンテナーを継続的にモニターして、CPU およびメモリーのニーズを分析します。VPA は、CPU およびメモリーに関する VPA の推奨値を満たさない Pod を削除します。再デプロイ時に、Pod は VPA の推奨値に基づいて新規のリソース制限および要求を使用し、アプリケーションに設定された Pod の Disruption Budget (停止状態の予算) を反映します。この推奨事項は、参照用に VPA CR の status
フィールドに追加されます。
デフォルトで、ワークロードオブジェクトは、VPA が Pod を自動的に削除できるようにするためにレプリカを 2 つ以上指定する必要があります。この最小値よりも少ないレプリカを指定するワークロードオブジェクトは削除されません。これらの Pod を手動で削除すると、ワークロードオブジェクトが Pod を再デプロイします。VPA は推奨内容に基づいて新規 Pod を更新します。この最小値は、VPA の最小値の変更 に記載されているとおり、VerticalPodAutoscalerController
オブジェクトを変更して変更できます。
Auto
モードの VPA CR の例
- 1
- この VPA CR が管理するワークロードオブジェクトのタイプ。
- 2
- この VPA CR が管理するワークロードオブジェクトの名前。
- 3
- モードを
Auto
またはRecreate
に設定します。-
Auto
:VPA は、Pod の作成時にリソース要求を割り当て、要求されるリソースが新規の推奨事項と大きく異なる場合に、それらを終了して既存の Pod を更新します。 -
Recreate
:VPA は、Pod の作成時にリソース要求を割り当て、要求されるリソースが新規の推奨事項と大きく異なる場合に、それらを終了して既存の Pod を更新します。このモードが使用されることはほとんどありません。リソース要求の変更に応じて Pod を必ず再起動させたい場合に限定して使用します。
-
VPA によってリソースの推奨事項を決定し、推奨リソースを新しい Pod に適用するには、動作中の Pod がプロジェクト内に存在し、実行されている必要があります。
CPU やメモリーなどのワークロードのリソース使用量が安定している場合、VPA はリソースの推奨事項を数分で決定できます。ワークロードのリソース使用量が安定していない場合、VPA は正確な推奨を行うために、さまざまなリソース使用量の間隔でメトリクスを収集する必要があります。
2.5.4.3. Pod 作成時における VPA 推奨の自動適用 リンクのコピーリンクがクリップボードにコピーされました!
VPA を使用して、Pod が最初にデプロイされる場合にのみ推奨リソースを適用するには、updateMode
が Initial
に設定された特定のワークロードオブジェクトの VPA CR を作成します。
次に、VPA の推奨値を使用する必要のあるワークロードオブジェクトに関連付けられた Pod を手動で削除します。Initial
モードで、VPA は新しいリソースの推奨内容を確認する際に Pod を削除したり、更新したりしません。
Initial
モードの VPA CR の例
VPA によって推奨リソースを決定し、推奨事項を新しい Pod に適用するには、動作中の Pod がプロジェクト内に存在し、実行されている必要があります。
VPA から最も正確な推奨事項を取得するには、Pod が実行され、VPA が安定するまで少なくとも 8 日間待機してください。
2.5.4.4. VPA の推奨事項の手動適用 リンクのコピーリンクがクリップボードにコピーされました!
CPU およびメモリーの推奨値を判別するためだけに VPA を使用するには、updateMode
を Off
に設定した特定のワークロードオブジェクトの VPA CR を作成します。
Pod がワークロードオブジェクト用に作成されると、VPA はコンテナーの CPU およびメモリーのニーズを分析し、VPA CR の status
フィールドにそれらの推奨事項を記録します。VPA は、新しい推奨リソースを判別する際に Pod を更新しません。
Off
モードの VPA CR の例
以下のコマンドを使用して、推奨事項を表示できます。
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml
この推奨事項により、ワークロードオブジェクトを編集して CPU およびメモリー要求を追加し、推奨リソースを使用して Pod を削除および再デプロイできます。
VPA によって推奨リソースを決定し、推奨事項を新しい Pod に適用するには、動作中の Pod がプロジェクト内に存在し、実行されている必要があります。
VPA から最も正確な推奨事項を取得するには、Pod が実行され、VPA が安定するまで少なくとも 8 日間待機してください。
2.5.4.5. VPA の推奨事項をすべてのコンテナーに適用しないようにする リンクのコピーリンクがクリップボードにコピーされました!
ワークロードオブジェクトに複数のコンテナーがあり、VPA がすべてのコンテナーを評価および実行対象としないようにするには、特定のワークロードオブジェクトの VPA CR を作成し、resourcePolicy
を追加して特定のコンテナーをオプトアウトします。
VPA が推奨リソースで Pod を更新すると、resourcePolicy
が設定されたコンテナーは更新されず、VPA は Pod 内のそれらのコンテナーの推奨事項を提示しません。
たとえば、Pod には同じリソース要求および制限の 2 つのコンテナーがあります。
backend
コンテナーがオプトアウトに設定された VPA CR を起動した後、VPA は Pod を終了し、frontend
コンテナーのみに適用される推奨リソースで Pod を再作成します。
2.5.4.6. VPA Operator のパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Vertical Pod Autoscaler Operator (VPA) のパフォーマンスを調整して、VPA が Kubernetes API サーバーにリクエストを行うレートを制限したり、VPA レコメンダー、アップデーター、アドミッションコントローラーコンポーネントの Pod の CPU とメモリーリソースを指定したりできます。
VPA カスタムリソース (CR) が管理するワークロードのみを監視するように VPA を設定することもできます。デフォルトでは、VPA はクラスター内のすべてのワークロードを監視します。その結果、VPA はすべてのワークロードの 8 日間の履歴データを蓄積して保存します。ワークロードに対して新しい VPA CR が作成された場合、VPA でこれを使用できます。ただし、これにより VPA は大量の CPU とメモリーを使用することになります。これにより、特に大規模なクラスターでは VPA が失敗する可能性があります。VPA CR を使用してワークロードのみを監視するように VPA を設定すると、CPU とメモリーのリソースを節約できます。トレードオフの 1 つは、実行中のワークロードがあり、そのワークロードを管理するために VPA CR を作成する場合です。VPA にはそのワークロードの履歴データがありません。そのため、最初の推奨値は、ワークロードがしばらく実行された後の推奨値ほど有用ではありません。
これらのチューニングを使用して、VPA が最高の効率で動作するために十分なリソースを確保し、スロットルや Pod の承認の遅延を防止します。
VerticalPodAutoscalerController
カスタムリソース (CR) を編集することで、VPA コンポーネントに対して以下のチューニングを行えます。
-
スロットル調整と Pod アドミッションの遅延を防ぐには、
kube-api-qps
パラメーターとkube-api-burst
パラメーターを使用して、Kubernetes API サーバーの VPA リクエストの 1 秒あたりのクエリー数 (QPS) とバーストレートを設定します。 -
十分な CPU とメモリーを確保するには、標準の
cpu
およびmemory
リソース要求を使用して、VPA コンポーネント Pod の CPU 要求とメモリー要求を設定します。 -
VPA CR が管理するワークロードのみを監視するように VPA を設定するには、レコメンデーションコンポーネントの
memory-saver
パラメーターをtrue
に設定します。
各 VPA コンポーネントに設定できるリソースおよびレート制限のガイドラインについて、次の表では、クラスターや他の要素のサイズに応じて、推奨のベースライン値を紹介しています。
これらの推奨値は、Red Hat の内部テストに基づいて算出されたものであり、必ずしも実際のクラスターを代表するものではありません。実稼働クラスターを設定する前に、実稼働以外のクラスターでこれらの値をテストしてください。
コンポーネント | 1-500 containers | 500-1,000 containers | 1,000-2,000 containers | 2,000-4,000 containers | 4,000+ containers | |||||
---|---|---|---|---|---|---|---|---|---|---|
CPU | メモリー | CPU | メモリー | CPU | メモリー | CPU | メモリー | CPU | メモリー | |
受付 | 25m | 50 Mi | 25m | 75Mi | 40m | 150Mi | 75m | 260 Mi | (0.03c)/2 + 10 [1] | (0.1c)/2 + 50 [1] |
レコメンダー | 25m | 100Mi | 50 m | 160Mi | 75m | 275Mi | 120M | 420Mi | (0.05c)/2 + 50 [1] | (0.15c)/2 + 120 [1] |
アップデーター | 25m | 100Mi | 50 m | 220Mi | 80 m | 350Mi | 150 m | 500 Mi | (0.07c)/2 + 20 [1] | (0.15c)/2 + 200 [1] |
-
c
は、クラスター内のコンテナーの数です。
コンテナーのメモリー制限を、テーブルで推奨されるリクエストの少なくとも 2 倍に設定することを推奨します。ただし、CPU は圧縮可能なリソースであるため、コンテナーの CPU 制限を設定すると VPA をスロットリングできます。そのため、コンテナーに CPU 制限を設定しないことが推奨されます。
コンポーネント | 1-150 VPAs | 151-500 VPAs | 501-2,000 VPAs | 2,001-4,000 VPAs | ||||
---|---|---|---|---|---|---|---|---|
QPS 制限 [1] | Burst [2] | QPS 制限 | Burst | QPS 制限 | Burst | QPS 制限 | Burst | |
レコメンダー | 5 | 10 | 30 | 60 | 60 | 120 | 120 | 240 |
アップデーター | 5 | 10 | 30 | 60 | 60 | 120 | 120 | 240 |
-
QPS は、Kubernetes API サーバーにリクエストを行う際の 1 秒あたりのクエリー数 (QPS) の制限を指定します。アップデーターおよびレコメンダー Pod のデフォルトは
5.0
です。 -
Burst は、Kubernetes API サーバーにリクエストを行う際のバースト制限を指定します。アップデーターおよびレコメンダー Pod のデフォルトは
10.0
です。
クラスターに 4,000 を超える VPAs がある場合は、テーブルの値でパフォーマンスチューニングを開始し、必要なレコメンダー、更新レイテンシーおよびパフォーマンスを達成するまで値を徐々に増やすことを推奨します。QPS および Burst の増加により、VPA コンポーネントから API サーバーに送信される API 要求が多すぎると、クラスターの健全性に影響し、Kubernetes API サーバーの速度が遅くなる可能性があるため、これらの値は徐々に調整します。
以下の VPA コントローラー CR の例は、1,000 から 2,000 コンテナーを持つクラスター用であり、Pod の作成サージは 26 から 50 になります。CR は以下の値を設定します。
- 3 つの VPA コンポーネントすべてに対するコンテナーメモリーおよび CPU 要求
- 3 つの VPA コンポーネントすべてに対するコンテナーのメモリー制限
- 3 つの VPA コンポーネントすべてに対する QPS およびバーストレート
-
VPA レコメンダーコンポーネントの
memory-saver
パラメーターをtrue
に設定
VerticalPodAutoscalerController
CR の例
- 1
- VPA アドミッションコントローラーのチューニングパラメーターを指定します。
- 2
- VPA アドミッションコントローラーの API QPS とバーストレートを指定します。
-
kube-api-qps
: Kubernetes API サーバーにリクエストを行うときの 1 秒あたりのクエリー数 (QPS) 制限を指定します。デフォルトは5.0
です。 -
kube-api-burst
: Kubernetes API サーバーにリクエストを行うときのバースト制限を指定します。デフォルトは10.0
です。
-
- 3
- VPA アドミッションコントローラー Pod のリソース要求および制限を指定します。
- 4
- VPA レコメンダーのチューニングパラメーターを指定します。
- 5
- VPA Operator が VPA CR を持つワークロードのみを監視するように指定します。デフォルトは
false
です。 - 6
- VPA アップデーターのチューニングパラメーターを指定します。
設定が各 VPA コンポーネント Pod に適用されたことを確認できます。
アップデーター Pod の例
アドミッションコントローラー Pod の例
レコメンダー Pod の例
2.5.4.7. OOM イベント後のカスタムのメモリー増加量 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで OOM (メモリー不足) イベントが発生した場合、Vertical Pod Autoscaler Operator (VPA) はメモリーの推奨値を増やします。この推奨値は、OOM イベントの発生時に観測されたメモリー消費量と、将来的なメモリー不足によるクラッシュを防ぐために指定された乗数に基づいています。
推奨値は、OOM イベント発生時に Pod によって使用されていたメモリー使用量に指定バイト数または指定パーセンテージを掛けて算出される値のうち、どちらか大きい方です。計算は次の式で表されます。
recommendation = max(memory-usage-in-oom-event + oom-min-bump-up-bytes, memory-usage-in-oom-event * oom-bump-up-ratio)
recommendation = max(memory-usage-in-oom-event + oom-min-bump-up-bytes, memory-usage-in-oom-event * oom-bump-up-ratio)
メモリーの増加量は、レコメンダー Pod で次の値を指定して設定できます。
-
oom-min-bump-up-bytes
。この値 (バイト単位) は、OOM イベントが発生した後のメモリーの具体的な増加量です。デフォルトは100MiB
です。 -
oom-bump-up-ratio
。この値は、OOM イベント発生時のメモリーの増加率です。デフォルト値は1.2
です。
たとえば、OOM イベント中の Pod メモリー使用量が 100 MB で、oom-min-bump-up-bytes
が 150 MB に設定され、oom-min-bump-ratio
が 1.2 に設定されている場合。OOM イベントの後、VPA では、その Pod のメモリー要求を 120 MB (100 MB * 1.2) よりも高い 150 MB に増やすことを推奨します。
レコメンダーの Deployment オブジェクトの例
関連情報
2.5.4.8. 代替のレコメンダーを使用する リンクのコピーリンクがクリップボードにコピーされました!
独自のレコメンダーを使用して、独自のアルゴリズムに基づいて自動スケーリングできます。代替レコメンダーを指定しない場合、OpenShift Container Platform はデフォルトのレコメンダーを使用します。これは、過去の使用状況に基づいて CPU およびメモリー要求を提案します。すべてのタイプのワークロードに適用されるユニバーサルレコメンデーションポリシーはないため、特定のワークロードに対して異なるレコメンダーを作成してデプロイメントすることを推奨します。
たとえば、コンテナーが特定のリソース動作を示している場合、デフォルトのレコメンダーは将来のリソース使用量を正確に予測できない可能性があります。例としては、監視アプリケーションで使用される使用量の急増とアイドル状態が交互に繰り返される周期的なパターンや、ディープラーニングアプリケーションで使用される繰り返しパターンなどがあります。これらの使用動作でデフォルトのレコメンダーを使用すると、アプリケーションのプロビジョニングが大幅に過剰になり、Out of Memory (OOM) が強制終了される可能性があります。
レコメンダーを作成する方法については、このドキュメントの範囲外です。
手順
Pod に代替のレコメンダーを使用するには:
代替レコメンダーのサービスアカウントを作成し、そのサービスアカウントを必要なクラスターロールにバインドします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 代替レコメンダーをクラスターに追加するには、次のような
Deployment
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 同じ namespace 内の代替レコメンダー用に新しい Pod が作成されます。
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE frontend-845d5478d-558zf 1/1 Running 0 4m25s frontend-845d5478d-7z9gx 1/1 Running 0 4m25s frontend-845d5478d-b7l4j 1/1 Running 0 4m25s vpa-alt-recommender-55878867f9-6tp5v 1/1 Running 0 9s
NAME READY STATUS RESTARTS AGE frontend-845d5478d-558zf 1/1 Running 0 4m25s frontend-845d5478d-7z9gx 1/1 Running 0 4m25s frontend-845d5478d-b7l4j 1/1 Running 0 4m25s vpa-alt-recommender-55878867f9-6tp5v 1/1 Running 0 9s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 代替レコメンダー
Deployment
オブジェクトの名前を含む Vertical Pod Autoscaler Operator (VPA) カスタムリソース (CR) を設定します。代替レコメンダーを含めるための VPA CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.5. Vertical Pod Autoscaler Operator の使用 リンクのコピーリンクがクリップボードにコピーされました!
VPA カスタムリソース (CR) を作成して、Vertical Pod Autoscaler Operator (VPA) を使用できます。CR は分析する Pod を示し、それらの Pod に対して VPA が実行するアクションを決定します。
VPA を使用して、デプロイメントまたはステートフルセットなどの組み込みリソースや Pod を管理するカスタムリソースをスケーリングできます。詳細は、「Vertical Pod Autoscaler Operator の使用について」を参照してください。
前提条件
- 自動スケーリングするワークロードオブジェクトが存在することを確認します。
- 代替レコメンダーを使用する場合は、そのレコメンダーを含むデプロイメントが存在することを確認してください。
手順
特定のワークロードオブジェクトの VPA CR を作成するには、以下を実行します。
スケーリングするワークロードオブジェクトのプロジェクトの場所に切り替えます。
VPA CR YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この VPA が管理するワークロードオブジェクトのタイプ (
Deployment
、StatefulSet
、Job
、DaemonSet
、ReplicaSet
、またはReplicationController
) を指定します。 - 2
- この VPA が管理する既存のワークロードオブジェクトの名前を指定します。
- 3
- VPA モードを指定します。
-
Auto
は、コントローラーに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。 -
Recreate
は、ワークロードオブジェクトに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。Recreate
モードが使用されることはほとんどありません。リソース要求の変更に応じて Pod を必ず再起動させたい場合に限定して使用します。 -
Initial
は、ワークロードオブジェクトに関連付けられた新しく作成された Pod に推奨リソースを自動的に適用します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。 -
Off
は、ワークロードオブジェクトに関連付けられた Pod の推奨リソースのみを生成します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。また、新規 Pod に推奨事項を適用しません。
-
- 4
- オプション: オプトアウトするコンテナーを指定し、モードを
Off
に設定します。 - 5
- オプション: レコメンダーの推奨者を指定します。
VPA CR を作成します。
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow しばらくすると、VPA はワークロードオブジェクトに関連付けられた Pod 内のコンテナーのリソース使用状況を確認します。
次のコマンドを使用して、VPA の推奨値を表示できます。
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、以下のような CPU およびメモリー要求の推奨事項が表示されます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.5.1. Vertical Pod Autoscaler のカスタムリソースの例 リンクのコピーリンクがクリップボードにコピーされました!
Vertical Pod Autoscaler (VPA) Operator は、デプロイメントまたはステートフルセットなどの組み込みリソースだけでなく、Pod を管理するカスタムリソースも更新できます。
カスタムリソースで VPA を使用するには、CustomResourceDefinition
(CRD) オブジェクトを作成する際に、/scale
サブリソースの labelSelectorPath
フィールドを設定する必要があります。/scale
サブリソースは Scale
オブジェクトを作成します。labelSelectorPath
フィールドは、Scale
オブジェクトおよびカスタムリソースの status.selector
に対応するカスタムリソース内の JSON パスを定義します。以下は、カスタムリソースをターゲットとする VerticalPodAutoscaler
定義と共に、これらの要件を満たす CustomResourceDefinition
および CustomResource
の例です。/scale
サブリソースコントラクトの例を以下に示します。
この例では、Pod を所有することを許可するカスタムリソースのコントローラーが存在しないため、VPA による Pod のスケーリングは行われません。そのため、カスタムリソースと Pod 間の調整と状態管理を管理するために、Kubernetes がサポートする言語でコントローラーを作成する必要があります。この例は、VPA がカスタムリソースをスケーラブルなものとして認識できるようにするための設定を示しています。
カスタム CRD、CR の例
- 1
- カスタムリソースオブジェクトの
status.selector
フィールドに対応する JSON パスを指定します。
カスタム CR の例
- 1
- 管理対象の Pod に適用するラベルのタイプを指定します。これは、カスタムリソース定義オブジェクト内で
labelSelectorPath
が参照するフィールドです。
VPA オブジェクトの例
2.5.6. Vertical Pod Autoscaler Operator のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
Vertical Pod Autoscaler Operator (VPA) を OpenShift Container Platform クラスターから削除できます。アンインストール後、既存の VPA カスタムリソース (CR) によってすでに変更されている Pod のリソース要求は変更されません。VPA によって行われた以前の推奨事項ではなく、ワークロードオブジェクトで定義されたリソースが、新しい Pod に割り当てられます。
oc delete vpa <vpa-name>
コマンドを使用して、特定の VPA CR を削除できます。Vertical Pod Autoscaler のアンインストール時と同じアクションがリソース要求に対して適用されます。
VPA を削除した後、潜在的な問題を回避するために、Operator に関連する他のコンポーネントを削除することを推奨します。
前提条件
- VPA をインストールしている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators をクリックします。 - openshift-vertical-pod-autoscaler プロジェクトに切り替えます。
-
VerticalPodAutoscaler Operator の場合は、Options メニュー
をクリックし、Uninstall Operator を選択します。
- オプション: Operator に関連付けられているすべてのオペランドを削除するには、ダイアログボックスで Delete all operand instances for this operator チェックボックスをオンにします。
- Uninstall をクリックします。
オプション: OpenShift CLI を使用して VPA コンポーネントを削除します。
VPA namespace を削除します。
oc delete namespace openshift-vertical-pod-autoscaler
$ oc delete namespace openshift-vertical-pod-autoscaler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VPA カスタムリソース定義 (CRD) オブジェクトを削除します。
oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io
$ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io
$ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd verticalpodautoscalers.autoscaling.k8s.io
$ oc delete crd verticalpodautoscalers.autoscaling.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CRD を削除すると、関連付けられたロール、クラスターロール、およびロールバインディングが削除されます。
注記この操作により、ユーザーが作成したすべての VPA CR がクラスターから削除されます。VPA を再インストールする場合は、これらのオブジェクトを再度作成する必要があります。
次のコマンドを実行して
MutatingWebhookConfiguration
オブジェクトを削除します。oc delete MutatingWebhookConfiguration vpa-webhook-config
$ oc delete MutatingWebhookConfiguration vpa-webhook-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VPA Operator を削除します。
oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
$ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow