EKS node autoscaling with Karpenter: just-in-time capacity, no node groups
Karpenter provisions EC2 capacity for EKS based on actual pending pods instead of static node groups. A look at NodePool, EC2NodeClass, consolidation and Spot use.
Karpenter takes a different approach to EKS node autoscaling by operating at the level of individual unschedulable pods rather than node groups, as Cluster Autoscaler does. This means capacity decisions follow real-time demand instead of pre-written templates. The NodePool resource defines scheduling and disruption policy, while EC2NodeClass handles AWS-specific plumbing like subnets, security groups, AMIs, and IAM roles — a separation that keeps capacity intent distinct from cloud infrastructure details.
The real payoff shows up in day-to-day operation: consolidation removes empty or underutilized nodes and swaps them for cheaper shapes, while drift detection replaces nodes that no longer match current NodePool or EC2NodeClass specs, such as outdated AMIs. However, consolidation's effectiveness depends entirely on the disruption rules in place — pod anti-affinity, topology spread constraints, and PodDisruptionBudgets can all quietly block consolidation. So when cost savings don't materialize, the workload policies around the nodes are usually the first place to look, not the controller itself.
Spot instance usage is another strength of Karpenter, since its ability to choose from a much wider range of instance types makes Spot genuinely practical. But this only pays off when a real on-demand fallback exists for interruption scenarios. Ultimately, Karpenter reduces the manual provisioning work but doesn't eliminate the need to explicitly define constraints like instance family, architecture, capacity type, and disruption tolerance.