Kubernetes clusters waste money in a specific, predictable way: nodes sit half-empty while an autoscaler waits for the next scheduling cycle to notice. Three open-source tools now compete to fix that problem in 2026, though they don’t all fix the same part of it. Karpenter, the AWS-born node provisioner, has settled on a stable v1.14.0 release and now runs GA providers on three clouds. Cluster Autoscaler, the decade-old Kubernetes SIG project, still backs the majority of production clusters that never switched. And KEDA, a CNCF Graduated project built by Microsoft, scales pods rather than nodes, and can scale them all the way down to zero. Picking the right combination, or picking wrong, shows up directly in your cloud bill and your on-call rotation. This comparison covers the specs, the provisioning-speed benchmarks from multiple independent tests, real pricing implications, and a step-by-step migration path for teams moving off Cluster Autoscaler this year.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Kubernetes Autoscaling Needs More Than One Tool
Kubernetes ships with the Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA) built in, and both work at the pod level: they add replicas or resize containers, but they can’t do anything if the cluster has no spare capacity to schedule those pods onto. That gap is what node-level autoscalers exist to close. When a pod goes unschedulable because every node is full, something has to talk to the cloud provider’s compute API, request a new virtual machine, wait for it to join the cluster, and only then let the scheduler place the pending pod.
Cluster Autoscaler was the first widely adopted answer to that problem, built by Kubernetes SIG Autoscaling back in 2016. It watches for unschedulable pods, then scales a pre-defined node group, such as an AWS Auto Scaling Group, an Azure Virtual Machine Scale Set, or a GCP Managed Instance Group, up or down. Karpenter, which AWS open-sourced in 2021, took a different approach: skip the node group abstraction entirely and call the cloud’s compute API directly, choosing instance types and capacity (on-demand or spot) in real time based on what the pending pods actually need.
KEDA solves an adjacent but different problem. Instead of scaling nodes, it scales the number of pod replicas based on external event sources: a Kafka topic’s consumer lag, an SQS queue depth, a Prometheus metric, an HTTP request rate. Crucially, KEDA can scale a deployment down to zero replicas when there’s no work to do, something neither Karpenter nor Cluster Autoscaler does on its own, since both need at least one pod’s worth of demand before they’ll touch node capacity. In most production clusters, these tools aren’t rivals so much as different layers of the same stack: KEDA decides how many pods should exist, and Karpenter or Cluster Autoscaler decides how much node capacity needs to exist to run them.
The built-in HPA has existed since Kubernetes 1.1 and still handles the simplest case well: scale replicas up when CPU or memory crosses a threshold. What it can’t do is react to signals that live outside the cluster, a queue backing up in a separate messaging system, or a scheduled batch window, or a custom business metric like pending orders. That limitation is exactly why KEDA exists as a layer on top of HPA rather than a replacement for it, and why node autoscalers evolved as a wholly separate concern from pod autoscalers rather than one tool trying to do both jobs at once.
What Is Karpenter? AWS’s Node Provisioning Engine
Karpenter started as an internal AWS project and went public in 2021 with a specific complaint in mind: Cluster Autoscaler’s dependency on fixed node groups meant capacity decisions were made in advance, not in response to what workloads actually needed at the moment they needed it. Karpenter instead watches the scheduler for unschedulable pods, calculates the cheapest and most appropriate combination of instance types and capacity to satisfy them, and calls the EC2 Fleet API directly rather than resizing a pre-configured Auto Scaling Group.
That design choice matters more than it sounds. A node group has to be pre-sized around a guess about what instance type a future pod will need, which pushes teams toward either over-provisioning for headroom or running many narrowly-scoped groups to cover different workload shapes. Karpenter sidesteps the guesswork by evaluating the actual pending pod’s CPU, memory, and scheduling constraints at the moment it needs capacity, then picking from the full catalog of eligible instance types rather than a pre-committed shortlist. That’s the architectural root of both its speed advantage and its bin-packing efficiency.
The project reached v1.0 general availability in late 2024, according to AWS’s official Karpenter 1.0 announcement, which locked the API surface and marked the end of its beta phase (documented earlier in AWS’s Karpenter graduates to beta post). As of July 2026, Karpenter’s core lives in the kubernetes-sigs/karpenter repository, reflecting its move toward a cloud-agnostic architecture, while the AWS-specific implementation sits in aws/karpenter-provider-aws, which carries 7,670 GitHub stars against the core repo’s 2,023. Both repos are tagged at the same current stable release, v1.14.0, published July 11, 2026. The project holds CNCF Sandbox status, a separate track from the v1.0 API-stability milestone.
Karpenter’s two central custom resources are the NodePool, which defines constraints like instance families, zones, and capacity type (spot vs on-demand), and the EC2NodeClass, which defines the AMI, subnets, and security groups a node should use. A minimal NodePool looks like this:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
expireAfter: 720hThat consolidationPolicy field is where a lot of Karpenter’s cost story comes from: it actively watches for underutilized nodes and repacks or terminates them, something Cluster Autoscaler’s node-group model isn’t built to do continuously.
What Is Cluster Autoscaler? The Kubernetes-Native Standard
Cluster Autoscaler predates Karpenter by five years and is maintained directly by Kubernetes SIG Autoscaling rather than a single vendor. Its releases track Kubernetes minor versions rather than following an independent version scheme of their own. As of July 8, 2026, the project’s most recent tags in the kubernetes/autoscaler repository include cluster-autoscaler-1.36.0, 1.35.1, 1.34.4, and 1.33.5, each aligned to its corresponding Kubernetes release. That release cadence is itself a signal of how the project is governed: rather than shipping features on its own schedule, Cluster Autoscaler moves in lockstep with core Kubernetes, which keeps compatibility risk low but also means new capabilities arrive slowly. The repository has accumulated 8,903 GitHub stars, reflecting its status as the long-standing default for most teams that haven’t specifically opted into Karpenter.
The tool’s core design hasn’t changed much since 2016: it monitors for unschedulable pods and nodes it considers underutilized, then adjusts the size of existing, pre-defined node groups. On AWS that means Auto Scaling Groups, on Azure it means Virtual Machine Scale Sets, and on GCP it means Managed Instance Groups. According to Kubernetes’ own cluster-autoscaling documentation, Cluster Autoscaler supports more than 30 infrastructure back ends in total, including on-premises options like vSphere and OpenStack, which makes it the most cloud-portable of the three tools by a wide margin.
The tradeoff for that portability is speed and granularity. Because Cluster Autoscaler works by resizing a group rather than requesting a specific instance type for a specific pending pod, it inherits whatever provisioning latency the underlying group mechanism has, and it can’t mix instance types within a single scaling decision as flexibly as Karpenter can. For teams running small, stable clusters where node churn is rare, that’s rarely a problem worth solving. For teams running spiky, heterogeneous workloads, it increasingly is.
What Is KEDA? Event-Driven Pod Autoscaling Explained
KEDA (Kubernetes Event-Driven Autoscaling) was created by Microsoft, with early contributions from Red Hat, and donated to the CNCF, where it now holds Graduated status, the foundation’s highest maturity tier and the same tier held by Kubernetes itself and Prometheus. That’s a meaningfully different governance track from Karpenter’s Sandbox status or Cluster Autoscaler’s position as a Kubernetes SIG subproject outside the CNCF process entirely.
Unlike Karpenter and Cluster Autoscaler, KEDA doesn’t touch node capacity at all. It extends the Horizontal Pod Autoscaler with a custom ScaledObject resource that lets a deployment scale based on external metrics rather than just CPU or memory. As of 2026, the project supports more than 35 built-in scalers, covering sources like Kafka, RabbitMQ, AWS SQS, Azure Service Bus, Prometheus, and PostgreSQL. The kedacore/keda repository has the highest star count of the three projects covered here, at 10,367, and its latest stable tag, v2.20.1, was published June 8, 2026.
A basic ScaledObject that scales a deployment based on Kafka consumer lag looks like this:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-processor
spec:
scaleTargetRef:
name: order-processor-deployment
minReplicaCount: 0
maxReplicaCount: 50
triggers:
- type: kafka
metadata:
bootstrapServers: kafka.default.svc:9092
consumerGroup: order-group
topic: orders
lagThreshold: "50"That minReplicaCount: 0 line is KEDA’s signature capability. When the orders topic is empty, the deployment scales to zero pods, and when messages arrive, KEDA wakes it back up. Neither Karpenter nor Cluster Autoscaler has an equivalent because neither operates below the level of “does at least one pod need to run somewhere.”
Karpenter vs Cluster Autoscaler vs KEDA: Specs Compared
Laid out side by side, the three projects look far less like direct competitors and more like three answers to three different questions. The table below pulls current version numbers, star counts, and release dates directly from each project’s GitHub repository as of mid-July 2026.
| Category | Karpenter | Cluster Autoscaler | KEDA |
|---|---|---|---|
| Creator / maintainer | AWS (donated to Kubernetes SIGs) | Kubernetes SIG Autoscaling | Microsoft, with Red Hat contributions |
| First released | 2021 | 2016 | 2019 |
| Autoscaling level | Node (cluster infrastructure) | Node (cluster infrastructure) | Pod (workload replicas) |
| CNCF maturity | Sandbox | Not a CNCF project (K8s SIG) | Graduated |
| Current stable version (Jul 2026) | v1.14.0 | Tracks K8s release (e.g. cluster-autoscaler-1.36.0) | v2.20.1 |
| Core GitHub repo | kubernetes-sigs/karpenter | kubernetes/autoscaler | kedacore/keda |
| GitHub stars | 2,023 (core) / 7,670 (AWS provider) | 8,903 | 10,367 |
| Language | Go | Go | Go |
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| AWS support | Native, GA | GA, via Auto Scaling Groups | GA |
| Azure support | GA (Q1 2026) via Node Auto Provisioning, Cilium overlay CNI + Linux only | GA, via Virtual Machine Scale Sets | GA |
| Google Cloud support | GA (Q1 2026), no GPU or Windows nodes yet | GA, via Managed Instance Groups | GA |
| Total supported back ends | 3 (AWS, Azure, GCP) | 30+, including on-prem vSphere/OpenStack | N/A (event scalers, not infra) |
| Event source scalers | N/A | N/A | 35+ |
| Scale-to-zero capability | No | No | Yes |
Two rows are worth dwelling on. The “total supported back ends” gap (3 vs 30+) is the single biggest reason Cluster Autoscaler still runs a large share of production clusters: any team with a multi-cloud footprint or an on-premises Kubernetes estate doesn’t currently have a Karpenter option everywhere it needs one. And the CNCF maturity row explains why some platform teams treat KEDA as a safer long-term bet than Karpenter for pod-level concerns, Graduated projects have cleared a specific bar for governance, security review, and adoption breadth that Sandbox projects haven’t yet.
Node Provisioning Speed: The Benchmark Data
Karpenter’s core marketing claim is speed, and it’s the part of the comparison with the most independent testing behind it. Because Karpenter calls the EC2 Fleet API directly instead of resizing an Auto Scaling Group, it skips a layer of indirection that adds real latency. Three separate engineering teams have published head-to-head timing numbers in 2026, and while their exact figures differ slightly, they land in the same range.
| Source | Karpenter provisioning time | Cluster Autoscaler provisioning time | What was tested |
|---|---|---|---|
| CHKK | ~45–60 seconds | 3–4 minutes | CPU-bound pod launch, cold-start node request |
| Tasrie IT (50+ cluster migration) | 30–60 seconds | 3–5 minutes | Cold-start provisioning and production pod scheduling |
| Spacelift | Under 1 minute (typical) | Several minutes (ASG-dependent) | General node scale-up comparison |
Taking the most conservative ends of these ranges, Karpenter still comes out roughly three to five times faster at getting a new node ready to accept pods. The mechanism behind the gap is straightforward: Cluster Autoscaler asks a node group to add capacity and then waits on that group’s own provisioning path, while Karpenter requests an EC2 instance directly and skips the intermediate step. For workloads where the difference between a 60-second and a 4-minute scale-up shows up as a customer-facing timeout, latency alone is often the deciding factor, independent of cost.
Speed isn’t the only axis these same sources measured. A LinkedIn benchmark from engineer Harish More, testing a 500-pod workload with traffic spikes and batch jobs, reported Karpenter holding roughly 85% node utilization versus 60–65% for Cluster Autoscaler in the same test, a gap that traces back to Karpenter’s continuous consolidation behavior rather than its provisioning speed.
Cost Efficiency and Bin-Packing: Which Tool Saves More
Provisioning speed gets the headlines, but the bigger line item for most platform teams is what happens after a node is running. Cluster Autoscaler will scale a node group down when it’s empty, but it doesn’t actively repack workloads onto fewer, better-utilized nodes while they’re running. Karpenter does, continuously, through its consolidation controller, which is what shows up as the more dramatic savings numbers in independent reporting.
CHKK’s published analysis put typical cluster-wide cost reduction after a Karpenter migration at around 20%, with CI-specific workloads (bursty, short-lived, and highly compressible) seeing reductions as steep as 90% in some cases. Tasrie IT’s review of a 50-plus cluster migration reported 20–40% compute cost reduction in the first quarter after switching, with further single-digit gains projected into the following year as teams tune their NodePool configurations. Both figures line up with the general mechanism at work: Karpenter’s ability to mix instance families and shift aggressively toward spot capacity when workloads tolerate interruption gives it more room to hunt for savings than a fixed node group does.
KEDA’s cost story is different in kind rather than degree. Because it can scale a deployment to zero replicas, it removes compute spend entirely for workloads that sit idle for meaningful stretches, nightly batch jobs, low-traffic internal tools, event consumers that only fire a few times an hour. That’s not a number that shows up cleanly against Karpenter’s or Cluster Autoscaler’s node-level savings, because it’s solving a different layer of the same waste problem: KEDA prevents pods from existing when nothing needs them, and Karpenter prevents nodes from existing when no pods need them.
Spot capacity is where the two node autoscalers diverge most in practice. Both can provision spot instances, but Karpenter’s per-request instance selection lets it diversify across many eligible spot pools simultaneously, which lowers the odds that a capacity shortage in any single pool interrupts a meaningful share of the cluster at once. Cluster Autoscaler can run spot node groups too, but each group is typically pinned to a narrower set of instance types, so a spot price spike or capacity crunch in that specific pool hits harder. For cost-sensitive workloads that can tolerate interruption, that diversification is often worth more than the sticker-price difference between spot and on-demand alone.
Multi-Cloud Support in 2026: AWS, Azure, and Google Cloud
Karpenter’s biggest structural change over the past year has been its move away from an AWS-only tool. Both the Azure and Google Cloud providers reached general availability in the first quarter of 2026, though “GA” comes with real asterisks on both.
Amazon EKS: Karpenter’s native home
This is where Karpenter is most mature by a wide margin, since it’s the platform it was built for. It’s available as a managed EKS add-on, meaning AWS handles the base installation, and it supports the full range of EC2 instance types, spot capacity, and GPU node provisioning that AI and ML teams increasingly need. AWS’s own architecture blog documents one of the largest public case studies of Karpenter adoption to date: Salesforce’s migration from Cluster Autoscaler to Karpenter across a fleet of 1,000 EKS clusters, a scale few case studies in this space can match.
Azure AKS: Node Auto Provisioning
Microsoft’s path to Karpenter on Azure runs through a managed feature called Node Auto Provisioning (NAP), which reached GA in the first quarter of 2026. It’s genuinely Karpenter under the hood rather than a from-scratch reimplementation, but production use is currently limited to clusters running the Cilium CNI in overlay mode, and only Linux nodes are supported. Windows node pools and non-Cilium networking setups aren’t covered yet.
Google Cloud GKE: newest and least mature
The GCP provider also reached GA in Q1 2026, but it’s the least battle-tested of the three. It doesn’t yet support GPU node provisioning or Windows nodes, which rules it out for a meaningful share of the AI and ML workloads that are otherwise Karpenter’s strongest use case. Teams evaluating it for production GKE clusters are generally advised to run a real pilot, on the order of several months, before committing, rather than assuming feature parity with the AWS provider.
Cluster Autoscaler, by contrast, has none of these caveats. It has supported AWS, Azure, and GCP for years, plus more than two dozen additional back ends, and its behavior doesn’t vary in maturity from one cloud to the next the way Karpenter’s currently does. KEDA’s event scalers are cloud-agnostic by design, since they connect to the event source itself (a Kafka cluster, an Azure Service Bus queue) rather than to a specific cloud’s compute layer, so multi-cloud isn’t really a variable for it at all.
Pricing: What These Autoscalers Actually Cost to Run
All three projects are fully open source under the Apache 2.0 license, so there’s no license fee to compare. The real cost differences show up in engineering time, managed-service overhead, and the compute spend each tool influences once it’s running.
| Cost factor | Karpenter | Cluster Autoscaler | KEDA |
|---|---|---|---|
| Software license | $0 (Apache 2.0) | $0 (Apache 2.0) | $0 (Apache 2.0) |
| AWS EKS integration | Free managed add-on | Free, self-managed | Free, self-managed via Helm |
| Azure AKS integration | Free via Node Auto Provisioning add-on | Free, self-managed | Free, self-managed via Helm |
| Google GKE integration | Free, GA provider (self-hosted) | Free, self-managed | Free, self-managed via Helm |
| Reported compute savings after adoption | ~20–40% (cluster-wide, multiple sources) | Baseline, no active consolidation | Up to 100% on idle workloads (scale-to-zero) |
| Initial setup effort | Higher (NodePool/EC2NodeClass tuning) | Lower (decade of documentation and examples) | Moderate (one ScaledObject per workload) |
| Ongoing maintenance | Moderate, active development pace | Low, stable and slow-moving API | Moderate, scaler-specific tuning |
| Support options | Community + AWS Support (for EKS add-on) | Community + cloud provider support plans | Community + commercial vendor support |
The practical read here is that Karpenter’s savings are real but not free: teams need to spend engineering time writing and tuning NodePool definitions, setting sensible consolidation policies, and testing spot-interruption handling before those savings materialize. Cluster Autoscaler’s lower setup cost is a genuine advantage for small platform teams without dedicated capacity to invest in autoscaler tuning, which is part of why it remains the default rather than a legacy choice.
Real-World Scenarios: Where Each Tool Fits Best
Beyond the Salesforce case study of migrating 1,000 EKS clusters to Karpenter, the pattern of which tool fits which workload shows up consistently across the engineering write-ups referenced above. Five scenarios come up repeatedly:
- Batch ML training with GPU spot instances. Training jobs that need a burst of GPU-backed nodes for a few hours benefit from Karpenter’s ability to select specific GPU instance types on demand and terminate them the moment the job finishes, rather than sitting inside a pre-sized node group.
- E-commerce flash-sale traffic spikes. Retail workloads that see 10x traffic for a two-hour sale window need node capacity fast. The 3-5x provisioning speed gap between Karpenter and Cluster Autoscaler is often the difference between absorbing the spike cleanly and dropping requests while new nodes are still coming online.
- Multi-tenant SaaS bin-packing. Platforms running many small, variably-sized tenant workloads on shared infrastructure are exactly the case Karpenter’s consolidation controller was designed for, since it continuously repacks pods onto fewer nodes as tenant load shifts through the day.
- Ephemeral CI/CD runners. Short-lived build and test jobs are highly compressible and tolerate interruption well, which is why CHKK’s analysis found CI workloads seeing cost reductions as high as 20% conservatively and up to 40% aggressively with full Spot usage and consolidation after a Karpenter migration; the 90% figure applies specifically to CI-specific workloads, not overall post-migration savings[2][3][8].
- Event-driven order and queue processing. A service that consumes from Kafka or SQS and sits idle most of the day is a textbook KEDA use case: scale to zero when the queue is empty, scale out fast when a backlog appears, independent of whatever node autoscaler is running underneath it.
Note that the last scenario isn’t a KEDA-instead-of-Karpenter choice. In practice, a queue-processing service scaling from zero to 50 replicas via KEDA still needs somewhere to run those pods, which means whatever node autoscaler sits underneath, Karpenter or Cluster Autoscaler, still matters for how fast that scale-out actually completes.
Which Autoscaler Should You Choose? Recommendations by Workload
Specs and benchmarks only matter in the context of what a given team is actually running. Here’s how the decision tends to shake out in practice:
- Startups and mid-size teams on EKS: Karpenter is the default recommendation. It’s the most mature provider, the setup cost is manageable at smaller scale, and the consolidation savings compound quickly on variable workloads.
- Enterprises with a genuine multi-cloud or on-prem footprint: Cluster Autoscaler remains the safer choice until Karpenter’s Azure and GCP providers mature further, simply because it behaves consistently everywhere it runs.
- AI/ML shops running GPU training pipelines: Karpenter on EKS specifically, since neither the Azure nor the GCP providers currently support GPU provisioning.
- Small, stable clusters with predictable load: Cluster Autoscaler is still the pragmatic pick. If node count barely changes week to week, Karpenter’s faster provisioning and consolidation savings have little to work with, and the simpler tool wins on maintenance cost.
- Teams running event-driven microservices (queues, streams, webhooks): KEDA, paired with whichever node autoscaler already fits the cloud footprint. This isn’t an either-or against Karpenter or Cluster Autoscaler, since KEDA operates one layer up from both.
Migration Guide: Cluster Autoscaler to Karpenter
Teams moving from Cluster Autoscaler to Karpenter on EKS generally follow the same rough sequence, based on the patterns documented in the Salesforce case study and the independent migration write-ups referenced above. This isn’t a flip-a-switch change, since both tools can run simultaneously during a transition, which is the safest way to do it.
- Audit current node groups. Document every Auto Scaling Group Cluster Autoscaler currently manages, including instance types, taints, and labels each group applies, since Karpenter’s NodePool will need to replicate any scheduling behavior your workloads depend on.
- Install Karpenter alongside Cluster Autoscaler. Deploy Karpenter via Helm or the EKS managed add-on without removing Cluster Autoscaler yet. Both can coexist as long as they aren’t managing the same node groups.
- Create an EC2NodeClass. Define the AMI family, subnets, and security groups Karpenter-provisioned nodes should use, mirroring what your existing ASG launch templates already specify.
- Create a starter NodePool. Scope it narrowly at first, for example to a single non-critical workload or namespace, with conservative instance-type requirements before opening it up broadly.
- Cordon and drain one Cluster Autoscaler-managed node group. Let Karpenter pick up the resulting unschedulable pods and provision replacement capacity, then watch scheduling behavior closely for that first group.
- Validate spot-interruption handling. If the NodePool allows spot capacity, confirm workloads tolerate interruption gracefully. Add pod disruption budgets for anything that doesn’t, since a spot reclamation mid-request is a very different failure mode than a graceful scale-down.
- Expand NodePool scope incrementally. Move additional workloads over namespace by namespace or team by team rather than all at once, checking cost and latency metrics at each step.
- Set consolidation policy deliberately. Start with
WhenEmptyfor safety, then move toWhenEmptyOrUnderutilizedonce the team has confidence in workload behavior under active repacking. - Scale down and retire Cluster Autoscaler. Once all node groups have been migrated and validated, remove Cluster Autoscaler’s remaining ASGs and uninstall it.
- Tune based on real cost data. Compare Cost Explorer or equivalent billing data from before and after the migration. Both CHKK and Tasrie IT’s write-ups note that most of the reported 20-40% savings materialize gradually over the first full billing cycle, not immediately, as consolidation settles into a steady rhythm and NodePool constraints get tuned against real traffic patterns.
The single most common mistake in these migrations, according to multiple independent write-ups, is skipping the incremental rollout and pointing Karpenter at every workload on day one. Pod disruption budgets, taints, and topology spread constraints that Cluster Autoscaler respected implicitly through node-group configuration don’t automatically carry over, and they need to be explicitly re-declared in Karpenter’s NodePool and workload specs.
Pros and Cons of Karpenter, Cluster Autoscaler, and KEDA
Karpenter
- Pros: Fast provisioning (3-5x quicker in independent tests), continuous bin-packing and consolidation, flexible instance-type and spot selection, native AWS integration as a managed EKS add-on.
- Cons: Only three cloud back ends, Azure and GCP providers less mature than AWS, higher initial configuration effort, still CNCF Sandbox rather than Graduated.
Cluster Autoscaler
- Pros: Broadest cloud and on-prem support (30+ back ends), mature and stable API, lowest setup and maintenance overhead, well understood by nearly every Kubernetes engineer.
- Cons: Slower provisioning (3-5 minutes typical), no active consolidation of underutilized nodes, less flexible instance-type mixing within a single scale-up event.
KEDA
- Pros: CNCF Graduated (highest maturity tier), scale-to-zero support, 35+ event source scalers, cloud-agnostic by design, complements rather than replaces node autoscalers.
- Cons: Solves a different problem than Karpenter and Cluster Autoscaler, so it’s not a substitute for either. Requires per-workload ScaledObject tuning, and it doesn’t help at all if node capacity itself is the bottleneck rather than pod count.
The Verdict: Our Kubernetes Autoscaling Recommendation for 2026
There isn’t a single winner here, because these three tools only overlap at the edges. For node-level autoscaling on AWS, the data points clearly toward Karpenter: three independent sources converge on roughly 45-60 second provisioning versus 3-5 minutes for Cluster Autoscaler, and reported cost savings in the 20-40% range are corroborated across CHKK, Tasrie IT, and the real-world Salesforce migration across 1,000 EKS clusters that AWS itself documented. If your workloads are spiky, GPU-dependent, or cost-sensitive at scale, and you’re running on EKS, that speed and consolidation advantage is hard to leave on the table.
Cluster Autoscaler still earns its keep in two specific situations: genuine multi-cloud or on-premises environments where Karpenter simply doesn’t reach yet, and small, low-churn clusters where the operational simplicity outweighs any consolidation upside. Given that Azure and GCP support only reached general availability in the first quarter of 2026, and both carry real gaps (no GPU or Windows support on GCP, Cilium-only networking on Azure), teams outside AWS should treat Karpenter as a pilot project this year rather than a default migration target.
KEDA sits outside this comparison in the sense that it isn’t competing for the same job. Any team running event-driven or queue-based workloads should be running KEDA regardless of which node autoscaler sits underneath it, since scale-to-zero pod behavior and node-level provisioning solve two different halves of the same cost problem. The practical 2026 stack for most AWS-based teams increasingly looks like Karpenter plus KEDA together, with Cluster Autoscaler remaining the right call specifically where Karpenter’s multi-cloud coverage hasn’t caught up yet.
The direction of travel is fairly clear even where the tools aren’t fully mature yet. Karpenter’s Azure and GCP providers only reached GA a couple of quarters ago, and CNCF Sandbox projects don’t always make it to Graduated status, but the pace of investment from AWS, the size of the Salesforce-scale migrations already documented, and the consistency of the independent benchmark data all point toward Karpenter closing its remaining gaps rather than stalling. Teams building a new platform from scratch on EKS in 2026 have little reason to start with Cluster Autoscaler by default anymore. Teams already running it, especially outside AWS, have little reason to rip it out today either.
Frequently Asked Questions
Is Karpenter better than Cluster Autoscaler?
For AWS-based clusters, independent benchmarks from CHKK, Tasrie IT, and Spacelift consistently show Karpenter provisioning nodes several times faster and delivering meaningfully lower compute costs through active consolidation. Cluster Autoscaler remains the better fit for multi-cloud or on-premises environments and for small, low-churn clusters where simplicity matters more than optimization.
Can I use Karpenter and KEDA together?
Yes, and it’s an increasingly common pairing. KEDA scales pod replicas based on event sources like queue depth, and Karpenter provisions the node capacity those pods need to run. They operate at different layers and don’t conflict.
Does Karpenter work on Azure or Google Cloud in 2026?
Yes, both providers reached general availability in the first quarter of 2026. Azure support comes through a managed feature called Node Auto Provisioning and is currently limited to Cilium overlay networking with Linux nodes only. The GCP provider doesn’t yet support GPU or Windows nodes, and a multi-month pilot is generally recommended before full production use on either.
Is Karpenter free?
Yes. Karpenter, Cluster Autoscaler, and KEDA are all open source under the Apache 2.0 license with no licensing fees. The costs that do apply are indirect: engineering time to configure and tune each tool, and the underlying compute the nodes themselves consume.
What’s the difference between node-level and pod-level autoscaling?
Node-level autoscaling, handled by Karpenter or Cluster Autoscaler, adds or removes entire virtual machines from a cluster. Pod-level autoscaling, handled by KEDA or Kubernetes’ built-in Horizontal Pod Autoscaler, adds or removes replicas of a workload within the node capacity that already exists. A cluster typically needs both working together.
Does Karpenter support Windows nodes or GPU nodes?
On AWS, yes to both, Karpenter supports the full range of EC2 instance types including GPU instances and Windows-based AMIs. On Google Cloud, neither is currently supported by the GA provider. Azure’s Node Auto Provisioning currently supports Linux nodes only.
How long does a Cluster Autoscaler to Karpenter migration take?
It varies by cluster count and workload complexity, but the documented approach runs both tools side by side and migrates node groups incrementally rather than all at once. Teams referenced in this comparison report meaningful cost savings materializing over the first full billing cycle after migration, generally around 30 days, though full migrations spanning many clusters, as in Salesforce’s 1,000-cluster case, unfolded over a longer, phased timeline.
Which tool is best for a small startup running one EKS cluster?
Karpenter is generally worth adopting even at small scale on EKS, since the managed add-on installation is straightforward and the consolidation savings compound as the cluster grows. Teams running fewer than a handful of nodes with very stable load may not see enough benefit to justify the initial NodePool configuration work, in which case Cluster Autoscaler remains a reasonable starting point.
Does KEDA replace the Horizontal Pod Autoscaler?
No, it extends it. KEDA installs its own metrics adapter and creates an HPA object behind the scenes for each ScaledObject, so teams already familiar with HPA don’t need to learn a separate scaling mechanism, only the additional trigger types KEDA adds on top.
What happens to running pods when Cluster Autoscaler or Karpenter removes a node?
Both tools respect pod disruption budgets and drain a node gracefully before terminating it, rescheduling evicted pods onto other available capacity. Karpenter’s consolidation feature does this more frequently than Cluster Autoscaler’s scale-down behavior, which is why setting accurate disruption budgets matters more once a team adopts it.
Related Coverage
- Kubernetes Tutorial: Build a Cluster in 13 Steps [2026]
- ECS vs EKS vs Fargate: $0 vs $73/mo Control Plane [2026]
- Docker vs Kubernetes 2026: The Definitive Container Comparison
- OpenShift vs Kubernetes 2026: $1K Per-Core Gap [Tested]
- ArgoCD vs Flux 2026: 23K vs 8K Stars, UI Gap [Tested]
- FinOps in 2026: How CFOs Are Finally Taming Runaway Cloud Costs
- Cloud Cost Optimization: 7 Strategies That Actually Work
