Karpenter Kubernetes Autoscaler

Cluster Autoscaler scales node groups. Karpenter provisions individual nodes based on pod requirements. The difference sounds subtle but changes how fast your cluster responds to demand.

Why Karpenter Exists

Cluster Autoscaler works with pre-defined node groups. You create a node group with t3.large instances, min 2, max 20. When pods cannot schedule, the autoscaler adds nodes from that group.

The problems:

• Slow: Node groups scale in 3-5 minutes
• Wasteful: If a pod needs 4 CPU cores, you might scale a group of 2-core nodes and get two nodes instead of one right-sized one
• Rigid: You must pre-define every instance type and size combination

Karpenter takes a different approach: look at what the pending pods actually need, then provision the cheapest node that fits.

How Karpenter Works

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"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "100"
    memory: 400Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

You define constraints (architecture, capacity type, instance families) and limits (max CPU/memory). Karpenter selects the optimal instance type for each scheduling decision.

Speed Difference

For bursty workloads, the difference between 4 minutes and 60 seconds to scale is the difference between degraded service and seamless handling.

Consolidation

Karpenter actively consolidates workloads. If three nodes are each 30% utilized, Karpenter will:

1. Find a single node type that fits all pods
2. Provision the new node
3. Drain and terminate the underutilized nodes

This happens continuously, not just at scale-down events. The result is consistently higher utilization and lower cost.

Spot Instance Handling

Karpenter natively handles spot interruptions:

spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]

When a spot instance gets a 2-minute interruption notice, Karpenter automatically provisions a replacement (on-demand if spot is unavailable) and drains the interrupted node. No manual interruption handler needed.

Migration from Cluster Autoscaler

# Install Karpenter
helm install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --namespace kube-system \
  --set settings.clusterName=my-cluster \
  --set settings.interruptionQueue=my-cluster

# Create NodePool and EC2NodeClass
kubectl apply -f nodepool.yaml

# Gradually move workloads off managed node groups
# Karpenter provisions replacement nodes automatically

# Once all workloads run on Karpenter nodes, remove managed node groups

Run both systems in parallel during migration. Karpenter handles new pods while existing node groups continue serving current workloads.

When to Use Karpenter

Good fit: - Variable workloads with unpredictable scaling needs - Cost-sensitive environments (Karpenter's bin-packing saves 20-40%) - Teams that want spot instances without complexity - Clusters with diverse pod sizes (GPU, high-memory, CPU-intensive)

Stick with Cluster Autoscaler if: - You need multi-cloud support (Karpenter is strongest on AWS) - Your workloads are predictable and steady-state - Node group management is working well for your team

---

Ready to go deeper? Master Kubernetes autoscaling with hands-on courses at CopyPasteLearn.