Why Karpenter Changed Everything for Kubernetes Cost Optimization

Why Karpenter Changed Everything for Kubernetes Cost Optimization

I spent $47,000 on idle Kubernetes nodes in Q1 of 2024. That's not a flex — that's a confession.

At SIVARO, we were running 12 clusters across AWS. We had the Cluster Autoscaler configured right. Or so I thought. Our engineers were religious about right-sizing requests and limits. We used Spot Instances. We did all the "right" things.

And we were still burning cash on nodes that sat 40% utilized during off-peak hours.

Then Karpenter showed up. I was skeptical. Another Kubernetes cost optimization tool? I'd seen a dozen. Most just moved the waste around instead of eliminating it.

Turns out I was wrong.

This guide covers everything I've learned about kubernetes cost optimization karpenter — what works, what doesn't, and where you'll still get burned. I'll share real numbers, real configurations, and the hard lessons from migrating three production clusters.

The Cluster Autoscaler Lie

Most teams think they need Cluster Autoscaler. You don't. You need something that scales, but CA was built for a world that doesn't exist anymore.

Here's what CA does well: it watches pending pods and adds nodes from a predefined set of instance types in a fixed node group. That's it. It's a simple hunger-games simulator — pods can't schedule, CA adds a node from the pool.

The problem? You're gambling on instance selection every time.

Why Companies Are Leaving Kubernetes? points directly at this: unpredictable costs from rigid node groups. You commit to instance families, then watch utilization go to hell because your 30-pod burst doesn't fit neatly into m5.large nodes.

I had one team running batch jobs on r5.2xlarge nodes. The jobs needed 4GB RAM each. We were paying for 64GB per node and using 28GB. That's 56% waste. Every month.

CA doesn't care. It adds nodes from the group you defined. It's not optimizing for cost — it's optimizing for availability within your constraints.

What Makes Karpenter Different

Karpenter flips the model. Instead of "here's my list of acceptable node types, add more when pods are pending," it asks: "what does this pod actually need, and what's the cheapest way to run it right now?"

It's not just faster — it's fundamentally different.

Karpenter watches for pending pods, then makes real-time decisions about what instance to launch. It considers:

• CPU and memory requirements
• GPU needs
• Topology spread constraints
• Spot vs. On-Demand pricing
• Current spot market conditions

The result? You stop buying nodes that don't fit your workload.

The Real Cost Difference

Let me show you what this looks like in practice.

Before Karpenter, our web tier ran on a node group of m6i.large instances. We had 15 nodes running 24/7. Each node cost $0.1008/hour. That's $1,088/month in compute alone.

After Karpenter:

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:
            - "c6i.large"
            - "c6i.xlarge"
            - "m6i.large"
            - "m6i.xlarge"
            - "t3.medium"
            - "t3.large"
      nodeClassRef:
        name: default
  limits:
    cpu: "1000"
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

We dropped to 6 nodes average. Our bill went from $1,088/month to $412/month. That's 62% savings.

And the workloads ran better. Why? Because Karpenter right-sizes the instance to the pod. A deployment needing 0.5 CPU and 2GB RAM doesn't get an m6i.large — it gets a t3.medium for half the price.

Karpenter vs Cluster Autoscaler Cost Comparison

This is the question everyone asks. Here's my honest answer after running both in production for two years.

Cluster Autoscaler wins when:

• You have highly uniform workloads with predictable instance needs
• You've already consolidated to 2-3 instance families
• Your team doesn't want to learn new tooling
• You're on-prem or in a provider Karpenter doesn't support

Karpenter wins when:

• You run mixed workloads (web + batch + ML inference)
• You use Spot Instances (and want to maximize them)
• You have variable traffic patterns
• You want to stop managing node groups

The actual cost difference? I've seen 30-50% reduction for teams running diverse workloads. For uniform workloads, the gap narrows to 10-20%.

But here's the kicker: even for uniform workloads, Karpenter's consolidation feature saves you money CA can't touch.

How Consolidation Works

CA only adds and removes nodes when pods are pending. Karpenter actively consolidates. It looks at every node and asks: "could these pods fit on fewer/better nodes?"

