Karpenter Changed How We Think About Kubernetes Cost Optimization
I spent $47,000 last month on Kubernetes cluster overhead. Not on pods doing actual work. On unused capacity, node startup latency, and the Cluster Autoscaler's inability to tell a c6i.large from a c7g.medium.
That was February 2025. By May, I'd cut that number to $12,500. The difference? Karpenter.
Not magic. Not a cloud provider discount. Just a fundamentally better way to think about kubernetes cost optimization karpenter — matching compute to work, not work to compute.
Here's what I learned, what I got wrong, and what actually works.
The Problem Nobody Wants to Admit
Most Kubernetes clusters are overprovisioned by 30-50%. I've seen the data from 12 different production environments we've audited at SIVARO. The average is 38%. You're paying for iron you don't use.
Why Companies Are Leaving Kubernetes makes the point bluntly: the complexity tax is real. Teams spend 60% of their time managing infrastructure instead of shipping product. And the cost? It's killing margins.
But here's the contrarian take: Kubernetes isn't expensive. The way you're running it is expensive.
The Cluster Autoscaler is a blunt instrument. It scales node pools, not workloads. It doesn't understand that your Spark job can run on a spot instance but your Postgres operator can't. It doesn't know that Graviton costs 20% less per vCPU than Intel. It just sees "need more nodes" and provisions from whatever pool fits the request.
Karpenter sees different.
Karpenter vs Cluster Autoscaler Cost Comparison: The Numbers
Let me be specific. We ran this test in April 2026:
Cluster A — Cluster Autoscaler, 3 node pools (on-demand c5, spot c5, on-demand r5)
Cluster B — Karpenter, 1 provisioner with multiple instance family preferences
Both running identical workloads. 45 microservices, 3 stateful sets, 2 batch jobs per hour.
Result over 30 days:
| Metric | Cluster A (CA) | Cluster B (Karpenter) |
|---|---|---|
| Monthly compute cost | $41,230 | $28,900 |
| Nodes provisioned | 87 | 64 |
| Average pod density | 6.2 pods/node | 11.4 pods/node |
| Node startup time | 4-7 minutes | 45-90 seconds |
| Spot interruption rate | 3.2% | 1.1% |
A 30% reduction just by switching schedulers. Same workloads. Same availability requirements. Same cluster size limits.
The karpenter vs cluster autoscaler cost comparison isn't close. CA was built for a world where instances were homogeneous and you managed pools. Karpenter was built for a world where you have 600+ instance types across 3 availability zones and want to pick the cheapest one that fits your pod's exact requirements.
How Karpenter Actually Saves Money
1. It Picks the Right Instance Type (Every Time)
The Cluster Autoscaler adds nodes from a limited set you define. You might have 5 instance types per pool. Karpenter considers all of them. Every EC2 instance type. Every ARM, Intel, AMD processor. Every generation.
When a pod requests 2 vCPU and 4GB memory, Karpenter checks: "What's the cheapest instance that fits this exactly?" It might pick a t4g.small. It might pick a c7g.medium. It depends on current spot pricing and availability.
This matters because instance pricing varies wildly. A c5.xlarge costs $0.17/hr. A c6i.xlarge costs $0.136/hr. A c7g.xlarge costs $0.122/hr. That's 28% difference for equivalent compute.
yaml
# Karpenter provisioner that optimizes for cost
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: ["c6i.*", "c7g.*", "m6i.*", "m7g.*"]
nodeClassRef:
name: default
limits:
cpu: 1000
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
weight: 100
Notice: I didn't specify exact instance types. I gave patterns. Karpenter picks the cheapest match within those families.
2. Bin Packing That Actually Works
The Cluster Autoscaler is dumb about packing. It adds a node, schedules a pod, then another pod comes along and needs a different instance type — so it adds another node.
Karpenter consolidates. It watches utilization across nodes and says "I could move these 4 pods from 3 nodes onto 2 nodes, then terminate the third." It does this continuously.
In our production clusters, Karpenter reduced node count by 35% on average. That's 35% fewer EC2 instances to pay for.
3. Spot Instance Intelligence
Here's where most people get burned: they run spot instances and get interrupted, so they add overprovisioning buffer. The buffer costs more than the savings.
Karpenter handles interruption differently. When AWS sends a rebalance recommendation (2 minutes before termination), Karpenter drains the node and reschedules the pods. It doesn't wait for the termination. It predicts it.
yaml
# Spot handling with interruption tolerance
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: spot-optimized
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
- key: "karpenter.sh/capacity-type"
operator: NotIn
values: ["on-demand"]
nodeClassRef:
name: spot-class
taints:
- key: "spot"
value: "true"
effect: "NoSchedule"
---
apiVersion: v1
kind: Pod
metadata:
name: batch-processor
spec:
tolerations:
- key: "spot"
operator: "Exists"
effect: "NoSchedule"
containers:
- name: processor
image: batch:latest
resources:
requests:
cpu: 2
memory: 4Gi
priorityClassName: high-priority
We run 85% spot in our production clusters now. Interruption rate is under 2%. The savings fund the entire Kubernetes infrastructure.
4. No More Overprovisioning Daemons
Every team I've worked with runs some variation of the overprovisioning hack — empty pods with low priority that get evicted when real work arrives. The idea is to keep buffer nodes ready.
Karpenter's startup time kills this pattern. When a pod needs a node, Karpenter provisions it in under 90 seconds. You don't need buffer. You don't need overprovisioning. You don't need the cluster-autoscaler-priority-expander hack.
I Deleted Kubernetes from 70% of Our Services in 2026 talks about removing Kubernetes entirely for certain workloads. I think that's the right call for services that don't need orchestration. But for the ones that do, Karpenter removes the cost argument.
What Actually Broke When We Migrated
I'm not selling you a fairy tale. Migration was painful.
The Bottleneck Problem
Karpenter doesn't handle pods that need GPU instances well out of the box. We had ML training workloads that required p4d instances. Karpenter kept trying to schedule them on cheaper instances, failing, retrying, wasting 20 minutes per scheduling attempt.
Fix: explicit node pool for GPU workloads with strict instance type requirements.
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["p4d.24xlarge", "p4de.24xlarge"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
nodeClassRef:
name: gpu-class
limits:
cpu: 256
disruption:
consolidationPolicy: WhenEmpty
The StatefulSet Problem
StatefulSets with local SSDs break Karpenter's consolidation. It tries to move pods to cheaper nodes, but the PVC is tied to a specific availability zone. It can't move them.
Fix: topology constraints on the provisioner to match the statefulset's zone requirements.
The Learning Curve
Your operators know how CA works. They know how to tune --scale-down-delay-after-add, how to set up priority expanders, how to manage node groups in the cloud console.
Karpenter requires a different mental model. It's not about pools. It's about constraints. "This pod can run on anything that has at least 2 vCPU, uses ARM, and is in us-east-1a." You have to think in terms of requirements, not infrastructure.
Real Configuration: What We Run in Production
Here's our actual Karpenter setup as of July 2026. Three node pools:
Pool 1: General Purpose — Handles 80% of workloads. Spot preferred, on-demand fallback. Instance families: c7g, m7g, r7g (Graviton). Consolidated aggressively.
Pool 2: Performance — Memory-intensive workloads with burst requirements. Instance families: r6i, r7i. Spot only. Higher disruption tolerance.
Pool 3: Critical — Production stateful services. On-demand only. No consolidation. Instance families: c7g, m7g. These nodes get replaced on schedule, never evicted.
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodeClass
metadata:
name: general
spec:
amiFamily: Bottlerocket
subnetSelector:
karpenter.sh/discovery: production
securityGroupSelector:
karpenter.sh/discovery: production
role: KarpenterNodeRole
tags:
Environment: production
CostCenter: compute-general
The key insight: you need a NodeClass per pool (AMIs, subnets, security groups differ) but you can share them across pools if networking is uniform.
The Cost Optimization Playbook
Here's the exact process we use for kubernetes cost optimization karpenter engagements:
Step 1: Audit Current Spend
Get a breakdown by namespace, by deployment, by pod. Use Kubecost or OpenCost (both free tiers work). Find the 20% of workloads consuming 80% of resources.
At SIVARO, we found one team running 40 replicas of a service that handled 200 requests/day. They'd set replicas: 40 two years ago and never revisited.
Step 2: Rightsize First
Before Karpenter can optimize, your requests need to be realistic. We run VPA in recommendation mode for 2 weeks, then apply the suggested requests.
bash
# Get VPA recommendations
kubectl get vpa -o json | jq '.items[].status.recommendation.containerRecommendations[].target'
Step 3: Install Karpenter with Conservative Settings
Start with a single node pool, spot only, with on-demand fallback. Let it run for a week. Monitor interruption rates, pod scheduling latency, and cost.
Step 4: Enable Consolidation
Consolidation is where the savings come from. WhenUnderutilized mode will rearrange pods to fewer nodes. Watch for excessive churn — some clusters consolidate so aggressively that pods restart too often.
Step 5: Add Workload-Specific Pools
GPU workloads, stateful services, batch jobs — each gets its own pool with appropriate constraints. Keep the general pool as the default.
Step 6: Monitor and Tune
Karpenter exposes metrics. Track karpenter_nodes_created, karpenter_nodes_terminated, karpenter_allocation_duration_seconds. You want allocation under 60 seconds average. If it's higher, your instance type requirements are too restrictive.
When Not to Use Karpenter
I'm going to say something unpopular: Karpenter isn't for everyone.
If you have 3 nodes running 10 services, you don't need it. The Cluster Autoscaler is fine. Karpenter's complexity isn't justified by the savings.
If your workloads are 100% stateful with PVCs pinned to specific node types, Karpenter helps less. It can't consolidate across zones if PVCs are zone-bound.
If you're on-premises or using bare metal, Karpenter doesn't work. It's designed for cloud APIs that let you provision instances on demand.
And if you're thinking about leaving Kubernetes entirely, Karpenter won't fix the fundamental question of whether you need Kubernetes at all. Some teams genuinely don't. Kubernetes isn't dead, you just misused it — and part of that misuse is running it for workloads that would be happier on Lambda or ECS or a bare metal box.
The Future We're Building
By January 2027, I expect Karpenter will handle most of what we currently do manually. It's learning to predict workload patterns — scaling up before traffic spikes, consolidating during quiet periods. The disruption budget system already lets you define "never kill more than 10% of my pods at once" while still consolidating.
The next frontier is multi-cloud. We're testing on GKE with Karpenter. If it works, we'll spread workloads across AWS and GCP based on spot pricing. That's the endgame: the scheduler optimizes globally, not per-provider.
Your First 90 Days
Month 1: Install Karpenter alongside your existing autoscaler. Set a low weight. Watch what it would do compared to CA. Find the mistakes.
Month 2: Move non-critical workloads to Karpenter. Batch jobs, CI runners, development namespaces. Test consolidation. Measure cost changes.
Month 3: Migrate production workloads. Drain CA-managed nodes. Remove the Cluster Autoscaler deployment. Celebrate the 30% reduction.
Then start optimizing further. Add more instance families. Tolerate more spot interruptions. Push consolidation harder.
The equation is simple: Karpenter costs time to configure. It saves money every day. The break-even is usually 2-3 weeks. After that, you're running cheaper infrastructure with less manual effort.
That's not a sales pitch. That's the data from 6 production migrations this year.
FAQ
Q: Does Karpenter work with EKS Auto Mode?
A: Yes, since 2025. The AWS team integrated Karpenter as the default scheduler for EKS Auto Mode. The configuration surface is smaller but the core cost optimization features are there.
Q: What's the migration cost from Cluster Autoscaler?
A: About 2 engineering weeks for a team that knows Kubernetes. If you're learning both Kubernetes and Karpenter simultaneously, budget 4 weeks. Monte Carlo analysis from 5 migrations showed $12-18K in engineering time for clusters running >$50K/month compute.
Q: Does Karpenter handle Windows nodes?
A: Poorly. Windows pod support exists but the instance type selection isn't optimized. We don't recommend Karpenter for clusters with significant Windows workloads.
Q: How do I prevent Karpenter from terminating nodes too aggressively?
A: Use consolidationPolicy: WhenEmpty instead of WhenUnderutilized for sensitive workloads. Or set disruption.budgets to cap concurrent terminations. We use 10% max for production pools.
Q: Can Karpenter reduce spot interruption costs?
A: Yes, by about 60% compared to standard spot handling. The rebalance recommendation listener drains nodes before AWS terminates them, reducing failed requests. Our production data shows 1.1% pod failure rate from spot interruptions vs 3.2% with manual handling.
Q: Is Karpenter compatible with custom schedulers for batch or big data workloads?
A: We tested with Volcano (batch scheduling) and Ray (ML workloads). It works, but you need to configure node pools carefully. The custom scheduler handles pod placement within the pool; Karpenter handles provisioning and lifecycle management.
Q: What's the catch?
A: You need to understand your workloads to write good constraints. If you just install Karpenter with everything set to "any instance, any AZ, spot or on-demand", it'll work but won't optimize well. The cost savings come from thoughtful instance selection and consolidation configuration.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.