Karpenter vs Cluster Autoscaler

Cluster Autoscaler (CA) was the de-facto Kubernetes node autoscaler for years: it watches for unschedulable pods and scales the appropriate node group up. Karpenter takes a fundamentally different approach — instead of scaling predefined node groups, it provisions nodes directly from cloud APIs in response to pending pods, selecting the optimal instance type in real time. On EKS, Karpenter is now the recommended default. The question of which to use is largely settled: Karpenter on EKS, CA everywhere else.

Karpenter wins on every performance dimension: it provisions nodes in 30–60 seconds (vs 2–5 minutes for CA + ASG), it bin-packs across hundreds of instance types simultaneously, and it actively consolidates underutilized nodes by replacing them with smaller ones (CA can only delete nodes, not replace them). Karpenter's spot instance handling — with configurable disruption budgets, rebalancing awareness, and automatic fallback to on-demand — is the most sophisticated available on any cloud. For EKS users, there's no longer a compelling reason to run CA.

CA wins on cloud breadth. Karpenter is mature only on AWS; its Azure provider is in preview and its GCP provider is community-maintained. CA runs on EKS, GKE, AKS, Alibaba, Hetzner, and more — all with years of production validation. CA is also simpler to get started: install via Helm, annotate your node groups, done. If you're on GKE or AKS and not running EKS, CA (or your cloud's native autoscaler like GKE NAP) is the right choice today.

Migrating from CA to Karpenter on EKS requires creating NodePool and EC2NodeClass CRDs to replace your ASG node groups, then deleting the CA deployment. The conceptual model is different — instead of thinking in node groups, you think in NodePool constraints (instance families, architectures, capacity types). Expect 1–2 days for a straightforward migration. Run both in parallel initially: Karpenter handles new pods, CA handles existing node groups until they drain.