Is Karpenter better than Cluster Autoscaler?

Karpenter provisions nodes in under a minute vs 3-5 minutes for Cluster Autoscaler, and its per-pod bin-packing typically saves 30-50% on compute costs. But CA is multi-cloud and more mature. Karpenter is best for AWS EKS with variable workloads.

Does Karpenter work with GKE or AKS?

Karpenter is primarily an AWS tool. It has experimental provider implementations for Azure and GCP, but the project is heavily AWS-focused. Cluster Autoscaler works natively with all three major clouds.

What's the cost difference between Karpenter and Cluster Autoscaler?

Karpenter's per-pod provisioning eliminates over-provisioning — it picks the smallest instance that fits your pods. Vorwerk reported 60% reduction in compute usage after migrating. Salesforce saved significantly across 1,000 EKS clusters.

Should I migrate from Cluster Autoscaler to Karpenter?

Yes, if you're on EKS with variable workloads and want faster scaling and lower costs. The migration is straightforward: deploy Karpenter via Helm, create a default NodePool, scale CA to zero, then monitor. Keep CA as a fallback during the transition.

KARPENTER VS CLUSTER AUTOSCALER: WHICH KUBERNETES NODE AUTOSCALER WINS IN 2026?

19/6/2026
5-minute read
966 words

Your cluster is scaling, but it’s scaling wrong.

The Cluster Autoscaler adds nodes in chunks — entire Auto Scaling Group instances — whether your pods need that much capacity or not. Three pending pods? Here’s an entire m5.large. One pod that needs a GPU? Here’s a full p3.2xlarge with 7 unused vCPUs.

This isn’t a minor inefficiency. It’s how most Kubernetes bills grow 30-50% higher than they should be.

Karpenter fixes this by doing what the Cluster Autoscaler never could: provisioning exactly the node your pods need, in under a minute.

Who Is This Guide For?

Platform engineers and SREs managing EKS clusters at scale. If you’re evaluating Karpenter, wondering whether to migrate from Cluster Autoscaler, or trying to understand why your node autoscaling costs more than it should.

By the End of This, You’ll Know

The architectural difference between Karpenter and Cluster Autoscaler — and why it matters for cost
How Karpenter provisions nodes in seconds vs minutes
Real cost savings from production migrations at Salesforce and Vorwerk
A step-by-step migration plan from CA to Karpenter

The Architectural Difference

Cluster Autoscaler works at the node-group level. It scans for pending pods, selects a pre-defined Auto Scaling Group, and asks the cloud provider to increase its size. The instance type is whatever you configured in that ASG — fixed, rigid, and almost certainly oversized for the pods that triggered the scale-up.

Karpenter watches the Kubernetes API for unschedulable pods and provisions a node that matches their exact resource requirements. It calls the EC2 CreateFleet API directly, bypassing Auto Scaling Groups entirely. The instance type, size, and capacity type (Spot vs On-Demand) are chosen dynamically based on the pod batch.

This is not a minor implementation detail. It’s a fundamentally different approach to infrastructure scaling.

Cluster Autoscaler scales node groups. Karpenter provisions nodes. The difference is the difference between buying in bulk and buying exactly what you need.

Provisioning Speed: Seconds vs Minutes

When a pod becomes pending, Karpenter launches a node in 45-60 seconds on AWS by invoking EC2 Fleet directly. Cluster Autoscaler takes 3-5 minutes because it must reconcile through the ASG lifecycle — health checks, instance warming, and Kubernetes node registration.

During traffic spikes, that 3-5 minute gap means pods remain pending, requests queue up, and user experience degrades. With Karpenter, the node is ready before most users notice the spike.

Cost Impact: Where the Savings Come From

Karpenter’s right-sized, per-pod provisioning enables aggressive bin-packing. It evaluates the exact CPU, memory, and hardware requirements of pending pods and selects the smallest instance that satisfies the combined demand. This eliminates the over-provisioning that Cluster Autoscaler’s node-group approach inherently creates.

Vorwerk — the German appliance manufacturer — adopted Karpenter across all environments and achieved a 60% reduction in compute usage and 30-50% EC2 cost savings by consolidating workloads onto right-sized Spot and On-Demand instances.

Salesforce migrated 1,000 EKS clusters from Cluster Autoscaler to Karpenter using a phased, zero-downtime approach. The migration enabled heterogeneous instance families, GPU nodes, and IP efficiency across regions — things that were impractical with CA’s rigid node groups.

The Datadog 2026 container report confirms the trend: a 22% increase in Karpenter-provisioned nodes over the past two years, driven by migrations from CA.

Karpenter v1.x: What You Get

Version 1.12.1 (May 2026) introduces two key CRDs that replace the complexity of node groups.

NodePool defines the shape of nodes — allowed instance families, CPU/memory limits, and disruption policies. Spending caps like limits.cpu: 1000 prevent runaway costs.

EC2NodeClass stores provider-specific configuration — AMI selection, subnet and tag discovery, security groups, and IMDSv2 enforcement. This decouples infrastructure details from the abstract pool.

The project lives under the CNCF kubernetes-sigs organization with approximately 4,900 GitHub stars and 200+ contributors.

Cluster Autoscaler: When to Keep It

Cluster Autoscaler remains the right choice for:

Multi-cloud deployments where you need consistent behavior across AWS, Azure, and GCP
Static, predictable workloads where node group boundaries match actual capacity needs
Teams that can’t absorb migration risk and prefer the maturity of a battle-tested tool

CA v1.35.0 (April 2026) continues to receive updates and is integrated into every major managed Kubernetes service. It’s not going anywhere. But for cost-sensitive, variable workloads on EKS, the gap in efficiency is hard to ignore.

Migration Guide: CA to Karpenter

The migration is simpler than most teams expect.

Prepare the cluster. Ensure Kubernetes 1.28+, install Helm, and create the required IAM roles (KarpenterNodeRole and KarpenterControllerRole).
Deploy Karpenter. Use the official Helm chart with serviceAccount.annotations.eks.amazonaws.com/role-arn pointing to the controller role. Set settings.clusterName and settings.interruptionQueue.
Create a default NodePool. Define allowed instance families, capacity types (Spot + On-Demand), and resource limits. The price-capacity-optimized allocation strategy balances cost with availability.
Scale CA to zero. Leave it installed but with zero replicas. This gives you a clean rollback path.
Validate. Monitor Karpenter’s Prometheus metrics — karpenter_provisioning_duration_seconds and karpenter_nodes_created_total. Adjust batch windows and consolidation policies based on workload patterns.

What You Can Actually Use Today

Start with a non-production cluster. Deploy Karpenter alongside CA, scale CA to zero, and run your workload for a week. Compare node count and compute cost against your CA baseline. Most teams see a 10-20% reduction immediately from bin-packing alone.

Set spending caps. Karpenter’s NodePool limits.cpu and limits.memory fields are your safety net. Start conservative and expand as you gain confidence.

Monitor spot interruption. Karpenter handles Spot interruptions automatically through its disruption budgets, but you should watch interruption rates in the first month. Set up alerts via the interruption queue SQS.

Keep CA in your back pocket. The migration is reversible. If Karpenter doesn’t fit your workload patterns, scaling CA back up takes minutes.

Optimizing your Kubernetes infrastructure?

I help engineering teams design cost-efficient Kubernetes platforms. If you’re evaluating Karpenter, planning a migration, or want to benchmark your current autoscaling costs, let’s talk.

Talk to me

kubernetes cloud cost-optimization comparison