Karpenter Spot Instance Setup: The 2026 Guide

Stop 3AM Pages

Free K8s Audit

I'll be straight with you — Kubernetes costs are out of control. I've seen it firsthand at three different companies this year alone. The Why Companies Are Leaving Kubernetes? piece hit home because I watched AcmeCorp waste $47K/month on unused EC2 capacity before they called me in.

Karpenter changed how we think about spot instances. But most people configure it wrong.

I'm Nishaant Dixit. At SIVARO, we've deployed Karpenter across 12 production clusters handling 200K events/sec. We've burned through enough spot terminations to know what works. Here's the complete guide on how to configure karpenter for spot instances — the version I'd give to my own engineers.

Why Spot Instances Are (Still) the Right Call in 2026

Most people think spot instances are too risky for production. They're wrong because the 70% cost reduction makes almost anything workable.

Kubernetes isn't dead, you just misused it. That piece nails it — Kubernetes works when you treat infrastructure as cattle, not pets. Spot instances are the ultimate cattle strategy.

We tested 100% spot for stateless workloads at Finova in March 2026. Preemption rate? 2.3% per week. Downtime? Zero. Because Karpenter handles the replacement.

What Karpenter Actually Does (No Fluff)

Karpenter is a Kubernetes node autoscaler. But it's not Cluster Autoscaler's cousin — it's a complete rewrite.

Key difference: Cluster Autoscaler adds nodes to existing node groups. Karpenter launches instances directly. No node groups. No ASGs. No launch templates. It creates EC2 instances that join your cluster as nodes.

This matters for spot because Karpenter can:

Pick any instance type across families (c5, m5, r6i, whatever)
Handle spot termination signals natively
Consolidate workloads into fewer, fuller nodes
Use instance diversity — 20+ types per provisioner

How to reduce kubernetes costs with karpenter starts with one number: spot pricing is typically 60-70% cheaper than on-demand. With Karpenter, you get that discount without the operational headache.

The Architecture You Need

Here's what we run in production:

Karpenter controller (deployment in kube-system)
     |
     v
AWSNodeTemplate (defines subnet, security groups, role)
     |
     v
Provisioner (defines instance types, taints, limits)
     |
     v
EC2 Fleet (Karpenter calls EC2 API directly)

Two CRDs. That's it.

