Kubernetes Autoscaling 2026: HPA, VPA, KEDA, and Karpenter in Concert

In production clusters, the classic Horizontal Pod Autoscaler (HPA) has long ceased to be sufficient. Modern Kubernetes environments demand a finely tuned interplay of multiple autoscalers: HPA for CPU-based replica scaling, VPA for vertical right-sizing of pod resources, KEDA for event-driven workloads, and Karpenter for dynamic node provisioning. This article provides guidance on which tool is suitable for which use case – and how the tools can be safely combined.

The Three Scaling Levels in the Kubernetes Cluster

Autoscaling in Kubernetes operates on three independent levels. HPA and KEDA scale the number of pod replicas (application level), VPA adjusts the CPU and memory requests per pod (pod size), while Cluster Autoscaler or Karpenter change the number of cluster nodes (infrastructure level). The common mistake is using a tool for the wrong level: An HPA can increase the replica count, but cannot provision new nodes – if the existing nodes are fully utilized, additional pods remain in Pending status. Similarly, KEDA can detect queue depth, but cannot correct misconfigured resource requests. Clear separation of responsibilities is the first step toward a robust autoscaling design.

HPA: Proven, but with Pitfalls

The Horizontal Pod Autoscaler is the standard tool for CPU- and memory-based scaling. In version autoscaling/v2, it supports not only resource metrics but also custom metrics like requests per second or queue lengths, provided a metrics adapter (e.g., Prometheus Adapter) is installed in the cluster.

A frequently underestimated parameter is the stabilization window: By default, HPA scales up aggressively, but also scales down quickly, which can lead to flapping. It is recommended to set stabilizationWindowSeconds to 300 seconds for scale-down with a maximum of 10% pod reduction per minute, while scale-up should occur without delay. This configuration prevents short load spikes from causing unnecessary up and down movements.

KEDA: Event-Driven Scaling at a New Level

KEDA (Kubernetes Event-Driven Autoscaling) extends the HPA concept with over 60 native scalers – from Kafka Consumer Lag to RabbitMQ queue depth to AWS SQS or Redis list length. Unlike the classic HPA, KEDA can scale pods down to zero when no events are pending and spin them back up as needed. This is especially valuable for batch jobs, background workers, and seasonal workloads.

Since version 2.16 (September 2026), KEDA supports file-based authentication for ClusterTriggerAuthentication and introduces new Kubernetes resource scalers. The next planned version is scheduled for January 2027. For HTTP-based workloads, the KEDA HTTP Add-on is available, which buffers incoming requests and brings pods out of standby when needed – a real alternative to traditionally always-running API gateway instances.

VPA 2026: In-Place Resizing Ends the Era of Pod Restarts

The Vertical Pod Autoscaler made a decisive leap in 2025/2026: Since Kubernetes 1.35 (December 2025), In-Place Pod Resizing is GA, and VPA 1.2+ offers the InPlaceOrRecreate mode. This allows pods to be live-adjusted in their resource requests without necessarily restarting – the biggest obstacle to VPA deployment in production has thus been removed.

Nevertheless, risks remain: The well-known VPA/HPA death spiral occurs when both tools access the same CPU/memory metrics. VPA lowers requests based on historical data, while HPA interprets the same absolute utilization as a higher percentage (because the request denominator became smaller) and scales horizontally upward. The remedy is simple: Use HPA on custom metrics (RPS, queue depth), use VPA only for CPU/memory – or run VPA in Off mode to collect recommendations only, without automatically intervening.

Karpenter: Next-Generation Node Autoscaling

At the cluster level, Karpenter has largely replaced the Cluster Autoscaler in AWS environments. Instead of relying on predefined node groups, Karpenter provisions nodes directly via the cloud API and automatically selects the most cost-effective instance type for pending pods. Consolidation of underutilized nodes is aggressive – according to the vendor, with 40–60% better node utilization compared to the classic Cluster Autoscaler. For GKE users, the Cluster Autoscaler remains the default choice for now, as a production-ready Karpenter provider for Google Cloud is not yet available.

Architecture Recommendations by Workload Type

For a web API (stateless, latency-sensitive), the recommendation is HPA on CPU + RPS custom metric, VPA in Off mode (collect recommendations), and Karpenter with a mix of Spot and On-Demand instances. Background workers listening on queues benefit from KEDA with scale-to-zero combined with Spot instances – failures of individual pods are covered by job retry mechanisms. ML inference workloads with GPUs scale best via KEDA (HTTP or custom Prometheus metrics) with a longer cooldown, as GPU nodes are expensive to spin up.

Conclusion

Kubernetes autoscaling in 2026 is no longer an either-or proposition. The key question is not “Which autoscaler is the best?” but “Which signal scales which object?”. HPA, VPA, KEDA, and Karpenter address different levels and signals, and only reveal their strength through intelligent interplay. The most common mistake remains reaching for HPA for every workload – those who instead analyze the scaling signal and choose the right tool will run more cost-efficiently and stably.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.