What Is Karpenter? How Just-in-Time Node Provisioning Cuts Kubernetes Cost

Key takeaways

• Karpenter watches unschedulable pods and provisions right-sized nodes directly from cloud APIs, without pre-defined node groups.
• Two core CRDs define behavior: NodePool (scheduling constraints and disruption policy) and NodeClass (cloud infrastructure configuration).
• Consolidation removes empty or underutilized nodes by repacking workloads onto fewer machines, reducing idle compute cost.
• Karpenter is GA on AWS via EKS Auto Mode (December 2024) and on AKS via Node Auto Provisioning (late 2024). GKE has no official provider as of mid-2026.
• The Cast AI 2026 State of Kubernetes Optimization Report shows 69% average CPU over-provisioning. Karpenter addresses the node-level portion of that waste. Pod-level rightsizing requires additional tooling.

What Karpenter is

AWS created Karpenter in 2021 as an alternative to rigid, node-group-based autoscaling. AWS contributed the project to the CNCF in 2023, where it entered the CNCF Sandbox, and v1.0 reached general availability in November 2024. The project currently sits at v1.14.

The core idea is direct cloud API provisioning. Instead of pre-sizing node groups and hoping the right instance type is available, Karpenter watches for pending pods and picks the best-fit, lowest-cost node for each scheduling event. On AWS, it calls the EC2 API directly. No node group templates. No manual scaling policies.

Karpenter sits within the broader ecosystem of Kubernetes autoscaling alongside the Horizontal Pod Autoscaler and Vertical Pod Autoscaler. Its focus is the node layer: how many machines run, what size they are, and how quickly they shut down when demand drops.

How Karpenter provisions nodes

Watching pending pods

Karpenter runs a controller that watches the Kubernetes API for pods in an Unschedulable state. When no existing node can fit a pod, the scheduler marks it pending. At that point, Karpenter evaluates the pod’s resource requests, node selectors, tolerations, and affinity rules. It then finds the smallest, cheapest instance type that satisfies every constraint and provisions it.

Instance selection across families and sizes

This is where Karpenter diverges sharply from traditional autoscalers. It evaluates hundreds of instance types simultaneously, across families and sizes. For example, if your pods need 4 vCPUs and 8 GiB of memory, Karpenter scans all instance types meeting that threshold, ranks them by current cost, and provisions the best match. It factors in Spot availability, regional pricing, and any capacity-type preferences from your NodePool.

The result is smarter bin-packing from the start. Karpenter sizes nodes to fit the workload, not the other way around.

Just-in-time vs node groups

Traditional node group autoscaling requires you to define instance types and group sizes upfront. The autoscaler scales those groups. As a result, you frequently end up with nodes too large for what is actually running on them.

Karpenter has no node groups. It provisions nodes just in time, selecting the right instance for each scheduling event. It also deprovisions nodes when workloads no longer need them. The lifecycle is tighter, and idle compute costs less.

Consolidation and bin-packing

How it removes and repacks nodes for cost

Consolidation is how Karpenter reclaims idle compute. It runs continuously, checking whether nodes are underutilized or empty. When it identifies a candidate node, it evicts the pods and terminates the node, rescheduling workloads onto remaining nodes.

Three policies control this behavior. WhenEmpty targets nodes with no running pods. WhenEmptyOrUnderutilized goes further: it cordons a node, evicts its pods, and reschedules them elsewhere if doing so reduces total node count. Over time, this is where a significant share of cost savings accumulates. A third option, Balanced, avoids consolidating nodes where cost savings are small relative to disruption cost. It is useful for clusters where workload churn makes aggressive consolidation counterproductive.

According to the Cast AI 2026 State of Kubernetes Optimization Report, average CPU utilization across Kubernetes clusters is just 8%, with 69% CPU over-provisioning cluster-wide. Karpenter’s just-in-time provisioning and consolidation directly address the node-level portion of that waste. The low utilization figure also reflects over-requested pods, which Karpenter cannot address on its own.

Disruption controls

Consolidation is powerful, but aggressive eviction can disrupt production workloads. Karpenter provides a disruption budget that limits how many nodes it replaces at once. The consolidateAfter parameter defines a stabilization delay before a node becomes eligible for consolidation. It applies to all consolidation policies, but is most commonly paired with WhenEmpty to prevent premature removal of nodes that briefly appear empty during deployment churn.

The budgets array gives you fine-grained control over the pace of disruption:

disruption:
  budgets:
    - nodes: "10%"
    - nodes: "5"
      schedule: "@daily"
      duration: 1h

The first entry caps concurrent node replacements to 10% of fleet nodes at a time. The second entry adds a maintenance window via a cron schedule, restricting replacements to at most 5 nodes during that window.

