1. HPAとVPAの併用が「危険」と言われ続けてきた理由
Kubernetesの運用で一度は検討する「HPAとVPAを併用する」という選択肢には、長らく明確な警告がついて回ってきました。HPA（Horizontal Pod Autoscaler）とVPA（Vertical Pod Autoscaler）は、どちらも「リソースをどう配分するか」を自動で決めるコントローラーですが、同じメトリクスを対象にすると互いの判断を揺さぶり合ってしまいます。
具体的には、HPAがCPU使用率をもとにレプリカ数を決める一方で、VPAが同じCPUのリクエスト値を書き換えると、HPAの「使用率」という分母そのものが動いてしまいます。その結果、スケールアップとスケールダウンが交互に起こる「スラッシング」と呼ばれる不安定な状態に陥ります（Kubernetesの公式ドキュメントでも、HPAはリソースリクエストを基準に使用率を算出する仕組みが説明されています）。
この問題自体は目新しいものではなく、HPAとVPAを同じCPU/メモリメトリクスに向けて併用すると競合が起きることは、複数の技術解説記事で繰り返し指摘されてきました（VPAとHPAの併用に関する解説）。厄介なのは、この種の競合がレプリカ数のグラフを継続的に見ていないと気づきにくい点で、Kuboのようにオートスケーリングの挙動が標準で可視化されている環境でなければ、発見が障害報告の後になりがちです。では、この「もう何年も言われ続けてきた問題」は、今どこまで解決に近づいているのでしょうか。
2. GKEが出した先行解答 — Multidimensional Pod Autoscaler（MPA）の仕組み
この問題に対して最初に実用的な答えを出したのが、Google Kubernetes Engine（GKE）です。GKEには「Multidimensional Pod Autoscaler（MPA）」という単一のカスタムリソースが用意されており、CPU使用率に基づく水平スケーリングと、メモリ使用量に基づく垂直スケーリングを1つのフィードバックループに統合します（Google Cloudの公式ブログ）。
仕組みとしては、HPAとVPAをそれぞれ別々に動かすのではなく、「CPUは水平に、メモリは垂直に」という形で対象メトリクスを最初から分離した上で、1つのコントローラーがまとめて面倒を見る設計です。公式ドキュメントによれば、MPAの利用にはGKE 1.19.4-gke.1700以降が必要で、Standardクラスタでは垂直スケーリングを別途有効化する必要があります（Google Cloudの設定ガイド）。
ただし重要な制限が2つあります。1つは、MPAがGKE専有の機能（autoscaling.gke.io というAPIグループ）であり、EKS・AKS・オンプレミスのクラスタ、そしてK3sベースの環境では利用できないこと。もう1つは、垂直スケーリングの対象が現状メモリのみで、CPUの垂直スケーリングには対応していないことです。GKEが示したのはあくまで「1つの実装例」であり、Kubernetesのエコシステム全体の答えではありません。
3. Kubernetes本体が動き出した — AEP-5342が目指すディストリビューション非依存の設計
GKEの一歩先を行こうとしているのが、Kubernetes本体のオートスケーラーを管理する kubernetes/autoscaler プロジェクトです。ここで進んでいるのが「AEP-5342」と呼ばれるMulti-dimensional Pod Autoscalerの提案で、2026年時点でステータスは「implementable（実装可能と承認済み）」まで進んでいます（kubernetes/autoscalerリポジトリのAEP文書）。
GKEのMPAとの最大の違いは、この提案が特定のクラウドベンダーに縛られない設計を前提にしている点です。AEP-5342では、リソース使用量の推奨を作る「Recommender」と、その推奨を実際にPodへ適用する「Updater／Admission Controller」を分離したアーキテクチャを採用し、垂直・水平の両方のスケーリング判断を単一のフィードバックループに統合することで矛盾を解消しようとしています。既存のHPA/VPAのライブラリを再利用する設計のため、将来的にはK3sを含む他のディストリビューションでも同じ仕組みが使える可能性があります。
この設計思想は、業界側の解説でも「HPAとVPAが協調せずに競合する」という根本原因への対処として語られています（マルチディメンショナルオートスケーリングの課題整理）。もっとも、AEPはまだ「実装可能」という段階であり、K3sで今日から使える機能ではありません。次の章では、その実装を待つ間に何ができるかを整理します。
4. K3s / Kuboでは今、何ができるか — 本番導入までの実践的な代替設計
AEP-5342が安定版として各ディストリビューションに降りてくるまでの間、K3s/Kuboの環境で現実的に取れる選択肢は「メトリクスの責務を手動で分離する」ことです。具体的には、VPAをメモリ専用にし、HPAを**CPU専用（または外部メトリクス）**に向けることで、GKEのMPAがやっていることを手動で再現します。
VPAのupdateModeは「Off」「Initial」「Auto」「Recreate」の4種類があり、HPAと併用する場合は、新規Pod作成時だけリソースを調整する「Initial」や、推奨値の提示だけに留める「Off」が安全とされています（VPAの仕組みに関する解説）。一方、非推奨とされる「Auto」モードで両者を併用すると、Podのエビクトと再起動が頻発し、不安定さが増幅されやすくなります。
なお、Kubernetesは2025年のv1.33でPodの「In-place Pod Resize」機能をベータ化し、コンテナを再起動せずにCPU・メモリのリクエストを変更できるようになりました（Kubernetes公式ブログ）。これはVPAの無停止運用を後押しする基盤技術で、AEP-5342のような統合型オートスケーラーが実用段階に進む際の土台にもなります。K3sは軽量なコントロールプレーンで全コンポーネントを単一プロセスとして動かすため、メトリクスも単一のPrometheusレジストリに統合される特性があり（K3s公式ドキュメント）、KuboのようにPrometheus+Grafanaが標準搭載された環境であれば、この種の責務分離設計の効果をダッシュボード上で検証しやすくなります。VPAのレコメンデーションとHPAのレプリカ数推移を並べて観察できるかどうかが、設計が機能しているかの判断材料になります。
5. この動向はKEDAの位置づけにも影響する
HPAとVPAの統合が進むほど、両者とは別の文脈にあるKEDA（Kubernetes Event-driven Autoscaling）の役割も相対的にはっきりしてきます。判断基準はシンプルで、スケーリングのトリガーがCPU・メモリのようなリソース圧力であればHPA（将来的にはMPA的な統合）、キューの長さや外部イベントのような信号であればKEDAという住み分けです（HPAとKEDAの使い分けガイド）。
言い換えると、AEP-5342が目指しているのは「リソース起点のスケーリングを1つにまとめる」ことであり、KEDAが担う「イベント起点のスケーリング」とは競合しません。むしろHPA/VPAの統合が進むことで、KEDAは本来の役割であるイベント駆動ワークロードに集中できるようになる、という整理ができます。こうした複数のオートスケーラーを組み合わせる構成は個別に動作確認するほど工数がかさむため、KuboのGitOps対応やHelm標準搭載といった機能で検証サイクルを短縮できる場面でもあります。
まとめ
HPAとVPAの併用が「危険」だという指摘は、今でも技術的には正しい事実です。ただしそれは固定的な結論ではなく、GKEのMPAという実装例と、Kubernetes本体で進むAEP-5342という提案によって、業界全体が解決に向けて動いている過渡期にあると捉えるべきでしょう。
K3s/Kuboの環境では、AEP-5342が安定版として降りてくるまでの間、VPAをメモリ専用・HPAをCPU専用に責務分離する設計で十分に併用リスクを抑えられます。こうした細かな設定判断は、可視化されていない環境ほど見落とされやすいものです。KuboはCaptain UIでHPA/VPAの挙動を可視化できるため、レプリカ数の頻繁な変動のような競合の兆候を検証段階で発見しやすくなります。
K3sベースでこうしたオートスケーリング設計を検証したい場合、Kuboなら月額48,000円〜でPrometheus+Grafanaが標準搭載された環境をすぐに用意できます。AEP-5342の進捗を追いながら、まずは今できるメトリクス分離の設計から試してみてはいかがでしょうか。