Skip to content
All projects
Cost & capacity engineering

Karpenter and Spot Capacity

Cutting Kubernetes compute spend by 25-35% without moving critical services off On-Demand.

Result
25-35%
Kubernetes compute saved
Where
CleverTap
2024 to 2025
Stack
4 tools
Karpenter · EKS · EC2 Spot · Kubernetes

Context

EKS clusters serving 50+ microservices across development and production, scaled by Cluster Autoscaler on On-Demand instances.

The problem

Cluster Autoscaler scales node groups, so capacity arrives in the shapes you defined in advance rather than the shapes the pending pods actually need. That mismatch shows up as paid-for headroom. The obvious saving, Spot instances, carries an obvious risk, and applying it uniformly would trade cost for reliability on services that cannot absorb an interruption.

  1. step: Pending podsreal requirements
  2. step: Karpenterprovisions to fit
  3. control: Interruption toleranceper workload
  4. result: Spoteligible non-prod
  5. result: On-Demandcritical services
Capacity type follows the workload's tolerance for interruption.

Approach

  1. 01

    Replace Cluster Autoscaler with Karpenter

    Karpenter provisions nodes against the actual requirements of pending pods rather than scaling predefined groups, which removes most of the shape mismatch.

  2. 02

    Separate workloads by interruption tolerance

    The saving comes from knowing which workloads can be interrupted. Eligible non-production workloads moved to Spot; critical services stayed on On-Demand deliberately.

  3. 03

    Assume the capacity disappears

    Spot was treated as capacity that will be taken away, not as cheaper On-Demand. The workloads moved onto it were horizontally scalable and replaceable, so Kubernetes can reschedule and Karpenter can bring up replacement capacity as availability shifts. Anything that could not absorb an interruption stayed on capacity suited to it, rather than being pushed onto Spot to make the savings number larger.

  4. 04

    Expand only after the behaviour is validated

    Rolled out incrementally, checking workload behaviour and cost impact before widening. A production Kubernetes fleet is not a single experiment, and the blast radius of getting capacity policy wrong is every service on the cluster.

  5. 05

    Keep the split explicit

    Capacity type is a property of the workload, not a global cluster setting, so the reliability trade is made per service and stays visible.