Why I Bet the Farm on Karpenter Consolidation and Cut Compute by 40%
I run SIVARO. We build data infrastructure and production AI systems for companies that can't afford downtime — or waste. In 2025, I watched one of our clients burn $87,000 in a single month on underutilized Kubernetes nodes. Spot instances sat idle. On-demand instances ran full tilt for workloads that could have been batched.
That client went from $87K to $52K — a 40% drop — in two months. The tool? Karpenter consolidation.
Not a new cluster. Not a cloud migration. Not layoffs.
A configuration change.
Here's what I learned, what I got wrong, and how you can apply the karpenter consolidation strategy to reduce compute costs right now without rewriting your entire platform.
What Karpenter Consolidation Actually Is
Let me kill the buzzword first.
Karpenter is an open-source node autoscaler for Kubernetes. You install it on your cluster. It watches pod resource requests, node capacity, and cloud provider pricing. When it sees a node that's underused, it consolidates — moves those pods to other nodes, terminates the underused one, and replaces it with something cheaper or smaller.
That's the 10,000-foot view.
The karpenter consolidation strategy to reduce compute costs specifically focuses on three levers:
- Node size consolidation — Replacing multiple small nodes with fewer large ones (or vice versa, depending on workload).
- Instance type optimization — Moving from expensive instance families (m5.xlarge at $0.192/hr) to cheaper ones (c7g.2xlarge at $0.163/hr) for the same workload.
- Spot instance gymnastics — Preferring spot instances aggressively while maintaining capacity for bursty or critical workloads.
Most people think consolidation is just "turn on spot instances." That's like saying "losing weight is just eating less." Sure, technically. But the details matter.
The $87K Mistake I Almost Made
At first I thought consolidation was a branding problem — turns out it was pricing.
We had a client in late 2024 running a 40-node cluster for their ML inference pipeline. Standard cluster autoscaler. No consolidation. They had 14 nodes running at 12% utilization because of stuck pods from failed taint-based scheduling.
Standard story. Everyone's seen it.
We shipped Karpenter v0.37 into their cluster (yes, we do the risky stuff). First results? Consolidation kicked in within 12 minutes. It terminated 9 nodes. Pods rescheduled. Everything kept running.
But here's the trap: Karpenter consolidation isn't fire-and-forget.
We ran it for a week. Costs dropped 22%. I felt like a genius. Then the next week, costs went back up 8% because the consolidation algorithm kept cycling nodes — terminating one, spinning up another, terminating that one. Churn.
We had to tune consolidationPolicy: WhenUnderutilized and set minimum free capacity thresholds. After that, stable 40% reduction.
How Karpenter Consolidation Works (The Quick Technical Tour)
Karpenter watches two things: pods waiting to be scheduled, and nodes that exist. It runs a reconciliation loop. When it finds a node that can be drained without leaving pods unscheduled, it:
- Cords the node
- Evicts pods gracefully
- Terminates the node
- Lets the new pod scheduling trigger a new node if needed
That's the "when underutilized" variant. There's also WhenEmpty — only consolidates if a node has zero pods. And WhenUnderutilized — consolidates even if there are a few pods, as long as they can fit elsewhere.
Here's a real config I use now:
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: ["m5.large", "m5.xlarge", "c5.2xlarge", "c6g.2xlarge"]
nodeClassRef:
name: default
consolidation:
enabled: true
policy: WhenUnderutilized
limits:
cpu: 1000
That consolidation.policy: WhenUnderutilized line is doing the heavy lifting. It tells Karpenter: don't just look at empty nodes. Look at any node where pods could be consolidated into fewer or cheaper instances.
The Spot Instance Bet That Paid Off
Let's talk about karpenter spot instance cost savings kubernetes specifically.
I have a contrarian take: most people are too scared of spot instances. They reserve 30% of capacity for spot, leave 70% on-demand. Then they complain about compute costs.
We tested a different approach at SIVARO: block-reserved on-demand for exactly the minimum critical base load. Everything else — spot-first. With consolidation.
The setup:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: spot-first
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
nodeClassRef:
name: default
consolidation:
enabled: true
policy: WhenUnderutilized
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: on-demand-fallback
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
nodeClassRef:
name: default
disruption:
consolidationPolicy: WhenEmpty
The trick? Two nodepools. Spot-first gets WhenUnderutilized. On-demand gets WhenEmpty. That means spot instances consolidate aggressively. On-demand only consolidates when they're completely empty — because on-demand costs more per hour, waiting to consolidate an underutilized on-demand node costs you money every minute.
We saw spot usage go from 35% to 78%. Cost drop: 37%.
But there's a catch I don't see people talk about: karpenter consolidation strategy to reduce compute costs works best when your workloads are interruption-tolerant. If you have stateful databases on spot, you're going to have a bad time. We learned that the hard way with a PostgreSQL cluster on spot instances. Three interruptions in one week. Never again.
What the Industry Gets Wrong About Kubernetes Costs
There's a lot of noise right now about leaving Kubernetes. People point to the Why Companies Are Leaving Kubernetes article, or stories like I Deleted Kubernetes from 70% of Our Services in 2026. They say Kubernetes is too expensive.
Most of the time, they're not wrong — but they're blaming the wrong thing.
The issue isn't Kubernetes. It's bad configuration. Specifically: overprovisioning, no consolidation, and ignoring spot pricing.
Here's what I mean: in 2025, I audited a cluster for a fintech company. They were running 120 nodes. Average pod utilization: 19%. They had requests set to 500m CPU for every pod regardless of actual usage. The cluster autoscaler was scaling up because of resource fragmentation — pods spread across nodes, leaving holes that couldn't be filled.
Karpenter consolidation fixed that in two hours. They went from 120 nodes to 73. Costs dropped 44%.
The company that deleted 70% of their services? They had similar problems. But instead of tuning their autoscaler, they ripped out Kubernetes. That's one valid approach. But it's expensive and disruptive. A consolidation strategy costs you a few days of configuration.
As the Kubernetes isn't dead, you just misused it article points out — most cost problems are configuration problems, not platform problems.
Advanced Consolidation Tactics (That Most People Skip)
1. Weighted Instance Families
Don't let Karpenter pick any random cheap instance type. You'll end up on burstable instances like t3.medium that throttle your CPU after credits run out. That's fine for idle services. Terrible for latency-sensitive inference.
Instead, weight instance families:
yaml
spec:
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.large", "m5.xlarge", "c5.2xlarge", "c6g.2xlarge"]
- key: "karpenter.sh/weight"
operator: In
values: ["20", "30", "40", "10"]
Map weights to cost-efficiency. We found c6g.2xlarge (Graviton) costs 25% less than m5.xlarge for the same CPU. So we gave it higher weight. Karpenter prefers it. Consolidation works harder to move workloads there.
2. Pod-Level Anti-Consolidation
Some pods should never be consolidated. Like a critical Prometheus instance running on bare metal with local SSDs. Or a database with strict node affinity.
You can add a label to prevent Karpenter from touching those nodes:
yaml
apiVersion: v1
kind: Pod
metadata:
labels:
karpenter.sh/do-not-disrupt: "true"
spec:
nodeSelector:
karpenter.sh/do-not-disrupt: "true"
We use this for our control plane components. Everything else is fair game.
3. Time-Based Consolidation Windows
This is where it gets interesting.
Not all workloads are equal at all hours. Our AI batch processing runs from 2 AM to 6 AM. During that window, we actually disable consolidation because the batch jobs consume all available capacity. Consolidating during batch processing would just add overhead.
Here's a simple scheduler approach:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: batch-window
spec:
disruption:
consolidationPolicy: WhenUnderutilized
schedule:
cron: "0 2 * * *"
action: DisableConsolidation
duration: 4h
Not a native Karpenter feature yet, but you can hack it with a mutating webhook or a simple cronjob that toggles the consolidation field.
The Real Numbers (Stop Guessing)
Let me give you hard numbers from three clients we worked with in 2025-2026:
| Client | Nodes Before | Nodes After | Monthly Compute Cost Before | After | Savings |
|---|---|---|---|---|---|
| Fintech (batch ML) | 120 | 73 | $248K | $139K | 44% |
| E-commerce (web + worker) | 47 | 29 | $93K | $58K | 38% |
| AI inference (real-time) | 34 | 22 | $71K | $46K | 35% |
That "AI inference" client? They couldn't use spot instances because latency requirements were sub-50ms. Consolidation still saved 35% just by right-sizing nodes and using cheaper instance families.
How to reduce Kubernetes costs with Karpenter isn't theory. It's cash.
Risks You Can't Ignore
I'm not going to sell you a fairy tale.
Karpenter consolidation has sharp edges:
- Pod disruption budgets matter. If your PDB is too permissive, Karpenter will drain pods that shouldn't be drained. Set
maxUnavailable: 1for stateful workloads. - Node termination can leave orphaned PVCs. We had a statefulset lose an EBS volume because the node was terminated before the PVC was detached. Add termination grace periods.
- Spot interruption plus consolidation can cause cascade failures. If Karpenter is already consolidating, and AWS reclaims 3 spot instances simultaneously, you can lose capacity faster than pods can reschedule. We now set
limits.cputo 20% overprovision for this exact reason.
Here's a safety net we use:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: balanced
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
kubelet:
maxPods: 58
consolidation:
enabled: true
policy: WhenUnderutilized
limits:
cpu: 500
memory: 2000Gi
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: critical-base
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
nodeClassRef:
name: default
consolidation:
enabled: false
limits:
cpu: 100
memory: 400Gi
Critical-base never consolidates. It's your insurance. Balanced does all the aggressive work.
When Consolidation Isn't Enough
Let me be clear: consolidation is not a magic wand.
If your actual application code is bloated — each pod consuming 4GB of memory when it needs 1GB — consolidation won't fix that. You'll just consolidate onto bigger nodes and pay the same.
And if your team is spending 40 hours a week fighting Kubernetes itself, not just costs, then maybe the We're leaving Kubernetes argument has merit. I've seen teams where the operational burden of maintaining a cluster outweighs the savings from consolidation. That's a judgment call.
But for teams that already run Kubernetes well — or are willing to invest two weeks in getting it right — consolidation is the single highest-ROI change you can make.
Your Next 7 Days
If you want to apply the karpenter consolidation strategy to reduce compute costs starting Monday:
- Day 1: Install Karpenter (it's a Helm chart). Set up one nodepool with
consolidation: { enabled: true, policy: WhenUnderutilized }. - Day 2: Run it on a small cluster. Watch for disrupted pods. Check logs for failed evictions.
- Day 3: Tune PDBs. Add
karpenter.sh/do-not-disruptto critical pods. - Day 4: Add a spot-first nodepool. Move stateless workloads there.
- Day 5: Enable weighted instance families.
- Day 6: Monitor costs in your cloud console. Compare to previous week.
- Day 7: Adjust limits. Set buffer capacity.
You'll see results in hours, not weeks.
FAQ
Does Karpenter consolidation work with EKS, GKE, and AKS?
Yes. Karpenter is cloud-agnostic. Works with AWS (EKS), Azure (AKS), and on-prem. GKE has its own equivalent (node auto-provisioning) but Karpenter is more flexible.
Will consolidation break my stateful applications?
It can, if you don't set pod disruption budgets. Use maxUnavailable: 1 and add termination grace periods. For databases on persistent volumes, consider pinning those pods to specific nodes with node selectors.
How long does it take to see cost savings?
Minutes. Karpenter starts consolidating within one reconciliation cycle (default 5 minutes). We saw 22% reduction in day one of real workloads.
Can I use consolidation with spot instances only?
Yes. That's where the biggest savings come from. But you need a fallback nodepool for on-demand capacity when spot is unavailable or for workloads that require guaranteed capacity.
Does consolidation affect application performance?
Short interruption during pod evictions — usually less than 30 seconds. For stateless web services, that's fine. For batch jobs, it can retry. For real-time inference, use PDBs and test with production traffic in a canary cluster first.
How does this compare to the standard cluster autoscaler?
Standard cluster autoscaler only adds or removes nodes based on pod scheduling. It doesn't proactively consolidate underused nodes. Karpenter continuously optimizes. Standard autoscaler is a fire extinguisher. Karpenter is a thermostat.
Is consolidation worth it for small clusters (less than 10 nodes)?
Honestly? Maybe not. The operational overhead of Karpenter — configuring nodepools, monitoring, tuning — may exceed the savings for a 5-node cluster. For clusters under $10K/month, just size your nodes manually and move on.
The Bottom Line
I've been building production systems since 2018. I've seen teams burn money on Kubernetes because they treated it as a "just add nodes and pray" platform. The ones who win are the ones who treat it as a cost optimization problem from day one.
The karpenter consolidation strategy to reduce compute costs isn't a silver bullet. But it's the closest thing I've found in the Kubernetes ecosystem. It's free. It's open source. It works.
You don't need to leave Kubernetes. You need to stop treating compute like it's infinite.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.