Kubernetes autoscaling in 2026 means running HPA, VPA, KEDA and Karpenter together

A guide published on dev.to makes the case that the Horizontal Pod Autoscaler alone no longer suffices for production Kubernetes, and sets out how HPA, VPA, KEDA and Karpenter can be combined safely when each tool is assigned to the layer of the stack it was built for.

Autoscaling happens on three levels

The article frames cluster autoscaling as three independent levels: replica count, handled by HPA and KEDA; per-pod CPU and memory requests, handled by VPA; and node count, handled by the Cluster Autoscaler or Karpenter. According to the author, the most common design error is deploying a tool at the wrong level. An HPA can raise the replica count but cannot create nodes, so if existing nodes are fully utilised the extra pods simply sit in Pending. Likewise, KEDA can read queue depth but cannot fix resource requests that were misconfigured in the first place.

HPA: proven, but tune the scale-down

HPA remains the standard choice for CPU- and memory-based scaling, and with autoscaling/v2 it can also react to custom metrics such as requests per second or queue length, provided a metrics adapter like the Prometheus Adapter is installed. The article singles out the stabilisation window as an underrated setting: it recommends a 300-second window for scale-down with at most 10% of pods removed per minute, while leaving scale-up immediate. That configuration, the author writes, stops short load spikes from producing constant up-and-down flapping.

KEDA: event-driven scaling and scale-to-zero

KEDA extends the HPA model with more than 60 native scalers, covering Kafka consumer lag, RabbitMQ queue depth, AWS SQS and Redis list length, among others. Unlike classic HPA, it can scale workloads down to zero when no events are pending, which the article says suits batch jobs, background workers and seasonal traffic. The piece notes that KEDA 2.16, released in September 2026, adds file-based authentication for ClusterTriggerAuthentication and new Kubernetes resource scalers, with the next release planned for January 2027. For HTTP workloads, a KEDA add-on buffers incoming requests and brings pods out of standby as needed, which the author presents as an alternative to always-running API gateway instances.

VPA: in-place resizing removes the restart penalty

The Vertical Pod Autoscaler made its decisive leap recently, according to the article: in-place pod resizing reached general availability in Kubernetes 1.35 in December 2025, and VPA 1.2 and later offer an InPlaceOrRecreate mode that adjusts resource requests without necessarily restarting the pod. That removes what the author calls the biggest obstacle to running VPA in production.

The well-known interaction hazard between the two tools remains, however. When HPA and VPA both read the same CPU or memory metrics, VPA lowers requests based on history, HPA then interprets the same absolute usage as a higher percentage and scales horizontally, and the two feed each other. The recommended remedies are to drive HPA with custom metrics such as RPS or queue depth while VPA owns CPU and memory, or to run VPA in Off mode so it only collects recommendations without acting on them.

Karpenter: node provisioning without node groups

At the infrastructure layer, the article says Karpenter has largely displaced the Cluster Autoscaler on AWS. Rather than working through predefined node groups, Karpenter provisions nodes directly via the cloud API, picks the most cost-effective instance type for pending pods and aggressively consolidates underused nodes. The vendor behind it claims 40–60% better node utilisation than the classic Cluster Autoscaler, a figure the article relays as a vendor claim. On Google Kubernetes Engine, the Cluster Autoscaler remains the default for now because no production-ready Karpenter provider exists for Google Cloud.

Recommended pairings by workload

The guide closes with per-workload recipes. A stateless, latency-sensitive web API should pair HPA on CPU plus an RPS custom metric with VPA in Off mode, running on Karpenter nodes mixing Spot and On-Demand capacity. Queue-listening background workers fit KEDA with scale-to-zero on Spot instances, with job retry mechanisms absorbing individual pod losses. GPU-based ML inference scales best through KEDA using HTTP or custom Prometheus metrics with a longer cooldown, since GPU nodes are expensive to bring up.

Why it matters

The piece reflects how far Kubernetes capacity management has shifted from a single-dial problem to a multi-tool discipline. The useful question is no longer which autoscaler is best, the author argues, but which signal scales which object. Teams that default to HPA for every workload — identified as the most common mistake — risk both instability and overspend, while a deliberate split of responsibilities across the replica, pod and node layers can improve cost efficiency and stability at the same time.