How to Reduce Kubernetes Costs With Karpenter Today

How to Reduce Kubernetes Costs With Karpenter Today

I've been running Kubernetes in production since 2018. I've seen teams burn money like it's confetti at a New Year's party — then blame the orchestrator.

Here's the truth: Kubernetes isn't the cost problem. Your autoscaler is. And if you're running the standard Cluster Autoscaler in 2026, you're leaving money on the table.

I'm Nishaant Dixit. At SIVARO, we manage data infrastructure that processes 200K events per second. We cut our Kubernetes compute bill by 43% in three months. Karpenter was the lever.

Let me show you how.

Why Your Current Autoscaler Is Burning Cash

Most teams think "autoscaling" means "Cluster Autoscaler + some spot instances." That's the 2024 playbook. It's broken.

Here's what Cluster Autoscaler does: it sees unschedulable pods, provisions a new node from a predefined group, and waits. That wait? It's 3-8 minutes on average. During that time, your pods sit pending. Your users feel latency. Your engineers add buffer capacity to compensate — which runs 24/7 whether you use it or not.

We tested this at SIVARO with one of our batch processing workloads. We had 15% overprovisioning baked in just to handle scale-ups. That's 15% waste. Always.

And it gets worse. Cluster Autoscaler works with node groups. You define instance types, zones, and sizes upfront. When your workload changes — say a new ML inference service needs GPU — you update configs, roll out node groups, and pray nothing breaks.

Why Companies Are Leaving Kubernetes? nails the core complaint: "Kubernetes is too complex for what it delivers." Most of that complexity? It's not Kubernetes itself. It's the hacks you stack on top of a scheduler that wasn't built for cost optimization.

Here's what nobody tells you: Karpenter isn't just a faster Cluster Autoscaler. It's a fundamentally different model.

Karpenter vs Cluster Autoscaler Cost Comparison — The Real Numbers

Let me give you a specific baseline. At SIVARO, we ran a side-by-side test in March 2026. Same cluster, same workloads, same spot usage ratio (60% spot, 40% on-demand). Here's what we saw:

Metric	Cluster Autoscaler	Karpenter
Node provisioning latency	4.2 min avg	47 seconds avg
Average node utilization	62%	84%
Spot interruption handling	6 min to replace	38 seconds to replace
Overprovisioning buffer	15%	4%
Monthly cost (5 node cluster)	$12,400	$7,080

The karpenter vs cluster autoscaler cost comparison isn't close. Karpenter uses a "bin packing" strategy that's smarter and faster. It doesn't pre-define node groups. It picks the cheapest instance type that fits your pods right now, provisions it in under a minute, and terminates it as soon as the pods are gone.

That 38-second spot interruption handling? That's the killer feature. When AWS reclaims a spot instance, Karpenter doesn't wait for the node to drain and re-provision. It preemptively migrates the pods and spins up a replacement — often before the termination notice finishes.

How to Configure Karpenter for Spot Instances (Without Losing Sleep)

Most people think spot instances are fragile. They're wrong — if you configure them right.

Here's the config we run in production. It's opinionated. It works.

yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: spot-optimized
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["c6a.large", "c6i.large", "c7a.large", "m6a.large", "m7a.large", "r6a.large"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-east-1a", "us-east-1b", "us-east-1c"]
      nodeClassRef:
        name: default

Notice what's missing: no instance size constraints beyond "large". Karpenter will pick the cheapest available spot "large" across families. If AWS needs c6a back, Karpenter shifts to c7a in seconds.

The consolidationPolicy: WhenUnderutilized flag is critical. It tells Karpenter: if a node drops below efficient utilization, consolidate pods onto fewer nodes and kill the empties. We've seen this cut node count by 30% on low-traffic weekends without any intervention.

But here's the counterintuitive part — don't use spot for everything. We run stateful workloads (Kafka brokers, Postgres replicas) on on-demand with a small reserved instance commitment. Spot is for stateless APIs, batch jobs, and ML inference services that can handle interruptions.

The Three Levers That Actually Reduce Costs

I've fielded this question from CTOs at four different startups this year. "How to reduce kubernetes costs with karpenter" — they all want a magic button. There isn't one. But there are three specific levers that matter.

Lever 1: Instance Diversity

Single-instance-type clusters are expensive. You're paying a premium for the one type you chose, and you can't take advantage of spot price fluctuations.

Karpenter lets you specify ranges of instance types. We use this:

yaml
spec:
  requirements:
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: ["c5", "c5a", "c6a", "c6i", "c7a", "m5", "m6a", "m7a", "r5", "r6a"]
    - key: "karpenter.k8s.aws/instance-size"
      operator: In
      values: ["2xlarge", "4xlarge"]

This gives Karpenter ~40 instance types to choose from. It'll pick the cheapest one available right now. On spot, that means savings of 70-85% over on-demand prices for the same compute capacity.

Lever 2: Consolidation Aggressiveness

You can tune how aggressive Karpenter is about consolidating. Default is moderate. We run WhenUnderutilized — it's the most aggressive option.

But here's the trap: aggressive consolidation works for batch jobs and APIs. It's terrible for stateful workloads that hold connections or cache data. We learned this the hard way when a Redis cluster collapsed during consolidation. Lesson learned — separate your NodePools by workload type.

Lever 3: Spot Fallback with Grace Period

Spot instances get reclaimed. It's not "if", it's "when". But you can configure grace periods and fallback policies.

yaml
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
    budgets:
      - nodes: 10%
        duration: 1h
        schedule: "0 9 * * 1-5"

This says: don't consolidate more than 10% of nodes during business hours on weekdays. Reduces customer impact while still optimizing.

Real Workloads, Real Savings — Two Case Studies

Case Study 1: ML Inference Pipeline

A client of ours runs real-time object detection for manufacturing plants. Their workload is spiky — sensors trigger inference batches that last 30-90 seconds, then idle for 2-5 minutes. Before Karpenter, they ran 12 nodes 24/7.

We migrated to Karpenter with spot instances and aggressive consolidation. Now they run an average of 5 nodes, with peaks of 14. Monthly cost dropped from $38K to $21K. The best part? Their P95 latency actually improved because Karpenter provisions GPU instances (p3.2xlarge, g4dn.xlarge) in under a minute versus the 7-minute wait with Cluster Autoscaler.

Case Study 2: SaaS API Backend

Another client has a multi-tenant SaaS platform with predictable daily traffic — morning peak in US East, evening peak in US West. They were running a static cluster of 30 nodes.

We set up two NodePools: one for the US East zone with spot diversity, one for US West. Karpenter shifts capacity between zones as traffic patterns change. They now run 18 nodes during off-peak, spiking to 28 during peaks. Savings: 37%. And they stopped paying for cross-region data transfer because pods get scheduled in the zone where traffic originates.

When Karpenter Doesn't Save You Money

Let me be honest. I've seen teams try Karpenter and still fail to reduce costs. Usually for three reasons:

1. You overprovision requests. If you set CPU requests at 2 cores but your pods use 0.3, Karpenter will bin pack based on 2 cores and leave waste. Fix your resource requests first.

2. You don't use HPA. Karpenter handles node-level scaling. Pod-level scaling is still your job. If you have 3 replicas running 24/7 that could be 1 replica at night, Karpenter can't help.

3. You have too many services. I Deleted Kubernetes from 70% of Our Services in 2026 — ... makes a brutal point: some services shouldn't be in Kubernetes at all. If your workload runs fine on 2 VMs with a load balancer, don't put it on Kubernetes. The overhead alone — nodes, control plane, monitoring — will eat your savings.

Kubernetes isn't dead, you just misused it. argues the same thing: "Kubernetes is a platform for complexity. Don't use it for simplicity."

How to Configure Karpenter for Spot Instances — The Playbook

Here's what we deploy as our standard playbook. Copy it. Adapt it.

yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: workload-cpu-spot
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", "c5a", "c6a", "c6i", "c7a", "m5", "m6a", "m7a"]
        - key: "karpenter.k8s.aws/instance-size"
          operator: In
          values: ["large", "xlarge", "2xlarge", "4xlarge"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-east-1a", "us-east-1b", "us-east-1c"]
      nodeClassRef:
        name: default
      taints:
        - key: "workload-type"
          value: "cpu"
          effect: "NoSchedule"
  limits:
    cpu: 1000
    memory: 4000Gi
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
    budgets:
      - nodes: 10%
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: workload-memory-on-demand
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["r5", "r6a", "r7a"]
        - key: "karpenter.k8s.aws/instance-size"
          operator: In
          values: ["large", "xlarge", "2xlarge", "4xlarge"]
      nodeClassRef:
        name: default
      taints:
        - key: "workload-type"
          value: "memory"
          effect: "NoSchedule"
  limits:
    cpu: 300
    memory: 1200Gi
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

Two NodePools. One for CPU-intensive spot workloads (with on-demand fallback if spot is unavailable). One for memory-intensive on-demand workloads. We tier-pod with tolerations to control placement.

The "Cluster Autoscaler" Trap Most Teams Fall Into

Let me be blunt — if you're still running Cluster Autoscaler in July 2026, you're paying a 20-40% premium for no reason.

I keep seeing teams migrate to Karpenter, see the cost drop, then ask "why didn't we do this earlier?" The answer is usually fear of change. Or the belief that "if it works, don't fix it."

But "works" is the lowest bar. Your infrastructure should be efficient.

The karpenter vs cluster autoscaler cost comparison keeps showing the same pattern: Cluster Autoscaler wins on simplicity (you configure node groups once and forget them). Karpenter wins on everything else — speed, cost, flexibility.

FAQ

Q: Does Karpenter work with EKS only?
A: Yes, as of July 2026. Karpenter is AWS-specific. For Azure, you'd want Karpenter for AKS (still in preview). For GCP, look at Karpenter for GKE (also preview). Stick to EKS for production use.

Q: How long does it take to migrate from Cluster Autoscaler to Karpenter?
A: We've done it in 2 hours for simple clusters. Complex setups with multiple node groups and custom taints took a weekend. The key is to disable Cluster Autoscaler, remove node group labels, and let Karpenter take over.

Q: Can Karpenter handle GPU workloads?
A: Yes. We run p3, p4, g4dn, and g5 instances with Karpenter. The key is specifying GPU instance types in the NodePool requirements and setting the correct tolerations on your pods.

Q: What about stateful workloads like databases?
A: Use on-demand NodePools with consolidation disabled. Karpenter still provisions and deprovisions nodes, but without consolidating. For truly critical databases (Postgres, etc.), use a dedicated NodePool with no consolidation and a long expiry (30+ days).

Q: How do I monitor Karpenter costs?
A: We export Karpenter metrics to Prometheus and visualize in Grafana. The key metrics: node count by capacity type, spot interruption rate, consolidation savings, and average node utilization. Karpenter also has a karpenter_savings metric that estimates savings versus on-demand.

Q: What happens if spot instances get reclaimed during a critical workload?
A: Configure PodDisruptionBudgets with maxUnavailable set appropriately. Also set karpenter.sh/disruption-budget on your NodePool. We run critical workloads with a do-not-disrupt annotation that Karpenter respects — it won't consolidate nodes with those pods.

Q: Is there a risk of vendor lock-in?
A: Yes. Karpenter is AWS-specific. But so is EKS. If you're on EKS, you're already locked in. The trade-off is real savings. We're leaving Kubernetes shows that some teams are moving away from Kubernetes entirely for simpler setups. If Karpenter locks you into AWS deeper, that's a choice you make knowingly.

Q: How to reduce kubernetes costs with karpenter — what's the first step?
A: Start with a cost audit. Identify which workloads are over-provisioned. Fix pod resource requests. Then install Karpenter on a non-production cluster and watch what it does. The savings will sell themselves.

The Bottom Line

Kubernetes isn't dead. It's not even dying. But the way most teams use it — with bloated clusters, slow autoscalers, and zero cost optimization — is dying.

Kubernetes isn't dead, you just misused it. captures this perfectly: the problem isn't the tool, it's the configuration.

Karpenter is the configuration that works. It's faster, cheaper, and more flexible than Cluster Autoscaler. It handles spot instances like a pro. It consolidates aggressively without breaking your workloads.

The question isn't whether you should use Karpenter. The question is: how much are you losing every month by not using it?

Go check your AWS bill. Then come back.

---

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