[{"data":1,"prerenderedAt":427},["ShallowReactive",2],{"blog-ja-kubernetes-hpa-vpa-autoscaling-conflict-design":3,"blog-related-ja-kubernetes-hpa-vpa-autoscaling-conflict-design":381,"blog-ja-kubernetes-hpa-vpa-autoscaling-conflict-design-alt":370},{"id":4,"title":5,"author":6,"body":7,"date":364,"description":365,"extension":366,"image":367,"locale":368,"meta":369,"navigation":370,"path":371,"seo":372,"stem":373,"tags":374,"__hash__":380},"blog\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design.md","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","Kubo Team",{"type":8,"value":9,"toc":356},"minimark",[10,18,21,24,29,32,57,60,71,75,81,84,95,98,101,116,131,135,141,148,165,172,181,185,191,198,279,291,312,315,323,326,329,335,347],[11,12,13],"p",{},[14,15],"img",{"alt":16,"src":17},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design\u002Fsection01.webp",[11,19,20],{},"CPUもメモリも自動で最適化したい。そう考えて、KubernetesのHorizontalPodAutoscaler（HPA）とVerticalPodAutoscaler（VPA）を同じDeploymentに両方設定したことはないだろうか。レプリカ数も、1Podあたりのリソース量も、両方AIならぬコントローラ任せにできれば運用は楽になるはずだ。",[11,22,23],{},"しかし実際には、HPAとVPAを同じリソースメトリクス（CPUまたはメモリ）で併用すると、2つの自動化が互いの判断材料を書き換え合い、スケーリングが際限なく暴走する「死のスパイラル」に陥ることがある。Kubernetes公式ドキュメントも、この構成を推奨しないと明示している。本記事では、HPA VPA 併用でなぜ事故が起きるのかという因果関係を整理し、実務で安全に両方の自動化を活かすための設計パターンを解説する。",[25,26,28],"h2",{"id":27},"_1-なぜ両方入れれば万全にならないのか","1. なぜ「両方入れれば万全」にならないのか",[11,30,31],{},"HPAとVPAは、どちらも「オートスケーリング」という同じ目的語で語られることが多いが、実際に操作する対象は全く異なる。",[33,34,35,47],"ul",{},[36,37,38,42,43,46],"li",{},[39,40,41],"strong",{},"HPA（水平スケール）",": 対象リソースのCPU使用率などの指標を見て、Podの",[39,44,45],{},"レプリカ数","を増減させる",[36,48,49,52,53,56],{},[39,50,51],{},"VPA（垂直スケール）",": 対象Podの実際のリソース消費を観測し、",[39,54,55],{},"CPU\u002Fメモリのrequest・limit","そのものを増減させる",[11,58,59],{},"この役割の違いがあるからこそ、「HPAでスケールアウトしつつ、VPAで1台ごとのサイズも適正化すれば、リソース効率が最大化できるのでは」という発想が自然に出てくる。実際、負荷が変動するステートレスサービスにはHPA、常時稼働のステートフルワークロードやリクエストが不安定なバッチにはVPA、という使い分けは広く推奨されている。",[11,61,62,63,70],{},"問題は、この2つを**同じDeploymentの同じメトリクス（例: CPU）**に対して同時に有効化したときに起きる。こうしたオートスケーリング同士の相性は、Podのマニフェストを眺めているだけでは気づきにくい。",[64,65,69],"a",{"href":66,"rel":67},"https:\u002F\u002Fkubo.hexabase.io\u002F",[68],"nofollow","Kubo","のように運用設定を可視化できる管理画面があれば、HPAとVPAが同じメトリクスを奪い合っていないかを設定段階で確認しやすくなる。",[25,72,74],{"id":73},"_2-衝突のメカニズム-utilizationの分母が動くとhpaが誤判断する","2. 衝突のメカニズム — utilizationの分母が動くとHPAが誤判断する",[11,76,77],{},[14,78],{"alt":79,"src":80},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design\u002Fsection02.webp",[11,82,83],{},"HPAは、対象のCPU使用率を次の式で計算している。",[85,86,91],"pre",{"className":87,"code":89,"language":90},[88],"language-text","utilization = 現在のCPU使用量 ÷ CPU request × 100\n","text",[92,93,89],"code",{"__ignoreMap":94},"",[11,96,97],{},"ここで、VPAが「このPodはrequestに対して使用量が低いから、requestを下げよう」と判断して書き換えると、何が起きるか。使用量が変わらなくても、分母（request）が小さくなった分だけ、計算上のutilizationは跳ね上がる。逆にVPAがrequestを引き上げれば、utilizationは見かけ上下がる。",[11,99,100],{},"この性質が、以下のようなフィードバックループを生む。",[102,103,104,107,110,113],"ol",{},[36,105,106],{},"HPAがスケールアウトしてレプリカ数を増やすと、1Pod あたりの負荷が下がる",[36,108,109],{},"VPAはその「負荷の低下」を履歴として学習し、推奨requestを引き下げる",[36,111,112],{},"requestが下がったことで、同じ使用量でも計算上のutilizationが跳ね上がる",[36,114,115],{},"HPAは「利用率が急上昇した」と判断し、さらにスケールアウトする",[11,117,118,119,124,125,130],{},"このサイクルが繰り返されると、レプリカ数とリソースrequestが同時に増減を続ける、収束しないスケーリングが発生する。",[64,120,123],{"href":121,"rel":122},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002Fvertical-pod-autoscale\u002F",[68],"Kubernetesの公式ドキュメント","でも、VPAのupdateModeや前提条件が詳細に規定されており、HPAとの役割分担を踏まえた設定が求められている。クラウドネイティブの運用知見を発信する",[64,126,129],{"href":127,"rel":128},"https:\u002F\u002Fscaleops.com\u002Fblog\u002Fhpas-three-architectural-flaws-and-why-your-autoscaling-keeps-failing\u002F",[68],"ScaleOpsの解説","では、この構成は「ドキュメント化された推奨されない構成」であり、意図せず組んでしまうエンジニアが後を絶たないと指摘されている。",[25,132,134],{"id":133},"_3-症状としての再起動ループ-vpaのpod再作成との複合要因","3. 症状としての「再起動ループ」— VPAのPod再作成との複合要因",[11,136,137],{},[14,138],{"alt":139,"src":140},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design\u002Fsection03.webp",[11,142,143,144,147],{},"前述のフィードバックループに、VPAのもう一つの性質が重なると、症状はさらに分かりにくくなる。VPAはこれまで、リソース設定の変更を適用するために",[39,145,146],{},"Podを一度削除して再作成する","（evict→再スケジュール）という方式を取ってきた。この再作成とHPAによるレプリカ数の増減が同時多発的に起きると、クラスタ全体で「原因不明の再起動」が連鎖しているように見える。",[11,149,150,151,154,155,160,161,164],{},"この課題に対し、Kubernetesエコシステムは着実に手を打ってきた。",[39,152,153],{},"In-Place Pod Resize","（Podを再作成せずにCPU\u002Fメモリのrequest・limitを書き換える機能）は2026年12月のアップデートでKubernetes 1.35として安定版(GA)に到達し、",[64,156,159],{"href":157,"rel":158},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F12\u002F19\u002Fkubernetes-v1-35-in-place-pod-resize-ga\u002F",[68],"Kubernetes公式ブログ","によれば、v1.27でのアルファ導入から6年以上の開発期間を経て、Podを削除せずにリソース変更を適用できるようになった。VPA側もこれに対応する",[92,162,163],{},"InPlaceOrRecreate","モードを持ち、可能な限りインプレースで更新し、インプレース更新ができない場合のみ従来のeviction（Recreate相当）にフォールバックする。",[11,166,167,168,171],{},"ただしここで誤解してはいけないのは、",[39,169,170],{},"In-Place Pod ResizeはVPAの「再作成コスト」を減らす機能であり、HPAとの計算上のフィードバックループ自体を解消するものではない","という点だ。再起動が減っても、utilizationの分母が動く問題は残る。症状が緩和されたことで「併用しても大丈夫」と誤解し、根本的な設計を見直さないまま運用を続けてしまうケースには注意したい。",[11,173,174,175,180],{},"実際、オートスケーリングが「指標の悪化」を忠実に拾い続けた結果、想定外の規模まで暴走する例は他にもある。",[64,176,179],{"href":177,"rel":178},"https:\u002F\u002Fkomodor.com\u002Fblog\u002Fcompany-autoscales-to-200-nodes-and-crashe-the-app\u002F",[68],"Komodorが紹介した事例","では、あるコード変更が原因でCPU負荷が時間とともに悪化し続け、HPAがそれに反応してPod数を通常の30から4,000まで増やし、ノード数も200まで膨れ上がる4.5時間規模のインシデントに発展した。HPA自体は設計通りに動いていたが、「指標が悪化し続ける根本原因」を見ないまま自動化だけに任せると、是正されないまま規模が際限なく拡大するという教訓は、HPAとVPAの併用問題とも地続きだ。",[25,182,184],{"id":183},"_4-安全に併用する3つの設計パターン","4. 安全に併用する3つの設計パターン",[11,186,187],{},[14,188],{"alt":189,"src":190},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design\u002Fsection04.webp",[11,192,193,194,197],{},"HPAとVPAを「併用してはいけない」わけではない。",[39,195,196],{},"同じメトリクスに対して両方が同時に書き換えを行う","構成を避ければ、安全に組み合わせることができる。実務でよく使われる設計パターンは次の3つだ。",[199,200,201,217],"table",{},[202,203,204],"thead",{},[205,206,207,211,214],"tr",{},[208,209,210],"th",{},"パターン",[208,212,213],{},"設計の要点",[208,215,216],{},"適したケース",[218,219,220,250,263],"tbody",{},[205,221,222,228,247],{},[223,224,225],"td",{},[39,226,227],{},"① updateModeをInitial\u002FOffにする",[223,229,230,231,234,235,238,239,242,243,246],{},"HPAを有効にしたまま、VPAの",[92,232,233],{},"updateMode","は",[92,236,237],{},"Auto","ではなく",[92,240,241],{},"Initial","（Pod作成時のみ推奨値を適用）または",[92,244,245],{},"Off","（推奨値の算出のみ）にする",[223,248,249],{},"既にHPAが稼働中で、VPAはリソース見積りの参考値としてだけ使いたい場合",[205,251,252,257,260],{},[223,253,254],{},[39,255,256],{},"② メトリクスを分離する",[223,258,259],{},"HPAはCPU使用率でスケール、VPAはメモリのrequestのみを最適化する、というように対象メトリクスを分ける",[223,261,262],{},"CPUとメモリで負荷特性が異なり、両方を自動最適化したい場合",[205,264,265,270,276],{},[223,266,267],{},[39,268,269],{},"③ カスタムメトリクス＋推奨モード",[223,271,272,273,275],{},"HPAはリクエスト数などのカスタムメトリクスでスケールし、VPAは",[92,274,245],{},"モードで推奨値の算出に専念する",[223,277,278],{},"トラフィック量に応じたスケールアウトと、リソース見積りの改善を両立したい場合",[11,280,281,282,284,285,290],{},"①の",[92,283,241],{},"モードが安全な理由は単純だ。Podが作成された時点でrequestが固定され、以降は稼働中のPodに対して変更が入らない。つまりHPAが見るutilizationの分母が安定し、フィードバックループが原理的に発生しなくなる。VPA導入支援ツール「Goldilocks」を提供する",[64,286,289],{"href":287,"rel":288},"https:\u002F\u002Fwww.fairwinds.com\u002Fblog\u002Fanswering-your-goldilocks-questions-about-how-hpa-and-vpa-work-together",[68],"Fairwindsの解説","でも、HPAが有効な環境ではVPAのupdater（自動適用コンポーネント）を無効化し、推奨値の算出に専念させる構成が推奨されている。",[11,292,293,294,299,300,305,306,311],{},"②・③のように対象メトリクスやスケーリング指標そのものを分離する設計も、",[64,295,298],{"href":296,"rel":297},"https:\u002F\u002Fcast.ai\u002Fblog\u002Fhpa-vs-vpa\u002F",[68],"Kubernetesのオートスケーリング比較解説","や",[64,301,304],{"href":302,"rel":303},"https:\u002F\u002Fsedai.io\u002Fblog\u002Fhpa-vs-vpa",[68],"クラウド監視・コスト最適化分野の解説記事","で繰り返し紹介されている、実務的に確立されたアプローチだ。",[64,307,310],{"href":308,"rel":309},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-09-vpa-hpa-together-cpu-memory-autoscaling\u002Fview",[68],"運用監視ツールを提供するOneUptimeの実装例","では、「HPAはCPU（またはカスタムメトリクス）でスケール、VPAはメモリのみをOff\u002FInitialモードで最適化する」という役割分担を徹底し、「両方のオートスケーラーが同じメトリクスを監視する構成は絶対に避けるべき」と明言されている。",[11,313,314],{},"いずれの場合も、サイドカーコンテナ（Istioプロキシなど）をVPAの対象から除外する設定を忘れないようにしたい。サイドカーのリソースまでVPAが変更すると、サービスメッシュ側で別の不整合が発生しうる。",[11,316,317,318,322],{},"こうした「どのコントローラがどのメトリクスを担当しているか」の整理は、クラスタが増えるほど属人化しやすい。",[64,319,321],{"href":66,"rel":320},[68],"Kubo Cloud","のCaptain UIは、HPA・VPAを含むオートスケーリング設定を一覧で可視化する機能を備えており、設計レビューの際にブラックボックス化を防ぐ助けになる。",[25,324,325],{"id":325},"まとめ",[11,327,328],{},"HPAとVPAは、どちらもKubernetesのオートスケーリングを支える強力な機能だが、「両方入れれば安心」という発想は危険だ。同じメトリクスに対して両方が同時に判断を下すと、utilizationの分母が動き続けるフィードバックループが生まれ、レプリカ数とリソースrequestが収束しないまま暴走する。",[11,330,331,332,334],{},"対策はシンプルだ。VPAの",[92,333,233],{},"をInitialやOffにしてHPAと役割を分けるか、CPU\u002Fメモリのようにメトリクスそのものを分離するか、どちらかの設計原則を守ればいい。2026年にIn-Place Pod ResizeがGAしたことで再起動のコストは下がったが、それはあくまで症状の緩和であり、根本的な設計判断（どちらの自動化に何を任せるか）を省略できるわけではない。",[11,336,337,338,341,342,346],{},"本番環境でオートスケーリングの設定を増やすたびに、こうした構成上の落とし穴をレビューする工数は無視できない。",[64,339,69],{"href":66,"rel":340},[68],"のCaptain UIなら、HPA・VPAを含むワークロードの自動化設定を可視化された管理画面で確認でき、どのコントローラが何を書き換えているのかをブラックボックス化せずに把握できる。EKSやAKSで同様の構成をゼロから設計・運用する場合と比べ、",[64,343,345],{"href":66,"rel":344},[68],"月額48,000円〜という価格","でK3sベースの本格的なKubernetes運用を始められる点も、こうした運用の落とし穴に時間を取られたくないチームには魅力だろう。",[11,348,349,350,355],{},"HPAとVPAの併用で悩んでいるなら、まずはどちらのメトリクスをどちらの自動化に任せるかを整理するところから始めてほしい。そのうえでマネージドな運用基盤を検討する場合は、",[64,351,354],{"href":352,"rel":353},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[68],"お問い合わせ","から相談してみるのも一つの選択肢だ。",{"title":94,"searchDepth":357,"depth":357,"links":358},2,[359,360,361,362,363],{"id":27,"depth":357,"text":28},{"id":73,"depth":357,"text":74},{"id":133,"depth":357,"text":134},{"id":183,"depth":357,"text":184},{"id":325,"depth":357,"text":325},"2026-10-07","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design",{"title":5,"description":365},"blog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design",[375,376,377,378,379],"k3s","kubernetes","hpa","vpa","autoscaling","v0p6eW1DPZ3uc8JUfb7IsWOFaC7_SFXeuxejJt_rB2A",[382,389,397,404,412,421],{"path":383,"title":384,"description":385,"date":386,"tags":387},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[375,376,377,378,379,388],"metrics-server",{"path":390,"title":391,"description":392,"date":393,"tags":394},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[375,376,377,395,379,396],"containerresource","service-mesh",{"path":398,"title":399,"description":400,"date":401,"tags":402},"\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",[375,376,378,379,403],"cgroup",{"path":405,"title":406,"description":407,"date":408,"tags":409},"\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",[375,376,377,410,379,411],"prometheus-adapter","observability",{"path":413,"title":414,"description":415,"date":416,"tags":417},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[375,376,418,377,379,419,420],"keda","event-driven-scaling","scaledobject",{"path":422,"title":423,"description":424,"date":425,"tags":426},"\u002Fblog\u002Fja\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","K3sでイベント駆動オートスケーリングが必要になったら。HPAとKEDA、どちらを選ぶかの判断基準","K3sでHPAのCPU\u002Fメモリベースのスケーリングでは対応しきれないイベント駆動ワークロードに直面したとき、標準のHPAを使い続けるべきか、CNCF GraduatedプロジェクトのKEDAを導入すべきか。3つの判断基準とK3s環境での注意点を整理する。","2026-09-10",[375,376,377,418,379],1792592616020]