How to Reduce Kubernetes Costs with Karpenter: A 2026 Field Guide
By Nishaant Dixit
I've been running Kubernetes in production since 2019. Watched the hype cycle peak, saw the backlash, and lived through the exodus. In 2025, we saw a real reckoning — Why Companies Are Leaving Kubernetes? wasn't just a hot take, it was a signal. By 2026, one engineering org publicly stated they deleted Kubernetes from 70% of their services, saving $416K. Brutal.
But here's the thing they don't tell you in those postmortems: they didn't leave Kubernetes because Kubernetes was broken. They left because they were over-provisioning like crazy. Their cluster was 40-60% idle. Their auto-scaler was the default Cluster Autoscaler — slow, dumb, and expensive.
Karpenter changes that.
If you're asking "how to reduce kubernetes costs with karpenter" — you're asking the right question in 2026. I've seen teams cut their compute spend by 30-50% just by switching from Cluster Autoscaler to Karpenter. Not by reducing workloads. By matching infrastructure to actual demand.
This guide assumes you know basic Kubernetes. It assumes you're tired of paying AWS for idle nodes. And it assumes you want the real trade-offs — not the marketing.
Let's get into it.
What Karpenter Actually Does (And Why Cluster Autoscaler Fails)
Cluster Autoscaler looks at pending pods and says "I need more nodes." Then it talks to the cloud provider API, requests a specific instance type, and waits. Minutes, sometimes tens of minutes. By the time that node is ready, your burst has already passed — or your costs have already spiked.
Karpenter is different. It's a Kubernetes-native node autoscaler that directly provisions instances via the EC2 API. No node groups. No instance families locked in amber. It looks at pod resource requests, picks the cheapest instance type that fits, and launches it in under 60 seconds.
The cost difference happens in two places:
- Bin-packing efficiency — Karpenter can pack pods tighter because it's not constrained to predefined node groups
- Spot instance utilization — Karpenter handles spot interruptions natively, so you can run spot safely without losing workloads
I've seen a team at a mid-size fintech reduce their cluster from 47 nodes to 23 just by switching. Same workload. Half the hardware. Why? Because Cluster Autoscaler was over-provisioning by 2x to handle spikes, and the node groups were poorly sized.
Setting Up Karpenter for Cost Efficiency
Let's start with the basics. You need:
- An EKS cluster (v1.24+)
- An EC2 instance profile with the right IAM permissions
- The Karpenter Helm chart (or raw YAML, if you're a masochist)
Here's a minimal karpenter.yaml provisioner that prioritizes spot instances:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "c5.large"
- "c5.xlarge"
- "c5.2xlarge"
- "c6a.large"
- "c6a.xlarge"
- "c6a.2xlarge"
- "m5.large"
- "m5.xlarge"
- "m6a.large"
- "m6a.xlarge"
nodeClassRef:
name: default
limits:
cpu: "1000"
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
The key here: consolidationPolicy: WhenUnderutilized. This is your primary lever for karpenter consolidation strategy to reduce compute costs. When Karpenter detects that pods on a node could fit onto fewer or cheaper nodes, it evicts and reschedules them. We'll talk more about consolidation later.
NodeClass — Your Cost Control Panel
The NodeClass defines your actual infrastructure:
yaml
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: Bottlerocket
role: "karpenter-node-role"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
subnetSelectorTerms:
- tags:
Name: "*private*"
tags:
Name: "karpenter-node"
Don't skip the amiFamily: Bottlerocket. It's AWS's minimal OS — smaller footprint, fewer vulnerabilities, faster boot times. We tested it against Amazon Linux 2 and got 15-20% faster node readiness. And since you pay for the instance, not the OS, there's zero cost difference.
Spot Instances: The 60-70% Discount
This is where the real karpenter spot instance cost savings kubernetes live. Spot instances are 60-70% cheaper than on-demand. But they can be terminated with 2-minute notice.
Most teams avoid spot because they're afraid of disruption. Cluster Autoscaler handles spot poorly — it doesn't rebalance well, and you end up with half your pods stuck when a spot pool gets reclaimed.
Karpenter's approach is different:
- It diversifies across instance types and availability zones
- When a spot interruption notice comes, Karpenter drains the node and provisions replacement capacity before the 2-minute window expires
- It tracks spot prices per region and instance type, preferring cheaper pools
Here's our spot-optimized NodePool:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: spot-optimized
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
nodeClassRef:
name: spot-class
limits:
cpu: "500"
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 168h
We've run 80% spot for our stateless workloads for 18 months. Total spot interruptions: 12. Average downtime: zero (because we had 3x redundancy per microservice).
The trick: never run a single replica on spot. Always run at least 2. Use pod disruption budgets. And for stateful workloads? Keep those on on-demand or use EBS-backed spot instances with proper backup.
Consolidation: The Silent Cost Killer
Most people focus on spot pricing for cost savings. That's table stakes. The real move is karpenter consolidation strategy to reduce compute costs.
Consolidation works by constantly evaluating whether your existing nodes are optimally packed. When a node drops below a utilization threshold, Karpenter calculates: "If I drain this node and redistribute its pods, can I terminate one or more nodes?"
The answer is often yes.
We ran an experiment: same workload, same pods, same scheduling constraints. With consolidation off, we had 31 nodes. With consolidation on? 19 nodes. That's a 38% reduction in node count. At $0.096/hr for a c5.xlarge, that's roughly $800/month saved. For a single cluster.
You configure consolidation in the disruption section:
yaml
disruption:
consolidationPolicy: WhenUnderutilized
consolidateAfter: 60s
The consolidateAfter: 60s means Karpenter will wait 60 seconds after a pod is scheduled before attempting to consolidate. You don't want it too aggressive — pods need time to start. But 60 seconds is usually enough.
One warning: consolidation can mess with your monitoring. When nodes get terminated and recreated, your dashboards look spiky. That's fine. It's working. But tell your team before you enable it.
Multi-Instance-Type Strategy
Here's a mistake I see constantly: teams restrict Karpenter to a single instance family. They pick m5 and say "that's good enough."
Karpenter's power comes from flexibility. Give it 15-20 instance types across 4-5 families. Let it choose the cheapest that fits your pod's CPU/memory profile.
yaml
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "c5.large"
- "c5.xlarge"
- "c5.2xlarge"
- "c6a.large"
- "c6a.xlarge"
- "c6a.2xlarge"
- "m5.large"
- "m5.xlarge"
- "m6a.large"
- "m6a.xlarge"
- "r5.large"
- "r5.xlarge"
- "r6a.large"
- "r6a.xlarge"
Why this matters: spot pricing varies wildly across instance types. On Tuesday, c5.xlarge spot might be $0.042/hr. On Wednesday, it jumps to $0.081/hr because some AI company spun up 2000 of them. Karpenter notices and shifts to c6a.xlarge at $0.038/hr.
You don't have to watch spot pricing. Karpenter does it for you.
Real Numbers: What We Saved
I'm going to share actual numbers from a client engagement in Q1 2026. E-commerce company, 15 microservices, production and staging clusters, US East region.
Before Karpenter (Cluster Autoscaler, on-demand only):
- 47 nodes (mix of m5 and c5)
- $14,200/month
- 42% average CPU utilization
After Karpenter (80% spot, consolidation enabled):
- 23 nodes (mix of 10 instance types)
- $5,860/month
- 68% average CPU utilization
Savings: $8,340/month (58%).
Did it require work? Yes. We had to adjust pod resource requests. Some pods were requesting 4x what they needed, which prevented consolidation. We used Vertical Pod Autoscaler (VPA) to right-size them over a month. That was the hardest part — not Karpenter itself.
The Gotchas Nobody Talks About
Let me be honest about the downsides. Karpenter isn't magic.
Pod Disruption Budgets matter more than you think. If your PDBs are too restrictive, Karpenter can't consolidate. We had a team set minAvailable: 2 on a deployment with 2 replicas. Karpenter couldn't terminate any node running that pod. We had to scale to 3 replicas to give it room.
StatefulSets with local storage are problematic. If your StatefulSet uses hostPath or emptyDir for important data, moving pods means data loss. Karpenter doesn't know about your application state. Use persistent volumes or accept that some nodes can't be consolidated.
Cluster add-ons can block consolidation. If you run DaemonSets that request significant resources, Karpenter might not be able to pack pods onto fewer nodes. We had a monitoring DaemonSet requesting 0.5 CPU per node. On a 50-node cluster, that's 25 CPUs of overhead. We optimized the DaemonSet down to 0.1 CPU per node.
Network costs don't change. People think "fewer nodes = lower total cost." That's true for compute. But data transfer costs, NAT gateway charges, and load balancer costs stay the same. Karpenter only reduces compute.
The Future: Where Karpenter is Going
As of July 2026, Karpenter v1.0 is stable and battle-tested. But the roadmap has some interesting things:
- Multi-cloud support — Currently AWS-only, but there's community work on Azure and GCP providers
- GPU-aware scheduling — Right now, Karpenter can provision GPU instances, but it doesn't optimize GPU utilization as aggressively as CPU/memory
- Carbon-aware provisioning — An experimental feature that prioritizes regions with cleaner energy during off-peak hours
I've been running the dev builds. The GPU scheduling improvement alone will be huge for teams running inference workloads.
When Karpenter Isn't the Answer
Kubernetes isn't dead, you just misused it — you've probably heard that take. It's partially true. But sometimes leaving Kubernetes is the right call.
If you have 3 microservices and a team of 5 engineers, Karpenter won't save you meaningful money. The operational overhead of managing a Kubernetes cluster — even with Karpenter — might exceed the compute savings. We're leaving Kubernetes stories usually come from teams who over-engineered their infrastructure.
Karpenter makes sense when:
- You have 10+ microservices or variable workloads
- Your utilization is under 40%
- You're paying more than $3K/month in compute
- You have at least one person who understands Kubernetes
If those don't apply? Use Lambda. Or Fargate. Or just run a single EC2 instance. Save yourself the complexity.
FAQ
Q: How long does it take to migrate from Cluster Autoscaler to Karpenter?
A: For a standard EKS cluster, 1-2 hours. Install Karpenter, create a NodePool, gradually cordon nodes from your old auto-scaling group, and let them drain. No downtime if you do it right.
Q: Can I run Karpenter alongside Cluster Autoscaler?
A: Technically yes. Practically no. They'll fight over node provisioning. Choose one.
Q: Does Karpenter work with EKS managed node groups?
A: Yes, but why would you? The whole point is escaping node groups. Use Karpenter's own NodeClass instead.
Q: What happens when a spot instance is reclaimed?
A: Karpenter gets the termination notice ~2 minutes before EC2 kills the instance. It marks the node as unschedulable, evicts pods (respecting PDBs), and launches replacement instances. If you have 2+ replicas, users see zero impact.
Q: How do I know if consolidation is working?
A: Run kubectl get events -n karpenter and look for consolidation-related events. Also check node count over time — you should see fewer nodes after enabling consolidation.
Q: Does Karpenter work outside AWS?
A: Not natively. There are community providers for Azure and GCP, but they're not production-ready as of mid-2026.
Q: My pods don't specify resource requests. Will Karpenter help?
A: No. Karpenter can't optimize blindly. You need to set CPU/memory requests for every workload. Use VPA to analyze actual usage and generate recommendations.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.