If your Kubernetes cluster runs on the Cluster Autoscaler, you already know the drill: a new pod is pending, a node gets added 10 minutes later, and it stays up long after the work is done. Meanwhile, your EC2 bill keeps climbing and your kubectl get nodes output looks like a fleet of half-empty trucks.
Karpenter — the open-source node autoscaling project that AWS donated to the CNCF — has been the most discussed answer to this problem on r/kubernetes and Hacker News for months. A recent HN thread on “Karpenter’s consolidation behaviour is counter-intuitive” (August 2026) shows exactly where teams get burned: they install it, watch it terminate nodes, and panic. This guide explains how Karpenter actually works in 2026, how to configure it for an SMB budget, and where its behavior will surprise you.
Why Karpenter Is Different From the Cluster Autoscaler
The Cluster Autoscaler (CA) is reactive and node-pool-bound: it adds nodes to a pool when pods can’t fit, and removes them when utilization drops below a threshold. It cannot change instance type, it cannot consolidate multiple underutilized nodes into one larger instance, and it treats every node in a pool as interchangeable.
Karpenter takes the opposite approach. It watches pending pods, computes the cheapest mix of instances that satisfies their combined requests, and provisions exactly those instances — from any family, size, zone, or capacity type (on-demand, spot, or savings plans). Every second, it re-evaluates whether existing nodes are still optimal. If two nodes at 30% utilization could be replaced by one node at 60%, it does it. If a node is running an outdated AMI or a deprecated Kubernetes version, it replaces it. This is called consolidation and drift detection, and it’s the reason Karpenter routinely cuts EC2 spend by 30–50% compared to static node groups.
Installing Karpenter on EKS in Under 15 Minutes
Karpenter v1.x runs in your cluster as a deployment and provisions nodes through the cloud provider API. On EKS, the installation is a Helm chart plus two custom resources. First, install the controller:
# Add the Karpenter Helm repo (official public ECR chart)
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
--version v1.5.0 --namespace karpenter --create-namespace \
--set settings.clusterName=production \
--set settings.interruptionQueue=production-karpenter \
--set controller.resources.requests.cpu=1 \
--set controller.resources.requests.memory=1Gi \
--waitThen define what a node looks like with an EC2NodeClass, and when nodes should exist with a NodePool. This is the entire config most SMBs need:
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
role: "arn:aws:iam::123456789012:role/KarpenterNodeRole"
amiFamily: AL2
subnetSelectorTerms:
- tags: { karpenter.sh/discovery: production }
securityGroupSelectorTerms:
- tags: { karpenter.sh/discovery: production }
---
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", "spot"]
- key: kubernetes.io/arch
operator: In
values: ["amd64", "arm64"]
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
expireAfter: 720h
limits:
cpu: "200"
memory: 400GiThat’s it. Karpenter now provisions whatever instance type fits the pending pods — including m7g Graviton instances that are ~20% cheaper than their x86 equivalents — and stops provisioning when the limits block is reached. The limits field is your safety net and your budget control in one.
The “Counter-Intuitive” Consolidation Behavior, Explained
The HN thread that made Karpenter trend again this month centers on one question: why is my node being terminated when it still has running pods? Here’s what’s happening — and why it’s usually correct behavior:
- Consolidation is request-based, not usage-based. Karpenter looks at pod requests, not actual CPU usage. A node running pods that request 4 vCPU but use 0.5 vCPU is a consolidation candidate. If your workloads have inflated requests, expect more churn than you’d predict.
- It can replace, not just delete. WhenUnderutilized mode may terminate two nodes and launch a single bigger one in their place. Pods get rescheduled during the swap, so it looks like an outage if you don’t have PodDisruptionBudgets (PDBs) in place.
- It respects PDBs and budgets. Set a
disruptionBudgeton the NodePool (e.g.,maxUnavailable: 10%) to cap how many nodes can be disrupted at once. Without it, Karpenter consolidates aggressively and your API pods restart in waves. - Stateful workloads block consolidation. Pods with local PVs or
emptyDirwithsizeLimitcan prevent node termination. Karpenter will simply skip those nodes — which is why a cluster with legacy stateful sets shows less savings.
You can watch every decision in the controller logs:
kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter -f | grep -i consolidat
# 2026-08-05T10:02:11Z INFO Consolidating node(s): i-0f3a... in 9.37m
# 2026-08-05T10:02:11Z INFO Launching node: 3 m7g.medium instances, spotCutting Costs Further: Spot, Limits, and Right-Sizing
Consolidation is only half the story. For SMBs, the biggest wins come from combining Karpenter with deliberate cost controls:
- Enable spot for stateless workloads. Add
"spot"to the capacity-type requirement (as above) and mark non-critical deployments withkarpenter.sh/do-not-disrupt: "true"only where truly needed. Spot with Karpenter typically runs 60–90% cheaper than on-demand. - Use
nodePoolRefscheduling for cost tiers. Create aspotNodePool for batch jobs and acriticalNodePool withon-demandonly, then pin workloads withnodeSelectorTermsin their pod specs. - Set
consolidationPolicy: WhenEmptyOrUnderutilized(the default) — it reclaims idle capacity within minutes instead of hours, unlike the CA’s 10-minute downscale delays. - Watch the built-in metrics.
karpenter_nodes_created,karpenter_nodes_terminated, andkarpenter_nodepool_usagefeed straight into Grafana; a single dashboard panel showing nodes vs. requested capacity tells you if your requests are realistic.
If you’re already fighting a runaway Kubernetes bill, Karpenter is the mechanism that makes the cost-cutting playbook from our Kubernetes cost guide actually stick — the other half is knowing what to measure, which we covered in our SMB FinOps guide.
When NOT to Adopt Karpenter
Karpenter isn’t universal. Skip it (for now) if: your cluster is under ~10 nodes and rarely scales (the savings won’t cover the operational overhead); you run mostly stateful workloads with local storage; or your team is mid-way through a cluster upgrade and can’t afford another moving part. Start on a non-production cluster, run it alongside the Cluster Autoscaler for two weeks (Karpenter and CA can coexist if you keep their node groups separate), and compare the before/after node counts. In our experience with SMB clients, the consolidation behavior stops feeling counter-intuitive the moment you add PDBs and a disruption budget — and the monthly EC2 invoice starts looking a lot smaller.
Autoscaling is one piece of a healthy platform. If you’d like a second pair of eyes on your cluster architecture, node configuration, or cloud costs, book a free 30-minute consultation — we’ll tell you honestly whether Karpenter is worth it for your setup.
Español 
English