Karpenter Cost Optimization: Consolidation Benchmark Results (7-Day Run)

$703.08 vs $400.83. Same workload. Same region. Same 7 days. That gap – $302.25, or 43.0% – is what Karpenter’s built-in consolidation leaves on the table when your cluster isn’t trivially packable.

Karpenter is a solid provisioner. It picks instances from EC2 Fleet, respects NodePool constraints, and handles scale-out well.

But consolidation is a different problem. Karpenter’s WhenEmptyOrUnderutilized policy works best when nodes drain cleanly and replacement capacity is predictable. Production clusters often don’t cooperate.

Topology spread constraints, tight PDBs, heterogeneous pod footprints, and fragmentation pods all fight the consolidator simultaneously.

This benchmark tested exactly that.

The Benchmark: Karpenter Native vs Three Consolidation Overlays

We ran four variants across identical workloads on EKS in eu-central-1, May 18–24, 2026. The 7-day run used the same pod mix, the same scale schedule, and the same instance family constraints (c/m/r, gen5+, 2–32 vCPUs, Spot-first).

Workload Autoscaling – – Workload optimization on Pods, Cast AI’s continuous resource request adjustment feature – was disabled across all four variants to isolate consolidation behavior from request rightsizing.

VPA was simulated via 30-minute cron patches – every 30 minutes, a cron job applied resource request patches simulating VPA scaling behavior, increasing requests at ramp-up and decreasing at ramp-down. This kept pod requests near-ideal throughout the test without actual VPA interference.

The benchmark cluster ran approximately 15–20 nodes at peak, scaling down to ~8–10 nodes at off-peak. Total infrastructure cost for the 7-day window reflects this scale; extrapolate proportionally for your fleet size.

• Variant A: Karpenter with consolidationPolicy: WhenEmptyOrUnderutilized. Baseline. No external tooling.
• Variant B: Karpenter with WhenEmpty only, plus Cast AI’s Evictor. Evictor is a continuous bin-packing daemon: it finds underutilized nodes, evicts their pods so Karpenter can delete the now-empty node, and repeats. Karpenter handles provisioning; Evictor handles the consolidation work Karpenter’s built-in policy leaves undone.
• Variant C: Karpenter with WhenEmptyOrUnderutilized, plus the Continuous Rebalancer (CRB) from the Karpenter Enterprise Suite by Cast AI. The Kentroller takes over consolidation from Karpenter. It runs recurring rebalance cycles: provisions replacement nodes first, then drains the old ones. Karpenter stays as the provisioner.
• Variant D: Full Cast AI’s Autoscaler. This replaces the Karpenter provisioner entirely. The Autoscaler handles both provisioning and consolidation, pairing Evictor with a Scheduled Rebalancer. Because it provisions for workload fit from the start, there is less corrective consolidation work to do.

Workloads at peak (~150 pods) and off-peak (~90 pods), with 30-minute cron scale events throughout:

• web-frontend: 30 replicas, 500m/256Mi, topologySpreadConstraints maxSkew=1 by hostname
• web-backend: 20 replicas, 1000m/512Mi, topologySpreadConstraints maxSkew=1 by hostname
• cpu-batch: 12 replicas, 500m/64Mi, high CPU requests relative to memory
• java-heap: 10 replicas, 500m/2Gi, PDB minAvailable=8
• padding-small: 40 replicas, 100m/64Mi
• padding-large: 10 replicas, 2000m/1Gi

Adversarial Workloads: How We Stress-Tested Each Consolidation Approach

Each of the following patterns is individually common in production. Combining all four in a cluster that was never static is what made this benchmark adversarial.

Topology Spread Constraints

web-frontend (30 replicas) and web-backend (20 replicas) both had maxSkew=1 spread across hostnames. This forces at least one pod per node per deployment for each node in scope.

A consolidator cannot drain a node if doing so would push any spread group over the skew limit. To drain a node, the consolidator has to find replacement capacity and coordinate evictions across multiple nodes simultaneously so the spread constraint stays satisfied throughout the transition.

Karpenter’s built-in policy doesn’t do coordinated multi-node reshuffling. Evictor and CRB have different strategies for handling this, with measurable consequences.

Tight PDB

java-heap ran 10 pods at 500m/2Gi each, with minAvailable=8. At any moment, only 2 pods were evictable.

Every eviction had to complete and the pod had to reschedule and pass readiness before another eviction could proceed. Nodes hosting java-heap pods took a long time to drain.

In practice, a consolidator that triggered a drain on such a node would find it nearly non-disruptable under normal operating conditions. This rate-limiting effect was constant throughout the 7-day window.

Heterogeneous Footprints

java-heap pods were memory-heavy at 2Gi/500m. cpu-batch pods requested 500m CPU with only 64Mi memory – a very different shape.

The bin-packing challenge is purely about the request profile mismatch: CPU-dominant and memory-dominant pods compete for different resource dimensions, making it hard to find node sizes that efficiently pack both without leaving significant headroom on one axis.

Consolidators work from requests alone – actual runtime utilization is not part of the equation. Every reshuffling decision must find a placement that fits both shapes without wasting capacity in whichever resource dimension the node type over-provides.

Padding Pods

The 40 padding-small pods (100m/64Mi each) and 10 padding-large pods (2000m/1Gi each) are scattered throughout the cluster, ensuring deployments span as many nodes as possible.

