Kubernetes Costs Are Eating Your Budget — Here's How Karpenter Fixes It
I'm going to tell you something that cost me $40,000 to learn: most Kubernetes cost optimization advice is garbage.
Cluster autoscaler is slow. Node groups are wasteful. And reserving EC2 instances for workloads that change every week? That's not engineering — that's gambling.
By mid-2025, I'd watched three startups burn through their seed rounds just keeping Kubernetes running. One company — let's call them FinStack — was spending $23,000/month on EC2 alone. Their actual compute utilization? 34%.
They weren't alone. In 2024, Why Companies Are Leaving Kubernetes? started documenting the exodus. By 2025, the trend accelerated. At SIVARO, we saw clients literally deleting clusters and moving to Lambda or Fargate just to escape the complexity.
But here's the contrarian take: Kubernetes isn't the problem. Your node provisioning strategy is.
Karpenter fixes that. This guide is how to actually use it to reduce Kubernetes costs — with real configurations, real numbers, and hard-won lessons from production.
What Is Karpenter (And Why Cluster Autoscaler Is Obsolete)
Karpenter is an open-source node autoscaler for Kubernetes. Built by AWS, donated to the CNCF. It replaces the Cluster Autoscaler with something fundamentally different.
Cluster Autoscaler works like a committee. It sees pending pods, checks node groups, negotiates with AWS APIs, and eventually — minutes later — spins up a node. The average latency from pod creation to node ready? Around 3-7 minutes. I've seen 12.
Karpenter works like a vending machine. Pod needs resources? Karpenter calculates the optimal instance type, provisions it directly via the EC2 API, and the node is ready in 60-90 seconds.
That's not a small difference. That's the difference between paying for idle nodes "just in case" and paying only for what you need right now.
By early 2026, I'd migrated 14 clusters to Karpenter. Cost reduction across the board: 35-55%. Worst case was 22% — still worth the migration.
How to Reduce Kubernetes Costs with Karpenter — The Core Strategies
Strategy 1: Stop Over-Provisioning Node Groups
Here's the dirty secret most cluster operators won't admit: their node groups are sized wrong.
Standard practice is to have a few instance types per node group. Spot, on-demand, maybe a GPU pool. The problem is fragmentation. You've got t3.mediums in one group, t3.larges in another. When a pod requests 4 vCPU and 8GB, it falls into a gap. The cluster autoscaler has to spin up an entire new node — which you'll pay for even if only 30% is used.
Karpenter doesn't care about node groups. It thinks in terms of requirements.
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:
- "t3.medium"
- "t3.large"
- "m5.large"
- "c5.large"
- "r5.large"
nodeClassRef:
name: default
limits:
cpu: "1000"
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
That's it. One NodePool covers 5 instance types, both spot and on-demand. If a pod needs 4 vCPU and 16GB, Karpenter selects the cheapest option that fits — likely a c5.large or r5.large — and provisions it on the spot market if available.
Strategy 2: How to Configure Karpenter for Spot Instances (Without Getting Interrupted)
This is where most people screw up.
They configure Karpenter for spot instances with one broad NodePool, then wonder why their batch jobs get interrupted at 3 AM.
The fix is diversity.
AWS' spot market is volatile. As of July 2026, certain instance families (looking at you, m6i) have a 20-30% interruption rate in us-east-1 during peak hours. But t3, c5, and r5 families? Under 5%.
Karpenter handles this gracefully if you let it.
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: "node.kubernetes.io/instance-type"
operator: In
values:
- "t3.medium"
- "t3.large"
- "t3.xlarge"
- "c5.large"
- "c5.xlarge"
- "c5.2xlarge"
- "r5.large"
- "r5.xlarge"
- "m5.large"
- "m5.xlarge"
nodeClassRef:
name: spot
limits:
cpu: "500"
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 168h
Key points:
- Don't limit to 2-3 instance types. Give Karpenter 10+. It picks the cheapest available.
- Set
expireAfterto 168h (7 days). Forces node rotation. Old Spot instances are more likely to be reclaimed. - Use
consolidationPolicy: WhenUnderutilized. If a node drops below 50% utilization, Karpenter drains it and reschedules pods to cheaper instances.
At SIVARO, we saw spot market savings of 65-75% compared to on-demand. But only when configured with instance diversity. One client stuck to 3 instance types and saw 12% interruption rate. We expanded to 12 types — dropped to 2%.
Strategy 3: Consolidation Is Free Money (If You Let It Work)
Most Kubernetes clusters have "node drift" — over time, workloads shift, and you end up with nodes that are 20-30% utilized. Cluster Autoscaler won't touch them because it only removes empty nodes.
Karpenter's consolidation feature is where the magic happens.
When enabled, Karpenter constantly evaluates every node: "Can I move these pods to cheaper or fewer instances?" If yes, it drains the node, terminates it, and reschedules the pods.
I've seen consolidation reduce node count by 40% without any pod evictions. Just smarter packing.
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: consolidation-heavy
spec:
template:
spec:
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "t3.*"
- "c5.*"
- "m5.*"
- "r5.*"
disruption:
consolidationPolicy: WhenUnderutilized
consolidateAfter: 5m
The consolidateAfter: 5m says "if a node drops below efficient utilization, wait 5 minutes then consolidate." That prevents flapping during traffic spikes.
One gotcha: consolidation doesn't work well with statefulsets using local SSDs. You'll need to annotate those pods with karpenter.sh/do-not-consolidate: "true".
Real Numbers: What You Actually Save
I'll give you three real examples. No fluff.
Client A (2025, FinTech): 8 clusters, 120 nodes average, running 40% spot. Moved to Karpenter with consolidation. Monthly EC2 bill dropped from $87K to $51K. Savings: $36K/month. That's $432K/year.
Client B (2024, SaaS): 3 clusters, 45 nodes average, 100% on-demand. Switched to Karpenter with spot-heavy config. Bill went from $23K to $9K. Savings: $14K/month. $168K/year.
Client C (2026, AI Startup): 12 GPU nodes running training workloads. Spot GPU instances are volatile — 40% interruption rate on p4d. But Karpenter's ability to fall back to on-demand meant they saved 55% on GPU costs while maintaining uptime.
None of these clients "left Kubernetes." They fixed their provisioning.
The Real Reason People Leave Kubernetes
Let's be honest. We're leaving Kubernetes stories aren't really about Kubernetes being broken. They're about Kubernetes being mismanaged.
The I Deleted Kubernetes from 70% of Our Services in 2026 — Saved $416K story is instructive. The author didn't delete Kubernetes because it was bad. They deleted it because they had 70 microservices that shouldn't have been on Kubernetes in the first place.
A cron job doesn't need a cluster. A webhook that runs twice a day? That's Lambda territory.
But for the workloads that do belong on Kubernetes — stateful services, streaming pipelines, ML inference — the cost problem is almost always a provisioning problem. And Karpenter solves that better than anything else in 2026.
Kubernetes isn't dead, you just misused it. captures this perfectly. The tool is fine. Our configuration was not.
Advanced: Karpenter for Multi-Arch and GPU Workloads
Multi-Arch (ARM + x86)
Graviton instances are 20-30% cheaper than x86 equivalents. But not everything runs on ARM. Karpenter handles this with node selectors.
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: arm
spec:
template:
spec:
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "c7g.*"
- "m7g.*"
- "r7g.*"
nodeClassRef:
name: arm
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: x86
spec:
template:
spec:
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "c7i.*"
- "m7i.*"
nodeClassRef:
name: x86
Pods that don't specify architecture will land on the cheapest available — usually ARM. Pods that need x86 get routed to the x86 pool. Karpenter handles the scheduling.
GPU Workloads
GPU instances are the wild west. p4d. p5. g5. Each has different pricing, availability, and interruption rates.
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: gpu-spot
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "g5.xlarge"
- "g5.2xlarge"
- "g5.4xlarge"
- "p4d.24xlarge"
nodeClassRef:
name: gpu
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 4h
Note the expireAfter: 4h. GPU spot instances are volatile. Rotate them more frequently. If one gets reclaimed, Karpenter spins up another within 2 minutes. Set PodDisruptionBudget on training jobs to handle the transition.
Migration Guide: Moving from Cluster Autoscaler to Karpenter
Don't do a big bang migration. I've done that. It's painful.
Step 1: Install Karpenter alongside Cluster Autoscaler. Both can coexist. Karpenter manages nodes it creates; Cluster Autoscaler manages nodes in node groups.
Step 2: Create a single NodePool with wide instance selection. Start with on-demand only. Validate pods land correctly.
Step 3: Enable spot after 72 hours. Monitor interruption rates. Adjust instance type list.
Step 4: Remove Cluster Autoscaler. Once Karpenter handles 100% of your nodes, delete the cluster autoscaler deployment and node groups.
Step 5: Enable consolidation. This is your final cost optimization lever.
The whole process takes 2-4 days for most clusters. I've done it in 8 hours for a small 5-node cluster.
Common Pitfalls (And How to Avoid Them)
Pitfall 1: Not setting resource limits. Karpenter can't optimize what it can't measure. Every pod needs requests and limits. If you skip them, Karpenter guesses — and guesses wrong.
Pitfall 2: Too few instance types. Three is not enough. Ten is a starting point. Karpenter's power is in choosing from a wide pool. Restrict it, and you lose flexibility (and money).
Pitfall 3: Ignoring expireAfter. Without it, nodes run forever. That's fine for stateful workloads, but wasteful for spot instances. Set 7 days for general workloads, 4 hours for GPUs.
Pitfall 4: Not monitoring spot interruptions. Karpenter handles reclaims, but you should track the rate. If >10% of spot nodes get reclaimed daily, your instance type list needs work.
Pitfall 5: Running Karpenter on the same node it manages. Don't. Run Karpenter on a Fargate pod or a small, dedicated worker node that's not managed by Karpenter. Otherwise, during consolidation, Karpenter might evict itself.
FAQ
Q: Does Karpenter work with EKS Fargate?
A: No — but you can run Karpenter on Fargate and have it manage regular EC2 nodes. That's actually a solid pattern.
Q: How does Karpenter handle node upgrades?
A: Automatically, via expireAfter. Old nodes get drained and terminated. Karpenter provisions replacement nodes with the latest AMIs. No manual upgrades.
Q: Can I use Karpenter with GPU instances on spot?
A: Yes. Set karpenter.sh/capacity-type: spot and watch interruption rates. Works best with small-to-medium GPU workloads. Large training jobs should run on on-demand or reserved.
Q: Does Karpenter support cross-AZ load balancing?
A: Natively. It spreads nodes across all zones in the AWSNodeTemplate. You can restrict with topology.kubernetes.io/zone.
Q: Will Karpenter make my pods restart?
A: During consolidation, yes — but only if it can reschedule them without downtime. DaemonSets, controllers, and statefulsets with PDBs are handled correctly. Stateless workloads get drained and rescheduled in seconds.
Q: How much does Karpenter cost?
A: Zero. It's free. You pay for the EC2 instances it provisions. That's the point — you only pay for compute you actually use.
Q: Is Karpenter production-ready in 2026?
A: Absolutely. Version 1.0 was released in early 2025. It's running thousands of clusters in production. AWS uses it internally.
The Bottom Line
Here's the thing about Kubernetes cost optimization: it's not about finding a cheaper cloud provider or switching to spot instances blindly. It's about matching compute supply to workload demand in real time.
Cluster Autoscaler did this poorly. Karpenter does it well.
I've seen clusters where the average utilization went from 34% to 72% just by switching to Karpenter with consolidation. The same workloads, same pods, same code. Just smarter scheduling.
If you're spending more than $10K/month on Kubernetes compute, you're leaving money on the table without Karpenter.
And if you're considering leaving Kubernetes entirely, try fixing your provisioning first. You might find, like I did, that the tool wasn't the problem.
The configuration was.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.