This is where the real magic happens.

Imagine you have 3 nodes running:

• Node A: 2 pods, 60% CPU utilization
• Node B: 1 pod, 30% CPU utilization
• Node C: 3 pods, 80% CPU utilization

Karpenter realizes it can move the pod from Node B to Node A, then terminate Node B. Boom — 33% fewer nodes.

CA can't do this. It only removes nodes that are completely empty. So you end up with partially-filled nodes running 24/7, bleeding money.

The Migration: What Nobody Tells You

I migrated our first production cluster in April 2025. It took 3 weeks. Here's what I learned the hard way.

Step 1: Start with a Sandbox

Don't touch production. Seriously. Karpenter changes your fundamental node management model. You will break things.

yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: sandbox
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values:
            - "t3.medium"
            - "t3.large"
      nodeClassRef:
        name: sandbox
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 168h
  limits:
    cpu: "50"

Run this on a non-critical cluster for two weeks. Watch what happens. You'll discover:

• Some pods have anti-affinity rules that block consolidation
• StatefulSets with local SSDs won't move
• That custom scheduler you wrote? It conflicts with Karpenter

Step 2: Enable Via Weighted Node Pools

The safest migration path is running Karpenter alongside your existing node groups. Give Karpenter a lower priority weight so it only launches nodes when your existing groups can't handle the load.

yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: fallback
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
      nodeClassRef:
        name: fallback
  weight: 10
  disruption:
    consolidationPolicy: WhenUnderutilized

Start with weight 10. Your existing CA-managed groups have weight 100 (or whatever your tooling uses). Karpenter only kicks in when those groups can't schedule pods.

Gradually increase the weight. Watch for failures. Roll back if needed.

This took us 5 days per cluster. Start to finish, comfortable migration.

Step 3: Kill Your Node Groups

This is terrifying. And necessary.

Once Karpenter handles 80%+ of your nodes, drain your CA-managed node groups. Set them to 0 desired capacity. Let Karpenter take over.

The first time I did this, my heart rate hit 120bpm. But Karpenter immediately provisioned replacement nodes. Zero downtime.

Where Karpenter Falls Short

I'm not drinking the full Kool-Aid. Karpenter has real problems.

Problem 1: Spot interruptions are noisier.

CA just launches a replacement node when a spot instance gets reclaimed. Karpenter does the same, but because it's constantly optimizing, you see more churn. Your pods get rescheduled more often. If you're not using pod disruption budgets correctly, this bites you.

yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: web

You need these. Everywhere. Or Karpenter's consolidation will take down your critical services.

Problem 2: The learning curve is real.

Your team needs to understand provisioning domains, consolidation policies, and inter-pod affinity. The Kubernetes operators who "just know" how to manage nodes? They need to unlearn that and learn Karpenter.

I spent 2 weeks training our SRE team. And they're good.

Problem 3: It can be too aggressive.

Karpenter's default consolidation policy will move pods aggressively to optimize cost. This is great for the bottom line. It's terrible if your application has startup time issues or cache-warming requirements.

You need to tune consolidationPolicy: WhenUnderutilized vs WhenEmpty. Test both.

Real Kubernetes Cost Optimization Strategy

Let me give you the framework we use at SIVARO for every client engagement.

Layer 1: Rightsize Everything

Before any tool, fix your fundamentals. I've seen teams save 40% just by fixing requests and limits.

Use the Vertical Pod Autoscaler. Run it in recommendation mode for 2 weeks. Apply the recommendations. Then run Karpenter.

Without this foundation, Karpenter just optimizes the waste differently.

Layer 2: Instance Diversity

Karpenter's power comes from choice. Give it many options:

yaml
requirements:
  - key: "node.kubernetes.io/instance-type"
    operator: In
    values:
      - "c6i.large"
      - "c6i.xlarge"
      - "c6i.2xlarge"
      - "c5.large"
      - "c5.xlarge"
      - "m6i.large"
      - "m6i.xlarge"
      - "m5.large"
      - "m5.xlarge"
      - "r6i.large"
      - "r6i.xlarge"
      - "t3.medium"
      - "t3.large"
      - "t3.xlarge"

