Karpenter

Karpenter is an open-source node lifecycle management project for Kubernetes, originally built at AWS and maintained under kubernetes-sigs. On AWS it manages EC2 capacity for EKS clusters.

How it works

Karpenter watches for pods that the Kubernetes scheduler has marked unschedulable. It evaluates their constraints, such as resource requests, node selectors, affinities, tolerations and topology spread constraints, then provisions nodes that satisfy them. It does not rely on pre-defined node groups. Instead, a NodePool describes the allowed requirements and limits, and an EC2NodeClass holds AWS-specific settings.

Karpenter also removes capacity. Its disruption methods include consolidation (removing or replacing empty or underutilised nodes), drift (replacing nodes that no longer match their NodePool or EC2NodeClass) and expiry via expireAfter. Disruption budgets limit how many nodes are disrupted at once.

For Spot capacity, Karpenter can watch an interruption queue fed by EC2 events. On a Spot warning, which gives two minutes’ notice, it starts a replacement node while draining the old one.

A practical example

A minimal NodePool in the shape shown in the official documentation:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements: [{key: karpenter.sh/capacity-type, operator: In, values: ["on-demand"]}]
  limits:
    cpu: "1000"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

Common mistakes

• Setting no limits, so a runaway deployment can provision a large amount of capacity.
• Omitting pod resource requests. Karpenter sizes nodes from requests, so missing ones lead to poor choices (see resource requests and limits).
• Running workloads without a PodDisruptionBudget, so consolidation can disrupt them abruptly.
• Allowing Spot for workloads that cannot tolerate interruption.
• Forgetting that Karpenter needs somewhere to run itself, typically a small managed node group or Fargate.

When to use it and when not to

Karpenter suits clusters with varied or bursty workloads where flexible instance selection and active consolidation reduce waste. A fixed, predictable fleet gains less. It also pairs with Horizontal Pod Autoscaler, which scales pods while Karpenter scales nodes. See the Karpenter and Cluster Autoscaler guidance for EKS for a comparison.

See also

• EKS
• Fargate
• Horizontal Pod Autoscaler
• Taints and Tolerations
• Karpenter technology overview