Karpenter or Cluster Autoscaler: which to use on your EKS cluster

Both do the same visible job: when pods do not fit on any node, new capacity appears, and when nodes are left over, they go away. The difference is how each one decides, and that changes the bill at the end of the month.

How each one decides

Cluster Autoscaler works with node groups. On AWS, each group is an Auto Scaling Group with an instance type (or a short list) defined in advance. When there are pending pods, it picks a group whose node template would fit the pod and grows that group. You decide the shape of the nodes when you create the groups.

Karpenter does not use groups. It reads the requirements of pending pods (CPU, memory, architecture, zone, tolerations) and creates EC2 instances directly, choosing among many types that meet them. You describe limits and preferences in a NodePool and an EC2NodeClass, and it picks the node shape each time.

Where the difference shows

Karpenter's cost gain comes from two things: it does not make you guess the right instance type for each group, and consolidation repacks pods to free whole nodes, not just empty ones.

When to keep Cluster Autoscaler

• The platform is multi-cloud and you want one autoscaling behavior across every cluster.
• Nodes are controlled through groups for governance, compliance or very specific images, and instance variety brings no gain.
• The load is steady and already well sized. Without variation, consolidation has little to recover.
• The team does not yet have reliable CPU and memory requests. Neither autoscaler makes up for inflated requests.

When Karpenter is worth the migration

• EKS cluster with variable demand (API peaks, jobs, queues, CI).
• Spot in use or planned, with several instance families available.
• Many node groups that exist only to cover combinations of size, architecture and zone.
• Interest in running Graviton next to x86 in the same cluster.

A safe migration path

1. Fix requests first. Compare them with real usage, for example with rightsizing-check. No autoscaler fixes pods that ask for three times what they use.
2. Install Karpenter next to Cluster Autoscaler, with its controller running on a small managed group, outside the nodes it provisions.
3. Create a `NodePool` limited to a test workload, using the NodePool generator to start from valid v1 YAML.
4. Enable consolidation with disruption budgets and PodDisruptionBudgets on critical workloads before widening the scope.
5. Move workloads in stages, drain the old groups and only then scale Cluster Autoscaler to zero.

To see the financial effect before touching production, use the savings calculator. The article Karpenter: how to cut Kubernetes cost covers NodePool, EC2NodeClass and troubleshooting.

In short

For an EKS cluster with variable load, Karpenter is usually the cheaper choice, as long as requests are right and disruption is controlled. Cluster Autoscaler remains a good fit for multi-cloud, steady or tightly controlled environments. If you want an opinion on your case, the efficiency assessment is the place to start.