1. Why Running HPA and VPA Together Has Always Been Considered Risky
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.
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 (Kubernetes' official documentation explains how HPA calculates utilization based on resource requests).
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 (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 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?
2. GKE's Early Answer: How the Multidimensional Pod Autoscaler (MPA) Works
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 (Google Cloud's official blog).
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 (Google Cloud's configuration guide).
There are two important limitations, though. First, MPA is a GKE-exclusive feature (using the autoscaling.gke.io API group), unavailable on EKS, AKS, on-premises clusters, or K3s-based environments. Second, vertical scaling currently 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.
3. Kubernetes Itself Is Moving: AEP-5342 and the Push for a Distribution-Agnostic Design
A step beyond GKE's approach is happening inside the kubernetes/autoscaler 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 (the AEP document in the kubernetes/autoscaler repository).
The biggest difference from GKE's MPA is that this proposal is designed to be vendor-neutral from the ground up. AEP-5342 separates a "Recommender" layer that generates resource recommendations from an "Updater/Admission 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/VPA libraries, the same mechanism could eventually become available on other distributions, including K3s.
Industry commentary frames this design as addressing the root cause: "HPA and VPA compete instead of cooperating" (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.
4. What K3s and Kubo Users Can Do Right Now
Until AEP-5342 lands as a stable feature across distributions, the realistic option for K3s/Kubo environments is to manually separate metric responsibilities. Specifically, dedicate VPA to memory only and HPA to CPU only (or an external metric), effectively reproducing by hand what GKE's MPA does automatically.
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 (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.
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 (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 (K3s's official documentation) — and in an environment like Kubo, 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.
5. What This Trend Means for KEDA
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 (a guide to choosing between HPA and KEDA).
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/VPA 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 Kubo's built-in GitOps support and standard Helm tooling can shorten the verification cycle.
Summary
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.
For K3s/Kubo 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. Kubo visualizes HPA/VPA behavior through its Captain UI, making it easier to catch early signs of conflict — like unusually frequent replica-count swings — during the verification stage.
If you want to test this kind of autoscaling design on a K3s-based cluster, Kubo 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.