A platform team migrating from Cluster Autoscaler noticed their EKS node count staying roughly the same after switching to Karpenter, and assumed the migration hadn't delivered much. Then they checked p95 CPU utilization: it had jumped from 8% to over 30%, because Karpenter was packing pods onto fewer, better-fitted nodes instead of leaving each pending pod stranded in a fixed-size node group with capacity to spare. The node count didn't need to change - the waste inside each node did.
That's the real story behind Cluster Autoscaler vs Karpenter in 2026: it's less "which one adds nodes faster" and more "which one wastes less capacity while doing it," and the two solve that problem with fundamentally different architectures.
Both autoscalers answer the same question - do we have enough node capacity for pending pods - but they answer it by querying completely different sources of truth.
Cluster Autoscaler: Scales pre-defined node groups (Auto
Scaling Groups on AWS). You define
instance types ahead of time; CA adds
or removes instances within those
fixed groups. 3-4 minutes to scale up.
Karpenter: Provisions nodes directly against the
cloud API - no pre-defined groups. Picks
from any instance type that fits pending
pods. 45-60 seconds to scale up, with
active bin-packing and consolidation.
Cluster Autoscaler's model is fundamentally a capacity-planning exercise done ahead of time: you decide which instance types exist in your node groups, and CA's job is purely to add or remove instances within that predefined menu. Karpenter's model removes the pre-planning step entirely - it reads pending pod resource requests directly and calls the cloud API to provision whatever instance actually fits, which is both faster and structurally less wasteful, since there's no fixed-size node group forcing a 2.5 vCPU pod onto a 4 vCPU instance because that's the only node group configured.
Karpenter brings new nodes online in 45 to 60 seconds by calling cloud APIs directly. Cluster Autoscaler relies on Auto Scaling Groups and typically takes 3 to 4 minutes to scale up, since it has to go through the ASG's own scaling lifecycle rather than provisioning an instance directly.
The bin-packing gap is arguably the bigger cost driver of the two. Cluster Autoscaler scales within fixed-size node groups, so if pending pods need 2.5 vCPU and the only available node group runs 4 vCPU instances, the pod gets a whole 4 vCPU node - wasted capacity baked directly into how the node group was defined. Karpenter picks from any instance type that fits, and its v1.5 release added "emptiness-first" consolidation, which actively recycles idle nodes rather than passively waiting for new pending pods to trigger a scaling decision the way Cluster Autoscaler's expander does.
AWS now ships Karpenter as the managed default inside EKS Auto Mode, which removes most of the operational overhead that historically made Cluster Autoscaler the safer, lower-maintenance choice - you don't install, scale, or upgrade the Karpenter controller yourself under Auto Mode.
That convenience comes with real constraints worth checking before defaulting to it: EKS Auto Mode runs Bottlerocket OS only, offers no SSH access to nodes, charges extra per-instance pricing on top of standard EC2 rates, and rotates nodes automatically roughly every 21 days. Teams that need SSH access for debugging, a different AMI, or tighter control over per-instance cost should run Karpenter themselves rather than adopting Auto Mode by default.
Karpenter was originally AWS-specific, but its core has since moved to the vendor-neutral kubernetes-sigs/karpenter project, enabling cloud-specific providers to implement the same provisioning model elsewhere. As of 2026, Azure has a production-ready Karpenter provider. GCP support remains early-stage community work with no production-ready provider as of mid-2026, which means Cluster Autoscaler is still the only real option for GKE clusters, and Cluster Autoscaler's mature, consistent support across AWS, GCP, and Azure makes it the more defensible single choice for genuinely multi-cloud Kubernetes environments.
Karpenter has not yet reached formal CNCF graduated status as of early 2026, though it sits within the Kubernetes SIG Autoscaling umbrella and continues shipping frequent releases.
Neither autoscaler fixes bad pod resource requests on its own. At roughly 8% average CPU utilization across many production clusters, most of the waste isn't in node inventory decisions at all - it's in resource requests set 10-12x higher than actual consumption, which no node autoscaler can see past, since both Karpenter and Cluster Autoscaler size nodes based on what pods request, not what they use.
Benchmark data makes the split concrete: Karpenter's bin-packing and consolidation alone save roughly 9% over a Cluster Autoscaler baseline. Adding pod-level rightsizing on top of Karpenter reaches closer to 43% savings. The node autoscaler choice is the smaller lever - continuous rightsizing of pod requests is the bigger one, and it matters regardless of which autoscaler sits underneath it.
Architecture and Speed:
| Factor |
Cluster Autoscaler |
Karpenter |
| Provisioning model |
Pre-defined node groups (ASGs) |
Direct cloud API, any instance type |
| Scale-up time |
3-4 minutes |
45-60 seconds |
| Bin-packing |
Passive, group-constrained |
Active, with emptiness-first consolidation |
Cloud Support and Fit:
| Factor |
Cloud coverage |
Best fit |
| Cluster Autoscaler |
AWS, GCP, Azure - mature everywhere |
Multi-cloud, stable GPU/ML node pools |
| Karpenter |
AWS mature, Azure production-ready, GCP early |
AWS-native, variable workloads, cost-sensitive |
For new EKS clusters in 2026, Karpenter (or EKS Auto Mode if the Bottlerocket/no-SSH constraints are acceptable) is the default recommendation - faster provisioning, better bin-packing, and native Spot/On-Demand mixing without maintaining pre-defined node groups. Budget 2-4 weeks for migration planning and testing if moving an existing cluster off Cluster Autoscaler; running both in parallel for a couple of weeks before fully cutting over is the safer path.
Stay on Cluster Autoscaler if your clusters span multiple clouds, run stable GPU/ML workloads that benefit from persistent, pre-sized node pools, or already have a well-tuned setup with no specific pain point driving a migration - there's no urgency to switch a cluster that isn't showing symptoms.
Before attributing cost savings to either autoscaler, audit actual p95 pod resource usage against requested resources per namespace first. For Indian engineering teams under cost pressure to justify a Karpenter migration to finance, that audit is the number that actually predicts the savings - the autoscaler choice alone rarely explains the full gap.
INFORMATIONReferences and Further Reading
Discussion0