When HPA Isn't Enough: What Actually Happens on K3s
If you've run a K3s cluster and configured the Horizontal Pod Autoscaler (HPA), you may have run into a familiar frustration: it just doesn't scale the way you expect. CPU usage looks perfectly normal, yet your message queue keeps piling up requests. Or the opposite happens — pods dutifully scale out based on CPU usage, while the actual backlog barely moves.
This isn't a misconfiguration — it's a structural limitation of how HPA works. According to the official Kubernetes API reference, HPA supports four metric types — resource, pods, object, and external — but the default metric it falls back to is CPU utilization at 80%. To handle signals like queue depth or event counts, which can't be observed from inside a Pod, you need additional design work.
This gap shows up especially often on K3s. Because K3s ships with metrics-server built in, getting CPU/memory-based HPA running is remarkably easy. But that very ease is often what leads teams down the path of "start with HPA" → "hit a wall once workloads become event-driven."
This article walks through a 3-point decision framework for when you've hit the limits of autoscaling on K3s: should you keep extending standard HPA, or adopt KEDA (Kubernetes Event-driven Autoscaling)? How much observability infrastructure you need to build yourself is also worth thinking about early, when you're choosing a managed Kubo Kubernetes-as-a-Service platform in the first place.
What Actually Differs Between HPA and KEDA
Let's start with the premise: KEDA does not replace HPA. As the official KEDA site states, KEDA is designed to "work alongside standard Kubernetes components like the Horizontal Pod Autoscaler and extend its functionality without overwriting or duplicating it." KEDA itself sits in front of the HPA controller, translating external event sources into the Kubernetes metrics API.
Here's how the two compare in practice.
How Standard HPA Works
- Reads CPU/memory utilization via metrics-server and adjusts pod counts accordingly
- To use custom metrics, you need an additional component like Prometheus Adapter implementing the custom.metrics.k8s.io API
- Historically, scaling in to zero replicas was not supported
How KEDA Works
- As a CNCF Graduated project, KEDA natively supports 60+ event sources (scalers), including Kafka, RabbitMQ, Prometheus, and various cloud queues
- A ScaledObject custom resource defines both what to scale and which event should trigger scaling
- When events drop to zero, KEDA can scale all the way down to zero replicas. Google Cloud's tutorial for GKE walks through examples using Pub/Sub and GPU inference workloads for scale-to-zero
That premise, however, has started to shift in 2026. The Kubernetes v1.37 release blog announced that HPA itself now supports scaling down to zero replicas using object/external metrics, enabled by default as a Beta feature. In other words, "HPA can't scale to zero" is no longer a safe assumption going forward. That said, KEDA's ready-made library of 60+ event source connectors and its broad authentication provider support remain a real practical advantage today.
Which Should You Choose? A 3-Point Decision Framework
When deciding between HPA and KEDA, three questions make the decision much clearer.
Question 1: Can your scaling signal be explained by resource utilization?
If your workload is a typical web app where request volume roughly correlates with CPU usage, standard HPA is sufficient. But if you need to scale based on a signal that moves independently of a pod's own resource usage — like a message queue backlog or the number of pending jobs — KEDA's event source integrations are the better fit.
Question 2: Is scale-to-zero a hard requirement?
For batch workloads with zero traffic overnight or on weekends, or GPU-backed inference workloads where idle cost is high, whether you can scale all the way down to zero directly affects your bill. As noted above, core Kubernetes is catching up here as a Beta feature, but as a CNCF Graduated project, KEDA already has production track record at organizations like FedEx, Reddit, and Xbox — that's still a meaningful gap in operational maturity today.
Question 3: Can your team maintain a custom metrics pipeline?
Using custom metrics with HPA alone means building and operating an adapter layer like Prometheus Adapter yourself. Mapping Prometheus queries to Kubernetes resources via configuration rules takes more operational effort than it looks like on paper. KEDA collapses this into a single ScaledObject definition, so the smaller your ops team — or the less you have a dedicated observability specialist — the bigger the relative benefit of adopting KEDA.
What to Watch for When Adopting KEDA on K3s
Since K3s ships with metrics-server built in, CPU/memory-based HPA works right out of the box. When adding KEDA on top of that, there are a few things worth watching for.
- Avoid conflicting with an existing HPA: KEDA generates an HPA resource internally via its ScaledObject. Make sure you don't define both a manual HPA and a KEDA ScaledObject for the same Deployment or StatefulSet.
- Choose your metric source carefully: If you're already running Prometheus as your monitoring stack, using KEDA's Prometheus scaler minimizes the number of new components you need to add.
- Watch resource constraints at the edge or on-prem: In edge or on-premise environments with limited node resources, factor in the resident cost of the KEDA Operator itself. Not every node can afford to host additional event-source components, so how much monitoring and autoscaling capability comes built-in becomes a real factor when choosing your environment.
This question — how much observability infrastructure you want to build yourself — connects directly to whether a K3s-based managed service makes sense for your team. Kubo ships with Prometheus + Grafana built in on top of K3s, so you don't need to build a monitoring stack from scratch before using KEDA's Prometheus scaler. For teams just starting to explore custom metrics integration, that built-in coverage translates directly into lower upfront setup cost.
If data sovereignty requirements mean your workloads have to stay on-premise, Kubo On-Premise lets you bring the same K3s-based setup into your own infrastructure, making it easier to port a KEDA design you've validated in the cloud into an on-prem environment.
Summary
HPA remains the default choice for workloads whose scaling signal can be explained by CPU/memory usage. But once you're dealing with event-driven workloads or a hard requirement for scale-to-zero, adopting KEDA starts to make sense.
To recap the three questions:
- Can your scaling signal be explained by resource utilization, or does it depend on an external event?
- Is scale-to-zero a hard requirement?
- Can your team realistically maintain a custom metrics pipeline?
Building a Prometheus Adapter and KEDA monitoring stack from scratch on EKS or AKS is, by itself, a project that takes real time to get off the ground. With Kubo, you get the full feature set of Kubernetes on a K3s base, with Prometheus + Grafana built in from day one — so you can try extending from HPA to KEDA at a predictable cost starting around ¥48,000/month. Start with HPA, and when you hit an event-driven workload that HPA can't handle well, that's the moment to evaluate extending to KEDA.