導入前回の記事では、HPA（Horizontal Pod Autoscaler）の実装について紹介しました。 HPA は一般に水平拡張と呼ばれます。 HPA とは異なり、Vertical Pod Autoscaler (VPA) は Pod の CPU とメモリのプロパティを自動的に調整します。これを垂直拡張と呼びます。 VPA は、サービス操作に適した CPU およびメモリ構成を提供できるため、サービス リソースの使用量を見積もる時間を節約し、リソースをより合理的に使用できます。もちろん、VPA はリソースの使用状況に基づいてポッド リソースを「調整」することもできます。ここで調整に二重引用符を使用するのは、その実装メカニズムが動的な増加ではなく再構築であるためです。実際の例を挙げます。メモリ制限が 100Mi であるが、現在 98Mi が使用されているとします。それ以上大きい場合はOOMになります。このとき、VPA はメモリ制限のサイズを垂直方向に増加します。このタイプの VPA は、es などの大量のリソースを消費するアプリケーションに適しています。大きな値を与えるとリソースが無駄になり、小さな値を与えるとリソースが足りなくなります。そこで、vpa が役に立ちます。もちろん、vpa は hpa のようにデフォルトで k8s に統合されていないため、自分で構成する必要があります。 VPA と HPA基本的に、VPA と HPA の違いはスケーリング方法です。 HPA はポッドを追加または削除することでスケーリングし、それによって容量を水平方向にスケーリングします。ただし、VPA は既存の Pod コンテナー内の CPU およびメモリ リソースを増減することでスケーリングし、容量を垂直方向にスケーリングします。次の表では、Kubernetes VPA と HPA の違いについて詳しく説明します。 容量を調整する必要がある
| 水平スケーリング (HPA)
| 垂直スケーリング (VPA)
| その他のリソース
| ポッドの追加
| 既存のポッドコンテナのCPUまたはメモリリソースを増やす
| リソースの削減
| ポッドの削除
| 既存のPodコンテナのCPUまたはメモリリソースを削減する
|
仕組み写真 VPA の構成要素VPA 展開には、VPA Recommender、VPA Updater、VPA Admission Controller という 3 つの主要コンポーネントがあります。各コンポーネントの機能を見てみましょう。 VPA 推奨者: - リソースの使用率を監視し、目標値を計算します。
- メトリック履歴、OOM イベント、VPA 展開仕様を表示し、適切なリクエストを推奨します。定義された制限要求に応じて制限を増減します。
VPA アップデータ: - 新しいリソース制限を必要とするポッドを削除します。
- 「updateMode: Auto」が定義されている場合は、推奨者が提案するものをすべて実装します。
VPA アドミッション コントローラー: - VPA Updater がポッドを削除して再起動するたびに、新しいポッドが起動する前に、CPU とメモリの設定が (Webhook を使用して) 変更されます。
- Vertical Pod Autoscaler の updateMode が「Auto」に設定されている場合、Pod のリソース要求を変更する必要がある場合、Pod は削除されます。 Kubernetes の設計上、実行中のポッドのリソース要求を変更する唯一の方法は、ポッドを再作成することです。
Kubernetes VPA の動作モード写真 - ユーザーが VPA を構成します。
- VPA Recommender は、メトリック サーバーから VPA 構成とリソース使用率メトリックを読み取ります。
- VPA Recommender は、Pod リソースの推奨を提供します。
- VPA Updater は Pod リソースの推奨事項を読み取ります。
- VPA アップデータがポッドの終了を開始します。
- デプロイメントはポッドが終了したことを認識し、レプリカ構成に合わせてポッドを再作成します。
- ポッドの再作成中に、VPA アドミッション コントローラーはポッド リソースの推奨事項を取得します。 Kubernetes は実行中のポッドのリソース制限を動的に変更することをサポートしていないため、VPA は既存のポッドを新しい制限で更新できません。古い制限を使用するポッドを終了します。 Pod のコントローラーが Kubernetes API サーバーに置き換えを要求すると、VPA アドミッション コントローラーは更新されたリソース要求と制限値を新しい Pod の仕様に挿入します。
- 最後に、VPA アドミッション コントローラーはポッドの推奨事項をオーバーライドします。この例では、VPA アドミッション コントローラーがポッドに「250m」CPU を追加しました。
ベストプラクティス大まかな考え方がわかったところで、始めましょう。 克隆代码# git clone https://github.com/kubernetes/autoscaler.git由于某些原因拉不到镜像，改yaml修改优先使用本地镜像# cd autoscaler/vertical-pod-autoscaler/deploy # sed -i 's/Always/IfNotPresent/g' recommender-deployment.yaml # sed -i 's/Always/IfNotPresent/g' admission-controller-deployment.yaml # sed -i 's/Always/IfNotPresent/g' updater-deployment.yaml # 拉取镜像# docker pull giantswarm/vpa-admission-controller:0.14.0 # docker pull giantswarm/vpa-recommender:0.14.0 # docker pull giantswarm/vpa-updater:0.14.0 # 修改tag # docker tag giantswarm/vpa-updater:0.14.0 registry.k8s.io/autoscaling/vpa-updater:0.14.0 # docker tag giantswarm/vpa-recommender:0.14.0 registry.k8s.io/autoscaling/vpa-recommender:0.14.0 # docker tag giantswarm/vpa-admission-controller:0.14.0 registry.k8s.io/autoscaling/vpa-admission-controller:0.14.0 # cd autoscaler/vertical-pod-autoscaler/hack # 安装脚本安装之前保证你的K8S集群的metrics-server已安装，并且openssl升级到1.1.1或更高版本# ./vpa-up.sh
インストールが完了するまで待ちます # kubectl get pods -n kube-system | grep vpa kube-system vpa-admission-controller-75bffbf8d8-6hxqq 1/1 Running 0 5m9s kube-system vpa-recommender-748c55b5bf-kqqjc 1/1 Running 0 4m34s kube-system vpa-updater-679d5dcdd6-lslc7 1/1 Running 0 4m15s
VPA では、リソース要件を自動的に計算するコントローラーごとに Vertical Pod Autoscaler リソースを挿入する必要があります。これは最も一般的なデプロイメントになります。 VPAには4つの動作モードがある - 「自動」: VPA はポッドの作成時にリソース要求を割り当て、優先更新メカニズムを使用して既存のポッドでそれらを更新します。現在、これは「再作成」と同等です (下記参照)。ポッド要求の再起動不要の (「インプレース」) 更新が利用可能になると、この「自動」モードでは優先更新メカニズムとして使用できます。注意: VPA のこの機能は実験段階であり、アプリケーションのダウンタイムが発生する可能性があります。現在実行中のポッドのリソースが VPA の推奨値を満たしていない場合、ポッドは排除され、十分なリソースを持つ新しいサービスが再デプロイされます。
- 「再作成」: VPA は、ポッドの作成時にリソース要求を割り当て、要求されたリソースが新しい提案と大幅に異なる場合は既存のポッドでリソース要求を更新します (定義されている場合は、ポッド中断予算を考慮します)。このモードは、リソース要求が変更されたときに Pod が再起動されることを保証する必要がある場合にのみ、まれに使用してください。それ以外の場合は、この「自動」モードを優先し、再起動不要のアップデートが利用可能になったらすぐに活用してください。注: VPA のこの機能は実験的なものであり、アプリケーションのダウンタイムを引き起こす可能性があります。
- 「初期」: VPA はポッドの作成時にのみリソース要求を割り当て、後で変更することはありません。
- 「オフ」: VPA はポッドのリソース要件を自動的に変更しません。これらの推奨事項は計算され、VPA オブジェクトで検査できます。このモードではリソースの推奨事項のみが取得され、ポッドは更新されません。
updateMode: Auto で VPA を作成する # 将updateMode中的requests 改为CPU：50m，Memory: 50Mi，同时将updateMode修改为Auto # 创建一个pod和svc # kubectl get pods -n vpa NAME READY STATUS RESTARTS AGE nginx-8454bb78d8-67pth 1/1 Running 0 9s nginx-8454bb78d8-6efsh 1/1 Running 0 9s # kubectl get svc -n vpa NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx NodePort 10.0.200.5 <none> 80:45425/TCP 15s # 进行压测，压测到一半时，突然连接断了，说明POD被重新创建了# ab -c 1000 -n 100000 http://192.168.0.191:45425/ This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 192.168.0.191 (be patient) apr_socket_recv: Connection reset by peer (104) Total of 187078 requests completed # 查看vpa # kubectl describe vpa nginx-vpa -n vpa | tail -n 20 Conditions: Last Transition Time: 2023-09-07T15:41:32Z Status: True Type: RecommendationProvided Recommendation: Container Recommendations: Container Name: nginx Lower Bound: #容器的最小估计值Cpu: 100m Memory: 262144k Target: #目标估计是我们用于设置资源请求的估计Cpu: 350m Memory: 262144k Uncapped Target: #无上限目标估计是在没有minAllowed和maxAllowed限制的情况下产生的目标估计Cpu: 350m Memory: 262144k Upper Bound: #上限是容器的最大建议资源估计Cpu: 2 Memory: 405160855 Events: <none> # 查看pod被重新创建了稍高的配置# kubectl get pods -n vpa NAME READY STATUS RESTARTS AGE nginx-daecsfv8d8-see8h 1/1 Running 0 4m nginx-daecsfv8d8-fsise 1/1 Running 0 3m
既知の制限- VPA が Pod リソースを更新するたびに、Pod が再作成され、実行中のすべてのコンテナが再作成されます。ポッドは異なるノード上で再作成できます。
- VPA は、推奨事項を適用するために排除または削除したポッド (自動モードおよび再作成モードで構成されている場合) が正常に再作成されることを保証できません。この問題は、VPA と Cluster Autoscaler を組み合わせることで部分的に解決できます。
- VPA は、コントローラーの下で実行されていないポッドのリソースを更新しません。
- 現在、Vertical Pod Autoscaler は、CPU またはメモリ上の Horizontal Pod Autoscaler (HPA) と併用しないでください。ただし、カスタム メトリックや外部メトリックでは、VPA を HPA と組み合わせて使用できます。
- VPA アドミッション コントローラーはアドミッション Webhook です。クラスターにアドミッション Webhook を追加する場合は、それらがどのように相互作用し、互いに競合する可能性があるかどうかを分析することが重要です。アドミッション コントローラの順序は、API サーバー上のフラグによって定義されます。
- VPA はほとんどのメモリ不足イベントに反応しますが、すべてのケースに反応するわけではありません。
- VPA のパフォーマンスは大規模クラスターではテストされていません。
- VPA の推奨事項は、利用可能なリソース (ノード サイズ、利用可能なサイズ、利用可能な割り当てなど) を超え、ポッドが保留状態になる可能性があります。この問題は、VPA と Cluster Autoscaler を組み合わせることで部分的に解決できます。
- 同じ Pod に一致する複数の VPA リソースの動作は未定義です。
要約するこの記事では、VPA を使用して、POD に基づく構成の水平拡張を実装します。合理的に使用することで、K8S の利用率が向上し、コスト削減と効率向上が実現します。しかし、現在の VPA にもいくつか問題があります。個人的には、VPA の最大の問題は、サービスを再構築することであり、再構築プロセス中にトラフィックが失われる可能性があると考えています。しかし、良いニュースとしては、バージョン 1.27 からは、アプリケーションを再起動せずにコンテナの CPU とメモリのリソース制限を動的に調整できるようになりました。近い将来、ダイナミックな拡張はよりスムーズになるでしょう。一緒に楽しみましょう〜 | 
