CPUもメモリも自動で最適化したい。そう考えて、KubernetesのHorizontalPodAutoscaler（HPA）とVerticalPodAutoscaler（VPA）を同じDeploymentに両方設定したことはないだろうか。レプリカ数も、1Podあたりのリソース量も、両方AIならぬコントローラ任せにできれば運用は楽になるはずだ。
しかし実際には、HPAとVPAを同じリソースメトリクス（CPUまたはメモリ）で併用すると、2つの自動化が互いの判断材料を書き換え合い、スケーリングが際限なく暴走する「死のスパイラル」に陥ることがある。Kubernetes公式ドキュメントも、この構成を推奨しないと明示している。本記事では、HPA VPA 併用でなぜ事故が起きるのかという因果関係を整理し、実務で安全に両方の自動化を活かすための設計パターンを解説する。
1. なぜ「両方入れれば万全」にならないのか
HPAとVPAは、どちらも「オートスケーリング」という同じ目的語で語られることが多いが、実際に操作する対象は全く異なる。
- HPA（水平スケール）: 対象リソースのCPU使用率などの指標を見て、Podのレプリカ数を増減させる
- VPA（垂直スケール）: 対象Podの実際のリソース消費を観測し、CPU/メモリのrequest・limitそのものを増減させる
この役割の違いがあるからこそ、「HPAでスケールアウトしつつ、VPAで1台ごとのサイズも適正化すれば、リソース効率が最大化できるのでは」という発想が自然に出てくる。実際、負荷が変動するステートレスサービスにはHPA、常時稼働のステートフルワークロードやリクエストが不安定なバッチにはVPA、という使い分けは広く推奨されている。
問題は、この2つを**同じDeploymentの同じメトリクス（例: CPU）**に対して同時に有効化したときに起きる。こうしたオートスケーリング同士の相性は、Podのマニフェストを眺めているだけでは気づきにくい。Kuboのように運用設定を可視化できる管理画面があれば、HPAとVPAが同じメトリクスを奪い合っていないかを設定段階で確認しやすくなる。
2. 衝突のメカニズム — utilizationの分母が動くとHPAが誤判断する
HPAは、対象のCPU使用率を次の式で計算している。
utilization = 現在のCPU使用量 ÷ CPU request × 100
ここで、VPAが「このPodはrequestに対して使用量が低いから、requestを下げよう」と判断して書き換えると、何が起きるか。使用量が変わらなくても、分母（request）が小さくなった分だけ、計算上のutilizationは跳ね上がる。逆にVPAがrequestを引き上げれば、utilizationは見かけ上下がる。
この性質が、以下のようなフィードバックループを生む。
- HPAがスケールアウトしてレプリカ数を増やすと、1Pod あたりの負荷が下がる
- VPAはその「負荷の低下」を履歴として学習し、推奨requestを引き下げる
- requestが下がったことで、同じ使用量でも計算上のutilizationが跳ね上がる
- HPAは「利用率が急上昇した」と判断し、さらにスケールアウトする
このサイクルが繰り返されると、レプリカ数とリソースrequestが同時に増減を続ける、収束しないスケーリングが発生する。Kubernetesの公式ドキュメントでも、VPAのupdateModeや前提条件が詳細に規定されており、HPAとの役割分担を踏まえた設定が求められている。クラウドネイティブの運用知見を発信するScaleOpsの解説では、この構成は「ドキュメント化された推奨されない構成」であり、意図せず組んでしまうエンジニアが後を絶たないと指摘されている。
3. 症状としての「再起動ループ」— VPAのPod再作成との複合要因
前述のフィードバックループに、VPAのもう一つの性質が重なると、症状はさらに分かりにくくなる。VPAはこれまで、リソース設定の変更を適用するためにPodを一度削除して再作成する（evict→再スケジュール）という方式を取ってきた。この再作成とHPAによるレプリカ数の増減が同時多発的に起きると、クラスタ全体で「原因不明の再起動」が連鎖しているように見える。
この課題に対し、Kubernetesエコシステムは着実に手を打ってきた。In-Place Pod Resize（Podを再作成せずにCPU/メモリのrequest・limitを書き換える機能）は2026年12月のアップデートでKubernetes 1.35として安定版(GA)に到達し、Kubernetes公式ブログによれば、v1.27でのアルファ導入から6年以上の開発期間を経て、Podを削除せずにリソース変更を適用できるようになった。VPA側もこれに対応するInPlaceOrRecreateモードを持ち、可能な限りインプレースで更新し、インプレース更新ができない場合のみ従来のeviction（Recreate相当）にフォールバックする。
ただしここで誤解してはいけないのは、In-Place Pod ResizeはVPAの「再作成コスト」を減らす機能であり、HPAとの計算上のフィードバックループ自体を解消するものではないという点だ。再起動が減っても、utilizationの分母が動く問題は残る。症状が緩和されたことで「併用しても大丈夫」と誤解し、根本的な設計を見直さないまま運用を続けてしまうケースには注意したい。
実際、オートスケーリングが「指標の悪化」を忠実に拾い続けた結果、想定外の規模まで暴走する例は他にもある。Komodorが紹介した事例では、あるコード変更が原因でCPU負荷が時間とともに悪化し続け、HPAがそれに反応してPod数を通常の30から4,000まで増やし、ノード数も200まで膨れ上がる4.5時間規模のインシデントに発展した。HPA自体は設計通りに動いていたが、「指標が悪化し続ける根本原因」を見ないまま自動化だけに任せると、是正されないまま規模が際限なく拡大するという教訓は、HPAとVPAの併用問題とも地続きだ。
4. 安全に併用する3つの設計パターン
HPAとVPAを「併用してはいけない」わけではない。同じメトリクスに対して両方が同時に書き換えを行う構成を避ければ、安全に組み合わせることができる。実務でよく使われる設計パターンは次の3つだ。
| パターン | 設計の要点 | 適したケース |
|---|---|---|
| ① updateModeをInitial/Offにする | HPAを有効にしたまま、VPAのupdateModeはAutoではなくInitial（Pod作成時のみ推奨値を適用）またはOff（推奨値の算出のみ）にする | 既にHPAが稼働中で、VPAはリソース見積りの参考値としてだけ使いたい場合 |
| ② メトリクスを分離する | HPAはCPU使用率でスケール、VPAはメモリのrequestのみを最適化する、というように対象メトリクスを分ける | CPUとメモリで負荷特性が異なり、両方を自動最適化したい場合 |
| ③ カスタムメトリクス＋推奨モード | HPAはリクエスト数などのカスタムメトリクスでスケールし、VPAはOffモードで推奨値の算出に専念する | トラフィック量に応じたスケールアウトと、リソース見積りの改善を両立したい場合 |
①のInitialモードが安全な理由は単純だ。Podが作成された時点でrequestが固定され、以降は稼働中のPodに対して変更が入らない。つまりHPAが見るutilizationの分母が安定し、フィードバックループが原理的に発生しなくなる。VPA導入支援ツール「Goldilocks」を提供するFairwindsの解説でも、HPAが有効な環境ではVPAのupdater（自動適用コンポーネント）を無効化し、推奨値の算出に専念させる構成が推奨されている。
②・③のように対象メトリクスやスケーリング指標そのものを分離する設計も、Kubernetesのオートスケーリング比較解説やクラウド監視・コスト最適化分野の解説記事で繰り返し紹介されている、実務的に確立されたアプローチだ。運用監視ツールを提供するOneUptimeの実装例では、「HPAはCPU（またはカスタムメトリクス）でスケール、VPAはメモリのみをOff/Initialモードで最適化する」という役割分担を徹底し、「両方のオートスケーラーが同じメトリクスを監視する構成は絶対に避けるべき」と明言されている。
いずれの場合も、サイドカーコンテナ（Istioプロキシなど）をVPAの対象から除外する設定を忘れないようにしたい。サイドカーのリソースまでVPAが変更すると、サービスメッシュ側で別の不整合が発生しうる。
こうした「どのコントローラがどのメトリクスを担当しているか」の整理は、クラスタが増えるほど属人化しやすい。Kubo CloudのCaptain UIは、HPA・VPAを含むオートスケーリング設定を一覧で可視化する機能を備えており、設計レビューの際にブラックボックス化を防ぐ助けになる。
まとめ
HPAとVPAは、どちらもKubernetesのオートスケーリングを支える強力な機能だが、「両方入れれば安心」という発想は危険だ。同じメトリクスに対して両方が同時に判断を下すと、utilizationの分母が動き続けるフィードバックループが生まれ、レプリカ数とリソースrequestが収束しないまま暴走する。
対策はシンプルだ。VPAのupdateModeをInitialやOffにしてHPAと役割を分けるか、CPU/メモリのようにメトリクスそのものを分離するか、どちらかの設計原則を守ればいい。2026年にIn-Place Pod ResizeがGAしたことで再起動のコストは下がったが、それはあくまで症状の緩和であり、根本的な設計判断（どちらの自動化に何を任せるか）を省略できるわけではない。
本番環境でオートスケーリングの設定を増やすたびに、こうした構成上の落とし穴をレビューする工数は無視できない。KuboのCaptain UIなら、HPA・VPAを含むワークロードの自動化設定を可視化された管理画面で確認でき、どのコントローラが何を書き換えているのかをブラックボックス化せずに把握できる。EKSやAKSで同様の構成をゼロから設計・運用する場合と比べ、月額48,000円〜という価格でK3sベースの本格的なKubernetes運用を始められる点も、こうした運用の落とし穴に時間を取られたくないチームには魅力だろう。
HPAとVPAの併用で悩んでいるなら、まずはどちらのメトリクスをどちらの自動化に任せるかを整理するところから始めてほしい。そのうえでマネージドな運用基盤を検討する場合は、お問い合わせから相談してみるのも一つの選択肢だ。