During eviction, Karpenter respects PodDisruptionBudgets (PDBs). If a PDB blocks eviction, Karpenter pauses the disruption of that node until the budget allows it.

For in-depth guidance on safe consolidation configuration, see our Karpenter consolidation guide. For a detailed look at disruption and drift interactions, see Karpenter disruption and drift.

Core concepts

NodePools and NodeClasses

Karpenter uses two core CRDs. A NodePool sets scheduling constraints (architecture, capacity type, instance family), resource limits, and disruption policy. A NodeClass sets cloud-provider infrastructure configuration. On AWS, this is an EC2NodeClass, specifying AMI selection, subnets, security groups, and IAM role.

The separation is intentional. Platform teams own the NodeClass for cloud configuration. Individual teams can define their own NodePool constraints for their workloads. This design keeps infrastructure policy centralized and workload scheduling policy flexible.

A minimal NodePool YAML example

The following NodePool allows both on-demand and Spot capacity on amd64 instances, sets a 1,000-CPU cluster limit, and enables WhenEmptyOrUnderutilized consolidation with a 10% node disruption budget.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "1000"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"

The paired EC2NodeClass specifies the AMI alias, IAM role, and subnet and security group selectors.

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  role: "KarpenterNodeRole-my-cluster"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"

For a full breakdown of every NodePool and NodeClass field, see the Karpenter NodePools guide.

Disruption and drift

Drift occurs when a node’s running configuration diverges from its NodePool spec. For example, when a new AMI version becomes available or requirements change, Karpenter marks affected nodes as drifted and replaces them automatically. This keeps your fleet in sync with your declared configuration, without manual rollouts or blue-green node group management. For full details on drift behavior and how to tune it, see the Karpenter NodePools reference.

Karpenter vs Cluster Autoscaler

The core difference is scope. Cluster Autoscaler scales pre-defined node groups with fixed instance types. In contrast, Karpenter provisions individual nodes directly from cloud APIs, selecting from all available instance types in near-real time.

In practice, Cluster Autoscaler polls the Kubernetes API every 10 or more seconds and operates only within pre-configured group boundaries. Karpenter reacts to scheduling events and selects the optimal instance type immediately. It also handles deprovisioning natively through its consolidation logic, while Cluster Autoscaler relies on group scale-down heuristics.

Cluster Autoscaler is more mature on non-AWS clouds and has broader community support in some environments. The right choice depends on your cloud provider and how much you want to maintain node group templates manually. For a full feature comparison, see Karpenter vs Cluster Autoscaler.

Karpenter on EKS and beyond

Karpenter has the deepest support on AWS. EKS Auto Mode was announced at AWS re:Invent 2024 and reached GA in December 2024, meaning new EKS clusters can enable Karpenter without a manual Helm install or separate controller deployment. For more on what EKS Auto Mode changes operationally, see our EKS Auto Mode guide.

Azure AKS reached general availability for Karpenter-based node provisioning via Node Auto Provisioning in late 2024. The Azure provider covers most common workload patterns and uses the same NodePool CRD structure as the AWS provider.

GCP and GKE tell a different story. As of mid-2026, no official Karpenter provider exists for GKE. Community-maintained options are available, but they lack production support and full feature parity with the AWS and Azure providers. Teams on GCP should evaluate alternative node autoscaling approaches before committing to Karpenter.

Where Karpenter stops and automation helps

Karpenter is effective at node provisioning and consolidation. Nevertheless, three gaps limit what it can achieve on its own.

The most common gap is over-requested pods. If a container requests 4 CPUs but uses 0.3, Karpenter still provisions a node sized to accommodate the full request. That gap — between what pods claim and what they actually consume — is a pod-request problem, not a node-provisioning problem.

Stateful workloads face a different constraint. When Karpenter consolidates, it evicts pods. For stateless workloads that tolerate disruption, this works well. For stateful workloads with persistent connections or local storage, eviction can mean downtime.

Spot instance risk is the third boundary. Karpenter handles interruption signals reactively but has no ML-based prediction of which Spot instances the cloud provider will reclaim.

Cast AI for Karpenter addresses all three gaps. The Karpenter Enterprise Suite, generally available as of May 2026, adds continuous workload rightsizing (adjusting pod resource requests based on actual usage), container live migration for stateful workloads without restarts, ML-based Spot interruption prediction, and workload-aware consolidation that factors in pod-level cost signals, not just node count. Real-time cost attribution, down to the namespace and workload level, closes the charge-back gap that Karpenter alone cannot address.

In combination, Karpenter handles the node layer and Cast AI handles the workload layer above it. Together, they close the gap between the 8% CPU utilization most clusters report and the 40-60% utilization range that well-optimized clusters achieve in production.

Frequently Asked Questions