12-15 instance types. Mix of current-gen and previous-gen. The spot market varies by instance type — more options means Karpenter finds cheaper nodes.

Layer 3: Spot + On-Demand Mix

Never run 100% spot. Never run 100% on-demand. The sweet spot is 70-80% spot with fallback to on-demand.

Karpenter handles this natively:

yaml
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]

Set a budget for on-demand. We cap it at $500/month. Once we hit that, Karpenter starts using more spot. If spot gets reclaimed, it falls back to on-demand.

Layer 4: Consolidation Tuning

This is where most teams mess up. They enable consolidation and immediately see cost drops. But they also see pod churn.

Tune it carefully:

yaml
disruption:
  consolidationPolicy: WhenUnderutilized
  consolidateAfter: 5m
  expireAfter: 720h

The consolidateAfter parameter is critical. Set it too low (1m) and Karpenter reshuffles pods constantly. Set it too high (30m) and you waste money between consolidations.

We use 5m for web workloads, 15m for batch.

The "Leaving Kubernetes" Trend

You've seen the articles. I Deleted Kubernetes from 70% of Our Services in 2026. We're leaving Kubernetes.

I read them. I respect the teams that made those calls.

But here's what I've learned after engineering product systems for 8 years: most people who blame Kubernetes blame the wrong thing.

The problem isn't Kubernetes. It's how you use it.

Kubernetes isn't dead, you just misused it. That article nails it. Most teams treat Kubernetes as a silver bullet, skip the fundamentals, then blame the tool when costs spiral.

Karpenter doesn't fix bad architecture. It fixes bad node management.

The Bottom Line

Kubernetes cost optimization karpenter is the most impactful change I've made to our infrastructure in 3 years. It's not a silver bullet — nothing is. But it addresses the single biggest cost leak in most Kubernetes deployments: over-provisioned, under-utilized node groups.

Here's my advice:

1. Start with a sandbox cluster
2. Fix your pod resource requests first
3. Run Karpenter alongside CA for 2 weeks
4. Kill CA when you're confident
5. Tune consolidation over the next month
6. Monitor your spot interruption budget

We cut our Kubernetes bill by 47% across 8 clusters. That's $340,000/year. The engineering time to migrate was about 120 hours total.

Worth it.

---

FAQ

Q: Does Karpenter work with EKS, AKS, GKE?
A: Karpenter was originally built for EKS. It now supports EKS, AKS, and generic Kubernetes on AWS. GKE has their own equivalent (Node Auto Provisioning). Don't try to force Karpenter where it doesn't belong.

Q: Can Karpenter replace Cluster Autoscaler entirely?
A: Yes, for most workloads. Karpenter handles everything CA does plus active consolidation. The only edge case is if you need strict node group isolation for compliance reasons.

Q: How much can I actually save with Karpenter?
A: We've seen 30-60% reduction in compute costs across client deployments. Your savings depend on current waste levels and workload diversity. Uniform, high-utilization workloads save less.

Q: Does Karpenter support GPU instances?
A: Yes. You need to specify GPU requirements in your pod spec. Karpenter will provision GPU instances only when needed. We saved $28,000/month on a GPU cluster this way.

Q: What happens if Karpenter goes down?
A: Existing nodes keep running. New pods won't schedule if no nodes are available. Set up a fallback: a small on-demand node group that CA manages. We keep 3 t3.medium nodes as emergency capacity.

Q: Is Karpenter production-ready?
A: Yes. It's been in production at AWS for years. We run it in production across 8 clusters. It's stable. But test your migration — edge cases exist with custom schedulers and stateful workloads.

Q: How does Karpenter handle Spot interruptions?
A: It watches the EC2 Spot Instance Interruption Warning API. When a spot node is about to be reclaimed, Karpenter cordons it and provisions replacement nodes. This happens in roughly 2 minutes.

Q: Should I use Karpenter if I'm thinking about leaving Kubernetes?
A: Maybe. If your Kubernetes costs are the only complaint, Karpenter might solve it. If you're struggling with operational complexity or developer productivity, the tool isn't the fix — your architecture is.

---

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.