Prerequisites (Don't Skip)

Before you configure anything:

EKS cluster running Kubernetes 1.28+ (we use 1.30 in prod)
IRSA enabled for the Karpenter controller
Subnets tagged with kubernetes.io/cluster/<cluster-name>: owned or shared
Security groups that allow node-to-node communication
IAM permissions — Karpenter needs ec2:RunInstances, ec2:TerminateInstances, ec2:DescribeInstances, and pricing:GetProducts

We forgot the pricing permission once. Cluster stayed empty for 11 minutes before we caught it.

How to Configure Karpenter for Spot Instances — Step by Step

Step 1: Install Karpenter

Don't use the Helm chart defaults. They're too permissive.

bash
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter   --version v0.37.0   --namespace karpenter   --create-namespace   --set serviceAccount.annotations."eks.amazonaws.com/role-arn"=arn:aws:iam::123456789:role/karpenter-controller   --set settings.aws.defaultInstanceProfile=KarpenterNodeInstanceProfile   --set settings.aws.interruptionQueueName=karpenter-interruption-handler   --set controller.resources.requests.cpu=1   --set controller.resources.requests.memory=1Gi   --set webhook.enabled=true

That interruptionQueueName is critical — it links Karpenter to the SQS queue that watches EC2 spot termination notices and rebalance recommendations. Without it, Karpenter can't preemptively drain nodes.

Step 2: Create the AWSNodeTemplate

This defines where nodes run:

yaml
apiVersion: karpenter.k8s.aws/v1beta1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    karpenter.sh/discovery: "my-cluster"
  securityGroupSelector:
    karpenter.sh/discovery: "my-cluster"
  instanceProfile: KarpenterNodeInstanceProfile
  tags:
    Environment: production
    ManagedBy: karpenter
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 100Gi
        volumeType: gp3
        deleteOnTermination: true

Critical detail: Use subnetSelector with tags, not hardcoded subnet IDs. Karpenter picks subnets based on availability — it distributes spot instances across AZs to reduce the blast radius of a full AZ going down.

Step 3: The Provisioner (This Is Where It Gets Real)

Here's the provisioner we use for spot-heavy workloads:

yaml
apiVersion: karpenter.sh/v1beta1
kind: Provisioner
metadata:
  name: spot-provisioner
spec:
  providerRef:
    name: default
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot"]
    - key: karpenter.k8s.aws/instance-family
      operator: In
      values: ["c5", "c5a", "c6a", "c6i", "m5", "m5a", "m6i", "r5", "r6i"]
    - key: karpenter.k8s.aws/instance-cpu
      operator: Gt
      values: ["1"]
    - key: karpenter.k8s.aws/instance-memory
      operator: Gt
      values: ["2048"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["us-east-1a", "us-east-1b", "us-east-1c"]
  limits:
    resources:
      cpu: "1000"
      memory: 4000Gi
  consolidation:
    enabled: true
    # Empty consolidation means Karpenter will move pods off underutilized nodes
  taints:
    - key: karpenter.sh/spot
      value: "true"
      effect: NoSchedule
  # Pods with toleration: karpenter.sh/spot=true will run on spot
  startupTaints:
    - key: karpenter.sh/spot-init
      value: "true"
      effect: NoSchedule

What we learned: That consolidation.enabled: true flag saved us $9,000 in February alone. Karpenter watches utilization and terminates nodes that could fit their pods elsewhere. It replaces them with smaller instances. For spot, this means constantly optimizing — the preempted node becomes two cheaper nodes.

Step 4: The Taint Strategy

Notice the karpenter.sh/spot taint. This is how you separate spot from on-demand:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateless-api
spec:
  replicas: 6
  template:
    spec:
      tolerations:
        - key: karpenter.sh/spot
          operator: Exists
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: karpenter.sh/capacity-type
                    operator: In
                    values:
                      - spot

Stateful workloads or critical databases stay on a separate on-demand provisioner. Everything else goes on spot.

Handling Spot Terminations (The Part Everyone Gets Wrong)

Karpenter handles two interruption events:

Spot termination notice — 2-minute warning from AWS
Rebalance recommendation — AWS wants to reclaim capacity

Karpenter watches an SQS queue (the interruptionQueueName you set earlier). When it sees a termination, it:

Cordon the node (no new pods)
Drain the pods (respects PDBs)
Terminate the instance
Launch a replacement

But here's the gotcha: If you use podDisruptionBudgets (PDBs) with maxUnavailable: 0, Karpenter can't drain. Your pods stay on a dying node. We saw this at a fintech client — spot termination came, PDB blocked drain, pods crashed.

Fix: Always set PDBs with maxUnavailable: 1 for spot workloads:

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

Or use maxUnavailable: 25%.

Instance Diversity — Your Best Protection

Single instance types on spot = death. AWS reclaims capacity for specific types. If you run only c5.xlarge and AWS runs out, all your nodes go at once.

We specify 8-12 instance families across 2-3 generations:

yaml
- key: karpenter.k8s.aws/instance-family
  operator: In
  values: ["c5", "c5a", "c6a", "c6i", "c7a", "m5", "m5a", "m6i", "m7a", "r5", "r5a", "r6i"]

Notice c7a and m7a — the Graviton3 instances. They're cheaper per compute unit than Intel. We benchmarked a Rust microservice on c7a.xlarge vs c5.xlarge: same throughput, 22% lower cost.

Monitoring (What to Watch)

I'll keep this short — three metrics matter:

Node count by capacity type — Are spot nodes actually launching?
Spot termination rate — Should be <5% per week in most regions
Consolidation actions — How many nodes Karpenter replaces

We use this Prometheus query:

karpenter_nodes_created_total{capacity_type="spot"}

If you see spot terminations spike above 10%, your instance family selection is too narrow. Add more families.

Common Mistakes (We Made All of Them)

Mistake 1: Not setting karpenter.sh/capacity-type as a requirement

Without this, Karpenter defaults to on-demand. You want spot? Explicitly specify it.

Mistake 2: Underestimating startup time

Spot instances can take 60-90 seconds to join the cluster. If your HPA scales up pods that need nodes, you'll get pending pods for 2+ minutes. Pre-warm with node overhead (we run 2-3 extra spot nodes always).

Mistake 3: Using only one instance family for GPU workloads

GPUs are scarce on spot. p4d.xlarge gets reclaimed constantly. We stopped using spot for GPU — the 40% savings wasn't worth the 15% termination rate.

Mistake 4: Forgetting about interrupt handling

I mentioned the SQS queue earlier. If you skip it, Karpenter doesn't get termination notices. Nodes just disappear. In 2025, a company (won't name them) lost a payment processing batch this way.

The Cost Numbers (Real Data)

Running a 50-node cluster in us-east-1:

Instance Type	On-Demand/Hour	Spot/Hour	Savings
c5.xlarge	$0.17	$0.045	73%
m5.xlarge	$0.192	$0.051	73%
r5.xlarge	$0.252	$0.072	71%

For our 12-cluster setup at SIVARO: $247K/month on-demand → $68K/month spot. That's $2.1M/year saved.

FAQ

Q: Will spot instances work for databases?

Running stateful workloads on spot is risky. We do it for read replicas only. Write-heavy databases? On-demand with spot failover nodes. We're leaving Kubernetes covers why stateful workloads drive people away — spot isn't the solution for that.

Q: How do I test spot termination handling?

AWS lets you simulate spot termination notices via the EC2 API. Run aws ec2 modify-spot-fleet-request --spot-fleet-request-id sfr-xxx --target-capacity 0 on a test node. Karpenter should drain it.

Q: What's the max spot instance diversity Karpenter supports?

I've tested 25+ instance types in one provisioner. Karpenter handles it fine. AWS pricing API returns real-time prices for all of them.

Q: Can I mix spot and on-demand in the same provisioner?

Yes. Remove the capacity-type requirement and set karpenter.sh/capacity-type: spot with a weight. Karpenter tries spot first, falls back to on-demand. We do this for critical services.

Q: Does consolidation work differently for spot?

No. But Karpenter won't terminate a spot node if the replacement would cost more. It checks spot pricing at that moment.

Q: How to reduce kubernetes costs with karpenter beyond just spot?

Node consolidation, bin packing, and using smaller instance families. We reduced node count by 40% through consolidation alone.

Q: What regions have the best spot availability?

us-east-1, us-west-2, eu-west-1. Avoid ap-southeast-1 (Singapore) — spot termination rates there are double.

Trade-Offs (Because Nothing's Free)

Spot instances aren't for everyone. Here's the honest assessment:

Trade-off 1: Cold start latency
New spot nodes take 60-90s to join. If your traffic spikes happen in 30 seconds, you'll see impact. Pre-warming helps but costs money.

Trade-off 2: Instance diversity means performance inconsistency
c5.xlarge and c7a.xlarge have different CPU architectures. We've seen 5-15% throughput variance. If your workload is CPU-bound, test across architectures.

Trade-off 3: Operator complexity
Karpenter adds another moving part. Our team spent 3 weeks getting comfortable with it. Now we can't imagine going back.

Trade-off 4: Not all workload types work
GPU spot: risky. Large memory instances on spot: frequently reclaimed. We keep databases on on-demand.

The Final Configuration (Copy-Paste Ready)

If you want one production-tested configuration, start here:

yaml
apiVersion: karpenter.sh/v1beta1
kind: Provisioner
metadata:
  name: base-spot
spec:
  providerRef:
    name: default
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot"]
    - key: karpenter.k8s.aws/instance-family
      operator: In
      values: ["c5", "c5a", "c6a", "c6i", "c7a", "m5", "m5a", "m6i", "m7g", "r5", "r5a", "r6i", "r7g"]
    - key: karpenter.k8s.aws/instance-cpu
      operator: Gt
      values: ["1"]
    - key: karpenter.k8s.aws/instance-memory
      operator: Gt
      values: ["4096"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["us-east-1a", "us-east-1b", "us-east-1c"]
  limits:
    resources:
      cpu: 500
      memory: 2000Gi
  consolidation:
    enabled: true
  taints:
    - key: karpenter.sh/spot
      value: "true"
      effect: NoSchedule
  startupTaints:
    - key: karpenter.sh/spot-init
      value: "true"
      effect: NoSchedule

And the corresponding AWSNodeTemplate:

yaml
apiVersion: karpenter.k8s.aws/v1beta1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    karpenter.sh/discovery: "my-cluster"
  securityGroupSelector:
    karpenter.sh/discovery: "my-cluster"
  instanceProfile: KarpenterNodeInstanceProfile
  tags:
    Environment: production
    ManagedBy: karpenter
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 100Gi
        volumeType: gp3
        deleteOnTermination: true

Parting Thoughts

Kubernetes isn't dead. But the way most people run it — overprovisioned on-demand instances, fat node groups, manual scaling — that's dead. Kubernetes isn't dead, you just misused it. That's the truth.

How to configure karpenter for spot instances comes down to three things: diversity, consolidation, and interrupt handling. Get those right, and you'll save 70% on compute costs. Get them wrong, and you'll have pods dropping during peak traffic.

We've been running spot-heavy clusters since 2024. The technology works. The patterns are mature. The only question is whether you'll take the time to configure it properly.

I'd bet on Karpenter. The industry is moving this way. The companies that adapt first — they're the ones that survive in 2026's cloud cost environment.

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