Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.
GitHub RepoImpressions287
View on GitHub
@githubprojectsPost Author

Karpenter: The Kubernetes Node Autoscaler That Actually Makes Sense

If you've ever wrestled with the Kubernetes Cluster Autoscaler, you know it can be a pain. It's slow to react, requires separate node groups per instance type, and often fails to match the right node to your workload. That's where Karpenter comes in.

Built by the good folks at AWS and now a CNCF Sandbox project under Kubernetes SIGs, Karpenter is a drop-in replacement for the old Cluster Autoscaler that thinks differently about how nodes should be provisioned. No more predefining node groups. No more waiting minutes for a new instance to spin up. Just fast, flexible, and simple node autoscaling.

What It Does

Karpenter watches for unschedulable Pods in your cluster. When it finds one, it instantly provisions the right node to run it. It decides which instance type, size, and zone to use based on the Pod's resource requests, tolerations, node selectors, and affinity rules. On the flip side, when nodes are underutilized, it consolidates them to reduce cost.

The key difference? Karpenter works directly with the cloud provider's API to launch instances, without needing pre-created node groups. It's a single controller that handles everything.

Why It’s Cool

Three things make Karpenter stand out:

1. Speed. Karpenter provisions nodes in seconds instead of minutes. It bypasses the node group dance and talks straight to the EC2 API (or your cloud provider's equivalent). For batch jobs, spot instances, or bursty workloads, this is a game changer.

2. Flexibility. You don't need to define separate node groups for every instance size. Karpenter dynamically picks the best instance type from a list of allowed families. So if your Pod needs 4 vCPUs and 16 GB RAM, Karpenter might launch a c5.xlarge or m5.xlarge depending on what's available. It even handles spot interruptions gracefully by re-provisioning pods on new nodes.

3. Simplicity. Configuration is a single custom resource called Provisioner. You tell it things like "use c5 and m5 families, prefer us-east-1a, with a max of 1,000 nodes." That's it. No scaling groups, no launch templates, no node group management. The operator model is clean and versioned, so you can git-ops your infrastructure.

How to Try It

Getting started is straightforward. You'll need a Kubernetes cluster on AWS (EKS, kops, or self-managed) with IAM credentials that can launch EC2 instances.

The quickest path:

# Install using Helm
helm repo add karpenter https://charts.karpenter.sh/
helm install karpenter karpenter/karpenter --namespace karpenter \
  --version 0.37.0 \
  --set settings.aws.defaultInstanceProfile=KarpenterNodeInstanceProfile \
  --set settings.aws.interruptionQueueName=karpenter

Then create a basic Provisioner:

apiVersion: karpenter.sh/v1beta1
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: ["spot", "on-demand"]
      nodeClassRef:
        name: default

For a full walkthrough including the EC2NodeClass setup, check the official docs.

Final Thoughts

Karpenter is the kind of tool that makes you wonder why we ever did it the old way. It's fast, it's clever, and it's simple enough that you can explain it to a teammate over lunch. If you're managing clusters at scale or just want your batch jobs to start faster, give it a shot.

I've been running it on a small EKS cluster for a few months now, and the biggest surprise is how little I think about node management. It just works. And that's the highest compliment I can give an infrastructure tool.


Follow us on X: @githubprojects

Back to Projects
Last updated: May 21, 2026 at 06:06 PM