そのresources設定、"勘"で決めていませんか？
OpenShiftクラスターでアプリケーションを運用していると、必ず向き合うことになるresources（requests / limits）の設定。
- 「このPodのCPU
requests、200mで本当に足りる…？」 - 「メモリ
1Giって申請されたけど、クラスタリソースをムダ遣いしてない？」 - 「とりあえず動いてるけど、これって最適な値なんだろうか…？」
Podの安定稼働とコスト効率を左右する重要な設定が、経験や"勘"に頼りがちになってしまうことがあります。
この記事では、OpenShiftで手軽に導入できるVertical Pod Autoscaler（VPA）を、安全な "Offモード" で動かし、リソース設定の最適解を"盗み見る"実践テクニックを紹介します。VPAは読んで字の如し、自動スケールアップが主目的の機能です。
VPAのOffモードは「優秀な分析レポート」
VPAには、その働き方を決めるいくつかのモードがあります。多くの方が心配する自動再起動はRecreateモードの挙動です。
しかし、今回主役となるupdateMode: "Off"は、Podに一切手を出しません。
その仕事はただ一つ。対象のPodの働きぶり（CPU/メモリ使用量）をじっと観察し、「このPodなら、これくらいのリソースが最適ですよ」という推奨値（Recommendation）をレポートしてくれます。
OpenShiftではVPA Operatorの導入がとても簡単です。OperatorHubから数クリックでインストールできるため、面倒な設定なしですぐにVPAを利用できます。
（インストールは簡単なので省略します！）
実践！stress-ngで負荷をかけ、VPAに分析させる
では、実際にstress-ngで擬似的な負荷をかけ、VPAで分析結果を確認してみます。
Step 1：準備（Podと"Offモード"VPAの用意）
まず、テスト対象のPodと、それを監視するupdateMode: "Off"のVPAを用意します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: stress-test-vpa
spec:
replicas: 1
selector:
matchLabels:
app: stress-vpa
template:
metadata:
labels:
app: stress-vpa
spec:
containers:
- name: stress-container
image: polinux/stress-ng
# resourcesはあえて空にしておく
resources: {}
command: ["tail", "-f", "/dev/null"]
apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
name: stress-vpa-analyzer
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: stress-test-vpa
updatePolicy:
# "Off"モードで、推奨値のレポートだけを出力させる
updateMode: "Off"
作成したYAMLをocコマンドで適用します。
$ oc apply -f test-deployment.yaml
$ oc apply -f test-vpa-off.yaml
Step 2：模擬試験（高負荷シナリオを実行する）
次に、stress-ngで負荷をかけてみます。
# Pod名を取得して、高負荷コマンドを実行
$ POD_NAME=$(oc get pods -l app=stress-vpa -o 'jsonpath={.items[0].metadata.name}')
$ oc exec -it ${POD_NAME} -- stress-ng --cpu 1 --cpu-load 80 --timeout 180s
別プロンプトで確認すると負荷が上がっていることがわかります。
NAME CPU(cores) MEMORY(bytes)
stress-test-vpa-7c86789c8c-twwts 789m 8Mi
Step 3：レポート確認（VPAの推奨値を盗み見る！）
負荷をかけている間に、裏でVPAアナリストがどんなレポートをまとめているか確認します。oc describe vpaコマンドで、Recommendation（推奨）セクションに注目します。
# VPAの分析レポートを確認する
$ oc describe vpa stress-vpa-analyzer
...
Recommendation:
Container Recommendations:
Container Name: stress-container
Lower Bound:
Cpu: 25m
Memory: 262144k
Target:
Cpu: 920m
Memory: 262144k
Uncapped Target:
Cpu: 920m
Memory: 262144k
Upper Bound:
Cpu: 147306m
Memory: 1841334254
...
VPAのレポートを見てみます。
Target: 920m ← VPAが考える 「推奨値」 です。requests設定の最有力候補です。
Lower Bound: 25m ← 最小推奨リソースです。
Upper Bound: 147306m ← 最大推奨リソースです。
VPAはTargetとして「920mのCPUが妥当だろう」と分析してくれました！
まとめ：安全な"答え合わせ"で、リソース設定に自信を
"Offモード"のVPAは、その演技を見て最適なresourcesを安全に教えてくれるアナリストとして利用できます。
今回利用したstress-ngは、アプリケーションのさまざまな負荷シナリオを実行する便利なツールです。（昔からあるので色んなサイトで紹介されています。）
VPAを使えば、以下のシーンで活用できるかと思います！
- 開発段階で、アプリの適切なリソース量を見積もる
- 本番環境で、既存のPodのリソース設定が妥当か、診断する
requests設定で「なんとなく」になりそうなときはVPAを活用して、リソース設定に裏付けを加えてみてはいかがでしょう。