[{"data":1,"prerenderedAt":297},["ShallowReactive",2],{"blog-ja-hpa-vpa-aep-5342-multidimensional-pod-autoscaler":3,"blog-related-ja-hpa-vpa-aep-5342-multidimensional-pod-autoscaler":251,"blog-ja-hpa-vpa-aep-5342-multidimensional-pod-autoscaler-alt":240},{"id":4,"title":5,"author":6,"body":7,"date":234,"description":235,"extension":236,"image":237,"locale":238,"meta":239,"navigation":240,"path":241,"seo":242,"stem":243,"tags":244,"__hash__":250},"blog\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler.md","HPAとVPAの併用問題、Kubernetes本体がAEP-5342で解決しようとしている。GKE版MPAとの違いとKuboで今できること","Kubo Team",{"type":8,"value":9,"toc":224},"minimark",[10,15,19,26,37,52,56,65,71,79,96,100,112,118,125,134,138,145,151,160,179,183,191,197,204,207,210,217],[11,12,14],"h2",{"id":13},"_1-hpaとvpaの併用が危険と言われ続けてきた理由","1. HPAとVPAの併用が「危険」と言われ続けてきた理由",[16,17,18],"p",{},"Kubernetesの運用で一度は検討する「HPAとVPAを併用する」という選択肢には、長らく明確な警告がついて回ってきました。HPA（Horizontal Pod Autoscaler）とVPA（Vertical Pod Autoscaler）は、どちらも「リソースをどう配分するか」を自動で決めるコントローラーですが、同じメトリクスを対象にすると互いの判断を揺さぶり合ってしまいます。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection01.webp",[16,27,28,29,36],{},"具体的には、HPAがCPU使用率をもとにレプリカ数を決める一方で、VPAが同じCPUのリクエスト値を書き換えると、HPAの「使用率」という分母そのものが動いてしまいます。その結果、スケールアップとスケールダウンが交互に起こる「スラッシング」と呼ばれる不安定な状態に陥ります（",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fhorizontal-pod-autoscale\u002F",[34],"nofollow","Kubernetesの公式ドキュメント","でも、HPAはリソースリクエストを基準に使用率を算出する仕組みが説明されています）。",[16,38,39,40,45,46,51],{},"この問題自体は目新しいものではなく、HPAとVPAを同じCPU\u002Fメモリメトリクスに向けて併用すると競合が起きることは、複数の技術解説記事で繰り返し指摘されてきました（",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-09-vpa-hpa-together-cpu-memory-autoscaling\u002Fview",[34],"VPAとHPAの併用に関する解説","）。厄介なのは、この種の競合がレプリカ数のグラフを継続的に見ていないと気づきにくい点で、",[30,47,50],{"href":48,"rel":49},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようにオートスケーリングの挙動が標準で可視化されている環境でなければ、発見が障害報告の後になりがちです。では、この「もう何年も言われ続けてきた問題」は、今どこまで解決に近づいているのでしょうか。",[11,53,55],{"id":54},"_2-gkeが出した先行解答-multidimensional-pod-autoscalermpaの仕組み","2. GKEが出した先行解答 — Multidimensional Pod Autoscaler（MPA）の仕組み",[16,57,58,59,64],{},"この問題に対して最初に実用的な答えを出したのが、Google Kubernetes Engine（GKE）です。GKEには「Multidimensional Pod Autoscaler（MPA）」という単一のカスタムリソースが用意されており、CPU使用率に基づく水平スケーリングと、メモリ使用量に基づく垂直スケーリングを1つのフィードバックループに統合します（",[30,60,63],{"href":61,"rel":62},"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Ftopics\u002Fdevelopers-practitioners\u002Fscaling-workloads-across-multiple-dimensions-gke",[34],"Google Cloudの公式ブログ","）。",[16,66,67],{},[22,68],{"alt":69,"src":70},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection02.webp",[16,72,73,74,64],{},"仕組みとしては、HPAとVPAをそれぞれ別々に動かすのではなく、「CPUは水平に、メモリは垂直に」という形で対象メトリクスを最初から分離した上で、1つのコントローラーがまとめて面倒を見る設計です。公式ドキュメントによれば、MPAの利用にはGKE 1.19.4-gke.1700以降が必要で、Standardクラスタでは垂直スケーリングを別途有効化する必要があります（",[30,75,78],{"href":76,"rel":77},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fmultidimensional-pod-autoscaling",[34],"Google Cloudの設定ガイド",[16,80,81,82,86,87,91,92,95],{},"ただし重要な制限が2つあります。1つは、MPAが",[83,84,85],"strong",{},"GKE専有の機能","（",[88,89,90],"code",{},"autoscaling.gke.io"," というAPIグループ）であり、EKS・AKS・オンプレミスのクラスタ、そしてK3sベースの環境では利用できないこと。もう1つは、垂直スケーリングの対象が",[83,93,94],{},"現状メモリのみ","で、CPUの垂直スケーリングには対応していないことです。GKEが示したのはあくまで「1つの実装例」であり、Kubernetesのエコシステム全体の答えではありません。",[11,97,99],{"id":98},"_3-kubernetes本体が動き出した-aep-5342が目指すディストリビューション非依存の設計","3. Kubernetes本体が動き出した — AEP-5342が目指すディストリビューション非依存の設計",[16,101,102,103,106,107,64],{},"GKEの一歩先を行こうとしているのが、Kubernetes本体のオートスケーラーを管理する ",[88,104,105],{},"kubernetes\u002Fautoscaler"," プロジェクトです。ここで進んでいるのが「AEP-5342」と呼ばれるMulti-dimensional Pod Autoscalerの提案で、2026年時点でステータスは「implementable（実装可能と承認済み）」まで進んでいます（",[30,108,111],{"href":109,"rel":110},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fautoscaler\u002Fblob\u002Fmaster\u002Fmultidimensional-pod-autoscaler\u002FAEP.md",[34],"kubernetes\u002FautoscalerリポジトリのAEP文書",[16,113,114],{},[22,115],{"alt":116,"src":117},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection03.webp",[16,119,120,121,124],{},"GKEのMPAとの最大の違いは、この提案が",[83,122,123],{},"特定のクラウドベンダーに縛られない設計","を前提にしている点です。AEP-5342では、リソース使用量の推奨を作る「Recommender」と、その推奨を実際にPodへ適用する「Updater／Admission Controller」を分離したアーキテクチャを採用し、垂直・水平の両方のスケーリング判断を単一のフィードバックループに統合することで矛盾を解消しようとしています。既存のHPA\u002FVPAのライブラリを再利用する設計のため、将来的にはK3sを含む他のディストリビューションでも同じ仕組みが使える可能性があります。",[16,126,127,128,133],{},"この設計思想は、業界側の解説でも「HPAとVPAが協調せずに競合する」という根本原因への対処として語られています（",[30,129,132],{"href":130,"rel":131},"https:\u002F\u002Fzesty.co\u002Fblog\u002Fhow-multi-dimensional-autoscaling-fixes-kubernetes-resource-waste\u002F",[34],"マルチディメンショナルオートスケーリングの課題整理","）。もっとも、AEPはまだ「実装可能」という段階であり、K3sで今日から使える機能ではありません。次の章では、その実装を待つ間に何ができるかを整理します。",[11,135,137],{"id":136},"_4-k3s-kuboでは今何ができるか-本番導入までの実践的な代替設計","4. K3s \u002F Kuboでは今、何ができるか — 本番導入までの実践的な代替設計",[16,139,140,141,144],{},"AEP-5342が安定版として各ディストリビューションに降りてくるまでの間、K3s\u002FKuboの環境で現実的に取れる選択肢は「メトリクスの責務を手動で分離する」ことです。具体的には、VPAを",[83,142,143],{},"メモリ専用","にし、HPAを**CPU専用（または外部メトリクス）**に向けることで、GKEのMPAがやっていることを手動で再現します。",[16,146,147],{},[22,148],{"alt":149,"src":150},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection04.webp",[16,152,153,154,159],{},"VPAのupdateModeは「Off」「Initial」「Auto」「Recreate」の4種類があり、HPAと併用する場合は、新規Pod作成時だけリソースを調整する「Initial」や、推奨値の提示だけに留める「Off」が安全とされています（",[30,155,158],{"href":156,"rel":157},"https:\u002F\u002Fwww.devzero.io\u002Fblog\u002Fkubernetes-vpa",[34],"VPAの仕組みに関する解説","）。一方、非推奨とされる「Auto」モードで両者を併用すると、Podのエビクトと再起動が頻発し、不安定さが増幅されやすくなります。",[16,161,162,163,168,169,174,175,178],{},"なお、Kubernetesは2025年のv1.33でPodの「In-place Pod Resize」機能をベータ化し、コンテナを再起動せずにCPU・メモリのリクエストを変更できるようになりました（",[30,164,167],{"href":165,"rel":166},"https:\u002F\u002Fv1-34.docs.kubernetes.io\u002Fblog\u002F2025\u002F05\u002F16\u002Fkubernetes-v1-33-in-place-pod-resize-beta\u002F",[34],"Kubernetes公式ブログ","）。これはVPAの無停止運用を後押しする基盤技術で、AEP-5342のような統合型オートスケーラーが実用段階に進む際の土台にもなります。K3sは軽量なコントロールプレーンで全コンポーネントを単一プロセスとして動かすため、メトリクスも単一のPrometheusレジストリに統合される特性があり（",[30,170,173],{"href":171,"rel":172},"https:\u002F\u002Fdocs.k3s.io\u002Fja\u002Freference\u002Fmetrics",[34],"K3s公式ドキュメント","）、",[30,176,50],{"href":48,"rel":177},[34],"のようにPrometheus+Grafanaが標準搭載された環境であれば、この種の責務分離設計の効果をダッシュボード上で検証しやすくなります。VPAのレコメンデーションとHPAのレプリカ数推移を並べて観察できるかどうかが、設計が機能しているかの判断材料になります。",[11,180,182],{"id":181},"_5-この動向はkedaの位置づけにも影響する","5. この動向はKEDAの位置づけにも影響する",[16,184,185,186,64],{},"HPAとVPAの統合が進むほど、両者とは別の文脈にあるKEDA（Kubernetes Event-driven Autoscaling）の役割も相対的にはっきりしてきます。判断基準はシンプルで、スケーリングのトリガーがCPU・メモリのようなリソース圧力であればHPA（将来的にはMPA的な統合）、キューの長さや外部イベントのような信号であればKEDAという住み分けです（",[30,187,190],{"href":188,"rel":189},"https:\u002F\u002Fwww.plural.sh\u002Fblog\u002Fkeda-vs-hpa-guide\u002F",[34],"HPAとKEDAの使い分けガイド",[16,192,193],{},[22,194],{"alt":195,"src":196},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection05.webp",[16,198,199,200,203],{},"言い換えると、AEP-5342が目指しているのは「リソース起点のスケーリングを1つにまとめる」ことであり、KEDAが担う「イベント起点のスケーリング」とは競合しません。むしろHPA\u002FVPAの統合が進むことで、KEDAは本来の役割であるイベント駆動ワークロードに集中できるようになる、という整理ができます。こうした複数のオートスケーラーを組み合わせる構成は個別に動作確認するほど工数がかさむため、",[30,201,50],{"href":48,"rel":202},[34],"のGitOps対応やHelm標準搭載といった機能で検証サイクルを短縮できる場面でもあります。",[11,205,206],{"id":206},"まとめ",[16,208,209],{},"HPAとVPAの併用が「危険」だという指摘は、今でも技術的には正しい事実です。ただしそれは固定的な結論ではなく、GKEのMPAという実装例と、Kubernetes本体で進むAEP-5342という提案によって、業界全体が解決に向けて動いている過渡期にあると捉えるべきでしょう。",[16,211,212,213,216],{},"K3s\u002FKuboの環境では、AEP-5342が安定版として降りてくるまでの間、VPAをメモリ専用・HPAをCPU専用に責務分離する設計で十分に併用リスクを抑えられます。こうした細かな設定判断は、可視化されていない環境ほど見落とされやすいものです。",[30,214,50],{"href":48,"rel":215},[34],"はCaptain UIでHPA\u002FVPAの挙動を可視化できるため、レプリカ数の頻繁な変動のような競合の兆候を検証段階で発見しやすくなります。",[16,218,219,220,223],{},"K3sベースでこうしたオートスケーリング設計を検証したい場合、",[30,221,50],{"href":48,"rel":222},[34],"なら月額48,000円〜でPrometheus+Grafanaが標準搭載された環境をすぐに用意できます。AEP-5342の進捗を追いながら、まずは今できるメトリクス分離の設計から試してみてはいかがでしょうか。",{"title":225,"searchDepth":226,"depth":226,"links":227},"",2,[228,229,230,231,232,233],{"id":13,"depth":226,"text":14},{"id":54,"depth":226,"text":55},{"id":98,"depth":226,"text":99},{"id":136,"depth":226,"text":137},{"id":181,"depth":226,"text":182},{"id":206,"depth":226,"text":206},"2026-10-27","HPAとVPAの併用は長年危険とされてきたが、GKEのMultidimensional Pod AutoscalerとKubernetes本体のAEP-5342提案が解決の方向性を示し始めている。K3s\u002FKuboで今日から実践できる設計も解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler",{"title":5,"description":235},"blog\u002Fja\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler",[245,246,247,248,249],"k3s","kubernetes","hpa","vpa","autoscaling","6jBjx9sOAoM5ZPglZ-Mwz1BTJrXrlBkaIsqMKUNG0qE",[252,258,265,273,280,288],{"path":253,"title":254,"description":255,"date":256,"tags":257},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[245,246,247,248,249],{"path":259,"title":260,"description":261,"date":262,"tags":263},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[245,246,247,248,249,264],"metrics-server",{"path":266,"title":267,"description":268,"date":269,"tags":270},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[245,246,247,271,249,272],"containerresource","service-mesh",{"path":274,"title":275,"description":276,"date":277,"tags":278},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","2026-10-17",[245,246,248,249,279],"cgroup",{"path":281,"title":282,"description":283,"date":284,"tags":285},"\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","discoveryIntervalを疑え。K3sのHPAがPrometheus Adapter経由で\"古いメトリクス\"を掴み続ける設定ミス","K3sのHPAがCPU使用率は正常なのにスケールしない。原因はPrometheus Adapterのmetrics-relist-interval\u002Fmetrics-max-ageとHPA sync-periodが噛み合っていない設定ミスだった。3層の遅延構造と診断コマンドを解説する。","2026-10-12",[245,246,247,286,249,287],"prometheus-adapter","observability",{"path":289,"title":290,"description":291,"date":292,"tags":293},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[245,246,294,247,249,295,296],"keda","event-driven-scaling","scaledobject",1793798685654]