[{"data":1,"prerenderedAt":302},["ShallowReactive",2],{"blog-en-hpa-vpa-aep-5342-multidimensional-pod-autoscaler":3,"blog-related-en-hpa-vpa-aep-5342-multidimensional-pod-autoscaler":256,"blog-en-hpa-vpa-aep-5342-multidimensional-pod-autoscaler-alt":245},{"id":4,"title":5,"author":6,"body":7,"date":239,"description":240,"extension":241,"image":242,"locale":243,"meta":244,"navigation":245,"path":246,"seo":247,"stem":248,"tags":249,"__hash__":255},"blog\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler.md","HPA and VPA Conflicts in Kubernetes: How AEP-5342 Aims to Fix What GKE's MPA Couldn't","Kubo Team",{"type":8,"value":9,"toc":229},"minimark",[10,15,19,26,37,52,56,65,71,79,96,100,112,118,125,134,138,149,155,164,183,187,195,201,208,212,215,222],[11,12,14],"h2",{"id":13},"_1-why-running-hpa-and-vpa-together-has-always-been-considered-risky","1. Why Running HPA and VPA Together Has Always Been Considered Risky",[16,17,18],"p",{},"Anyone operating Kubernetes eventually considers combining the Horizontal Pod Autoscaler (HPA) with the Vertical Pod Autoscaler (VPA). Both controllers automatically decide how resources should be allocated, but when they target the same metric, they end up destabilizing each other's decisions.",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection01.webp",[16,27,28,29,36],{},"Specifically, HPA decides replica counts based on CPU utilization, while VPA rewrites the very CPU request value that makes up the denominator of that utilization calculation. The result is \"thrashing\" — scale-ups and scale-downs alternating in an unstable loop (",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fhorizontal-pod-autoscale\u002F",[34],"nofollow","Kubernetes' official documentation"," explains how HPA calculates utilization based on resource requests).",[16,38,39,40,45,46,51],{},"This problem isn't new. Multiple technical write-ups have repeatedly pointed out that running HPA and VPA against the same CPU or memory metric causes conflict (",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-09-vpa-hpa-together-cpu-memory-autoscaling\u002Fview",[34],"one explainer on combining VPA and HPA","). What makes it tricky is that this kind of conflict is hard to notice unless you're continuously watching replica-count graphs — without an environment like ",[30,47,50],{"href":48,"rel":49},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo",", where autoscaling behavior is visualized by default, teams often only discover it after an incident report. So how close are we to actually solving a problem that's been discussed for years?",[11,53,55],{"id":54},"_2-gkes-early-answer-how-the-multidimensional-pod-autoscaler-mpa-works","2. GKE's Early Answer: How the Multidimensional Pod Autoscaler (MPA) Works",[16,57,58,59,64],{},"Google Kubernetes Engine (GKE) was the first to offer a practical answer. GKE provides a single custom resource called the \"Multidimensional Pod Autoscaler (MPA),\" which unifies horizontal scaling based on CPU utilization and vertical scaling based on memory usage into one feedback loop (",[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's official blog",").",[16,66,67],{},[22,68],{"alt":69,"src":70},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection02.webp",[16,72,73,74,64],{},"Rather than running HPA and VPA as two independent controllers, MPA separates target metrics from the start — \"CPU goes horizontal, memory goes vertical\" — and lets a single controller manage both. According to the official documentation, MPA requires GKE version 1.19.4-gke.1700 or later, and Standard clusters must separately enable vertical scaling (",[30,75,78],{"href":76,"rel":77},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fmultidimensional-pod-autoscaling",[34],"Google Cloud's configuration guide",[16,80,81,82,86,87,91,92,95],{},"There are two important limitations, though. First, MPA is a ",[83,84,85],"strong",{},"GKE-exclusive feature"," (using the ",[88,89,90],"code",{},"autoscaling.gke.io"," API group), unavailable on EKS, AKS, on-premises clusters, or K3s-based environments. Second, vertical scaling currently ",[83,93,94],{},"covers memory only"," — CPU vertical scaling isn't supported. What GKE demonstrated is one implementation, not an answer for the Kubernetes ecosystem as a whole.",[11,97,99],{"id":98},"_3-kubernetes-itself-is-moving-aep-5342-and-the-push-for-a-distribution-agnostic-design","3. Kubernetes Itself Is Moving: AEP-5342 and the Push for a Distribution-Agnostic Design",[16,101,102,103,106,107,64],{},"A step beyond GKE's approach is happening inside the ",[88,104,105],{},"kubernetes\u002Fautoscaler"," project, which maintains Kubernetes' own autoscaler components. A proposal called \"AEP-5342\" for a Multi-dimensional Pod Autoscaler has advanced to \"implementable\" status as of 2026 (",[30,108,111],{"href":109,"rel":110},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fautoscaler\u002Fblob\u002Fmaster\u002Fmultidimensional-pod-autoscaler\u002FAEP.md",[34],"the AEP document in the kubernetes\u002Fautoscaler repository",[16,113,114],{},[22,115],{"alt":116,"src":117},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection03.webp",[16,119,120,121,124],{},"The biggest difference from GKE's MPA is that this proposal is designed to be ",[83,122,123],{},"vendor-neutral from the ground up",". AEP-5342 separates a \"Recommender\" layer that generates resource recommendations from an \"Updater\u002FAdmission Controller\" layer that actually applies them to Pods, unifying both vertical and horizontal scaling decisions into a single feedback loop to resolve the contradiction. Because it's designed to reuse existing HPA\u002FVPA libraries, the same mechanism could eventually become available on other distributions, including K3s.",[16,126,127,128,133],{},"Industry commentary frames this design as addressing the root cause: \"HPA and VPA compete instead of cooperating\" (",[30,129,132],{"href":130,"rel":131},"https:\u002F\u002Fzesty.co\u002Fblog\u002Fhow-multi-dimensional-autoscaling-fixes-kubernetes-resource-waste\u002F",[34],"one analysis of the multi-dimensional autoscaling problem","). That said, the AEP is still only at the \"implementable\" stage — it isn't something you can use on K3s today. The next section covers what you can actually do while you wait for it.",[11,135,137],{"id":136},"_4-what-k3s-and-kubo-users-can-do-right-now","4. What K3s and Kubo Users Can Do Right Now",[16,139,140,141,144,145,148],{},"Until AEP-5342 lands as a stable feature across distributions, the realistic option for K3s\u002FKubo environments is to manually separate metric responsibilities. Specifically, dedicate VPA to ",[83,142,143],{},"memory only"," and HPA to ",[83,146,147],{},"CPU only (or an external metric)",", effectively reproducing by hand what GKE's MPA does automatically.",[16,150,151],{},[22,152],{"alt":153,"src":154},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection04.webp",[16,156,157,158,163],{},"VPA's updateMode comes in four flavors — Off, Initial, Auto, and Recreate — and when combining it with HPA, \"Initial\" (which only adjusts resources for newly created Pods) or \"Off\" (which only surfaces recommendations) are considered the safer choices (",[30,159,162],{"href":160,"rel":161},"https:\u002F\u002Fwww.devzero.io\u002Fblog\u002Fkubernetes-vpa",[34],"one explainer on how VPA works","). The deprecated \"Auto\" mode, by contrast, tends to trigger frequent Pod evictions and restarts when combined with HPA, amplifying instability.",[16,165,166,167,172,173,178,179,182],{},"It's also worth noting that Kubernetes beta-graduated \"In-place Pod Resize\" in v1.33 (2025), allowing CPU and memory requests to change without restarting containers (",[30,168,171],{"href":169,"rel":170},"https:\u002F\u002Fv1-34.docs.kubernetes.io\u002Fblog\u002F2025\u002F05\u002F16\u002Fkubernetes-v1-33-in-place-pod-resize-beta\u002F",[34],"the official Kubernetes blog","). This underlying technology supports zero-downtime VPA operation and also lays groundwork for integrated autoscalers like the one AEP-5342 envisions. Because K3s runs all control-plane components as a single process, its metrics are naturally consolidated into a single Prometheus registry (",[30,174,177],{"href":175,"rel":176},"https:\u002F\u002Fdocs.k3s.io\u002Fja\u002Freference\u002Fmetrics",[34],"K3s's official documentation",") — and in an environment like ",[30,180,50],{"href":48,"rel":181},[34],", where Prometheus and Grafana come built in, it becomes much easier to verify on a dashboard whether this kind of responsibility-split design is actually working. Being able to watch VPA's recommendations alongside HPA's replica-count trend side by side is the key signal for whether the design is doing its job.",[11,184,186],{"id":185},"_5-what-this-trend-means-for-keda","5. What This Trend Means for KEDA",[16,188,189,190,64],{},"As HPA and VPA move toward integration, the role of KEDA (Kubernetes Event-driven Autoscaling) — which operates in a different context entirely — becomes relatively clearer. The decision rule is simple: if the scaling trigger is resource pressure like CPU or memory, HPA (and eventually an MPA-like integrated approach) is the right tool; if the trigger is an external signal such as queue depth, KEDA is the right tool (",[30,191,194],{"href":192,"rel":193},"https:\u002F\u002Fwww.plural.sh\u002Fblog\u002Fkeda-vs-hpa-guide\u002F",[34],"a guide to choosing between HPA and KEDA",[16,196,197],{},[22,198],{"alt":199,"src":200},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Fsection05.webp",[16,202,203,204,207],{},"In other words, what AEP-5342 is aiming for is consolidating resource-driven scaling into a single mechanism — it doesn't compete with the event-driven scaling that KEDA handles. If anything, as HPA\u002FVPA integration progresses, KEDA can focus more squarely on the event-driven workloads it was built for. Verifying a setup that combines multiple autoscalers like this takes real effort to test individually, which is exactly the kind of scenario where ",[30,205,50],{"href":48,"rel":206},[34],"'s built-in GitOps support and standard Helm tooling can shorten the verification cycle.",[11,209,211],{"id":210},"summary","Summary",[16,213,214],{},"The warning that running HPA and VPA together is \"risky\" remains technically true today. But it's no longer a fixed conclusion — GKE's MPA implementation and the AEP-5342 proposal moving through Kubernetes itself suggest the industry is in a transitional period, actively working toward a resolution.",[16,216,217,218,221],{},"For K3s\u002FKubo environments, until AEP-5342 becomes available as a stable feature, separating VPA (memory-only) from HPA (CPU-only) responsibilities is enough to keep the risks of running both in check. These kinds of fine-grained configuration decisions are exactly the ones that get overlooked in environments without good visibility. ",[30,219,50],{"href":48,"rel":220},[34]," visualizes HPA\u002FVPA behavior through its Captain UI, making it easier to catch early signs of conflict — like unusually frequent replica-count swings — during the verification stage.",[16,223,224,225,228],{},"If you want to test this kind of autoscaling design on a K3s-based cluster, ",[30,226,50],{"href":48,"rel":227},[34]," can get you a Prometheus+Grafana-equipped environment running for as little as ¥48,000 a month. While keeping an eye on AEP-5342's progress, it's worth starting with the metric-separation design you can apply today.",{"title":230,"searchDepth":231,"depth":231,"links":232},"",2,[233,234,235,236,237,238],{"id":13,"depth":231,"text":14},{"id":54,"depth":231,"text":55},{"id":98,"depth":231,"text":99},{"id":136,"depth":231,"text":137},{"id":185,"depth":231,"text":186},{"id":210,"depth":231,"text":211},"2026-10-27","Running HPA and VPA together has long been considered risky in Kubernetes. GKE's Multidimensional Pod Autoscaler and the upstream AEP-5342 proposal point toward a resolution. Here's what K3s and Kubo users can do today.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler\u002Ftitle.webp","en",{},true,"\u002Fblog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler",{"title":5,"description":240},"blog\u002Fen\u002Fhpa-vpa-aep-5342-multidimensional-pod-autoscaler",[250,251,252,253,254],"k3s","kubernetes","hpa","vpa","autoscaling","dZhFzwTRKabb-DA_2QfnPlmcYXRtfQqYmvjDziApQOI",[257,263,270,278,285,293],{"path":258,"title":259,"description":260,"date":261,"tags":262},"\u002Fblog\u002Fen\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"Running Both Feels Safer\" Is the Trap. Why Combining HPA and VPA in Kubernetes Can Send Autoscaling Into a Spiral","Enabling both HPA and VPA in Kubernetes can make two well-intentioned automations fight each other, sending autoscaling into an endless spiral. Here's why the conflict happens, and how to combine them safely with updateMode and metric separation.","2026-10-07",[250,251,252,253,254],{"path":264,"title":265,"description":266,"date":267,"tags":268},"\u002Fblog\u002Fen\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","Your HPA Config Is Correct. So Why Won't Pods Scale? The Real Cause of 'Unknown Metrics' in K3s and the HPA\u002FVPA Death Spiral","You set up an HPA in K3s and Pods still won't scale. The usual culprits are unset resource requests silently disabling metrics, and a self-reinforcing HPA\u002FVPA feedback loop. Here's how to diagnose and fix it.","2026-09-02",[250,251,252,253,254,269],"metrics-server",{"path":271,"title":272,"description":273,"date":274,"tags":275},"\u002Fblog\u002Fen\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPA Was Scaling on the Sidecar's Share Too. The ContainerResource Blind Spot in Kubernetes","Kubernetes HPA sums resource usage across every container in a Pod, so Istio sidecars and logging agents dilute the scaling decision. Here's how the ContainerResource metric fixes it, in a K3s\u002FKubo context.","2026-10-21",[250,251,252,276,254,277],"containerresource","service-mesh",{"path":279,"title":280,"description":281,"date":282,"tags":283},"\u002Fblog\u002Fen\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPA InPlaceOrRecreate Didn't Stop the Restart. Testing InPlacePodVerticalScaling on K3s","Does VPA's InPlaceOrRecreate mode and In-Place Pod Resize really avoid Pod restarts? We test QoS class constraints and the cgroup v1 trap on K3s with real configs and kubectl commands.","2026-10-17",[250,251,253,254,284],"cgroup",{"path":286,"title":287,"description":288,"date":289,"tags":290},"\u002Fblog\u002Fen\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","Question Your discoveryInterval: Why K3s HPA Keeps Scaling on Stale Metrics from Prometheus Adapter","K3s HPA won't scale even though CPU usage looks normal. The culprit is a mismatch between Prometheus Adapter's metrics-relist-interval\u002Fmetrics-max-age and the HPA sync-period. Here's the three-layer delay chain and how to diagnose it.","2026-10-12",[250,251,252,291,254,292],"prometheus-adapter","observability",{"path":294,"title":295,"description":296,"date":297,"tags":298},"\u002Fblog\u002Fen\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU Usage Looks Normal, But Requests Are Piling Up. When to Add KEDA to HPA in Kubernetes","KEDA and HPA aren't an either-or choice. When event-driven workloads grow on K3s\u002FKubernetes, here's why HPA alone hits its limits and how to decide when to add KEDA alongside it.","2026-10-03",[250,251,299,252,254,300,301],"keda","event-driven-scaling","scaledobject",1793798716827]