This multiplies the number of consolidation variants the optimizer has to consider: more pods distributed across more nodes means more possible reshufflings to evaluate and more constraints to satisfy simultaneously.

The effect isn’t to block consolidation – it’s to increase the combinatorial complexity of finding an optimal packing arrangement, which is exactly where simpler consolidators leave the most money on the table.

A Note on Benchmark Conditions

This was a deliberately adversarial benchmark. No single production cluster combines topology spread constraints at this density, a PDB this tight, this degree of footprint heterogeneity, and fragmentation pods simultaneously. Real production clusters are less erratic.

If your cluster is mostly stateless, evenly sized workloads with no spread constraints, Karpenter’s built-in consolidation will perform much closer to the best-case numbers here. Results will vary.

The point of combining all four patterns was to stress-test each consolidation strategy under conditions where the easy wins were already taken. Treat the absolute figures as benchmark artifacts; focus on the relative differences between variants.

Karpenter Cost Optimization Results: A-to-D Comparison

Variant A: Karpenter Baseline

Karpenter’s EC2 Fleet API picks instance types for capacity availability and NodePool fit, not for workload packing efficiency. Once a node is provisioned, Karpenter’s consolidation policy can remove nodes one at a time – but it cannot replace multiple nodes with multiple nodes simultaneously.

When the easy single-node wins are taken, real consolidation gains require coordinated multi-node reshuffling, and Karpenter’s architecture doesn’t support that.

Topology spread constraints and the java-heap PDB compound the problem, but the root limitation is architectural: consolidation stalls wherever progress requires coordinating across multiple nodes at once. This is the floor most teams are running on today.

Variant B: Karpenter + Cast AI’s Evictor

Total cost: $639.45. 9.1% savings over the baseline ($63.63 saved).

Evictor runs as a continuous daemon rather than as a policy on the provisioner. It continuously evaluates which nodes are underutilized, evicts their pods, and relies on Karpenter to delete the now-empty node.

The gap between Variant A and Variant B comes from this decoupling: Karpenter provisioned for capacity; Evictor continuously corrected the packing after the fact.

In a 7-day run against these adversarial constraints, the savings are real but modest – topology spread and the PDB limit how aggressively Evictor can evict. Evictor can drain multiple nodes in parallel, but it doesn’t provision replacement infrastructure; that decision stays with Karpenter. The gains are bounded by what continuous eviction alone can achieve without the ability to re-provision for better fit.

Variant C: Karpenter + Continuous Rebalancer

Total cost: $591.98. 15.8% savings ($111.10 saved).

The Karpenter Enterprise Suite’s CRB runs recurring rebalance cycles in which Kentroller provisions replacement nodes first and then drains the originals. This approach enables more targeted instance selection on the replacement side and can coordinate drains across multiple nodes within a single rebalance cycle – which is why it consistently outperforms Evictor in clusters where the hard consolidation gains require moving multiple nodes at once.

The 15.8% figure reflects CRB’s current behavior. There is meaningful headroom here, and efficiency is expected to improve in upcoming releases. These numbers are a floor, not a ceiling.

Variant D: Full Cast AI Autoscaler

Total cost: $400.83. 43.0% savings ($302.25 saved).

Unlike the overlay approach in Variants B and C, the Cast AI Autoscaler evaluates workload fit constraints (topology spread, PDB, heterogeneous footprints) as part of its provisioning decision – not as a post-hoc correction step. The Scheduled Rebalancer then handles periodic defragmentation on top of near-optimal initial placement.

Because the initial packing is closer to optimal, Evictor and the Scheduled Rebalancer have less corrective work to do throughout the run. At $302.25 saved versus Karpenter over 7 days on this benchmark cluster, the compounding effect of provisioning-time fit decisions is the largest single driver of cost reduction in this test.

Choosing Your Consolidation Strategy: A Decision Guide

The data points toward a clear decision tree depending on where you are and what you’re willing to change:

• Still on Karpenter and want a first step up? Add Evictor. Install via Helm (helm install castai-evictor castai-helm/castai-evictor); requires switching NodePool from WhenEmptyOrUnderutilized to WhenEmpty. 9.1% savings in this benchmark. Real improvement, minimal operational change.
• Want meaningfully more while keeping Karpenter as the provisioner? Add the Karpenter Enterprise Suite. Continuous Rebalancing reached 15.8% savings ($111.10) in the 7-day run by coordinating multi-node drains that Evictor can’t do. These numbers are a floor – further improvements in progress will push the ceiling higher.
• Willing to replace the provisioner for the biggest gains? The full Cast AI Autoscaler reached 43.0% savings ($302.25) over 7 days – more than double of the CRB. The delta comes from provisioning-time fit decisions, not post-hoc correction. Requires connecting your EKS cluster to Cast AI; here’s how to get started.

Start Your Kubernetes Cost Analysis

These numbers came from a controlled benchmark cluster. Your production cluster has different workload shapes, different spread constraints, and different scale patterns. The only way to know your actual consolidation gap is to measure it.

Connect your EKS cluster to Cast AI and see your cluster’s actual consolidation gap – the difference between what you’re running and what the Karpenter Enterprise Suite or Cast AI’s Autoscaler could deliver.