Karpenter — Node Autoscaling

Just-in-time node provisioning for Kubernetes — Karpenter watches unschedulable pods and provisions the optimal EC2 instance type directly, replacing Cluster Autoscaler.

Overview

Nodes for the pods that are waiting

Karpenter is an open-source node autoscaler for Kubernetes that provisions new nodes in response to unschedulable pods. Unlike Cluster Autoscaler, which manages predefined node groups, Karpenter calls the cloud provider API directly to launch the best instance type for the pending workload.

How it works

1 — A pod cannot be scheduled: no node has enough CPU, memory or GPU, or none matches the required node affinity
2 — Karpenter watches for pods the Kubernetes scheduler marks unschedulable
3 — It evaluates the pod's resource requests and scheduling constraints and computes the cheapest or fastest instance type that satisfies all of them
4 — It calls the EC2 RunInstances API directly, with no Auto Scaling Group; the node registers and the pod is scheduled

Configuration objects

NodePool — Constraints on the nodes Karpenter can provision: allowed instance families, capacity types (On-Demand or Spot), zones and resource limits (max total CPU and memory across all Karpenter nodes)
EC2NodeClass — AMI family, subnet selector, security group selector and instance store configuration; decouples cloud-specific settings from the generic NodePool

Consolidation and drift

Consolidation — Continuously checks node efficiency; if a node is underutilized and its workloads fit elsewhere, drains and terminates it without waiting for scale-down delay timers
Drift detection — When a NodePool or EC2NodeClass changes (new AMI, changed instance requirements), detects nodes that no longer match and replaces them through a rolling process

Karpenter vs Cluster Autoscaler

Node groups — Requires predefined node groups (ASGs) — None: calls the cloud API directly
Instance choice — Only within the group's boundaries — Best instance type chosen dynamically
Capacity mix — Per group — On-Demand and Spot in a single NodePool
Scale-down — Waits for delay timers — Consolidates proactively

> [!TIP] Karpenter is the recommended approach for new EKS clusters.

Key concepts

NodePool: Karpenter CRD that defines what kinds of nodes Karpenter can provision: allowed instance families, capacity types (On-Demand/Spot), availability zones, and resource limits (max total CPU/memory for all Karpenter nodes).
EC2NodeClass: AWS-specific Karpenter CRD that defines the AMI family, subnet selector (by tag), security group selector, and block device configuration for nodes Karpenter launches.
Consolidation: Karpenter feature that continuously evaluates whether underutilized nodes can be emptied and terminated. Workloads are rescheduled onto remaining nodes. Reduces cluster costs proactively without waiting for CPU or memory thresholds.
Disruption Budget: Constraint on how many nodes Karpenter can disrupt simultaneously during consolidation or drift replacement. Set via NodePool disruption settings to prevent consolidation from causing service outages.
Drift Detection: Karpenter detects when existing nodes no longer match their NodePool or EC2NodeClass spec (e.g., AMI changed) and proactively replaces them via rolling node replacements.
Topology Spread Constraints: Kubernetes scheduling constraint that distributes pods across zones or nodes. Karpenter respects these constraints when selecting which AZ to launch new nodes in.

When to use it

Replacing Cluster Autoscaler in EKS clusters for better cost efficiency and speed
Interview questions about Kubernetes node autoscaling strategies
Mixing Spot and On-Demand instances dynamically based on workload requirements
Reducing cluster costs by automatically consolidating underutilized nodes
Designing EKS clusters that scale from zero for batch or ML workloads