Karpenter is open source and free to use. At small scale that is the whole story. Past a handful of clusters three costs appear that no licence fee captures: the engineering time to configure, upgrade and keep NodePools consistent across clusters; the savings that stay on the table because Karpenter provisions against requests that run about 69% above actual usage; and the work of filling the gaps around it – cost allocation, commitment coordination, fleet policy. None of this makes Karpenter the wrong choice. It makes “free” the wrong frame for the decision.
Key Takeaways
- Karpenter carries no license fee. Engineering overhead is real: 0.5–1.0 FTE ($80,000–$165,000 per year) for multi-cluster fleets.
- Karpenter provisions to pod resource requests. Pods request 69% more CPU than they actually use at runtime. Karpenter cannot close that gap.
- Three gaps surround Karpenter: cost allocation, commitment coordination, and fleet governance. Each requires separate tooling or headcount to fill.
- At 1–3 clusters, open-source is the correct choice. Past 10 clusters, the commercial overlay math typically tips the other way.
- A commercial layer runs on top of Karpenter, not instead of it. Existing NodePool configurations stay in place.
This post puts numbers on each cost and builds a total cost of ownership model you can run against your own estate. It also covers when open-source Karpenter is genuinely the right call, because sometimes it is. If you are new to the tool, start with what Karpenter is and how it works first.
This post focuses on AWS/EKS. The engineering overhead and TCO framework apply broadly; commitment and Spot coordination tooling availability varies by cloud provider.
What Free Actually Covers
Karpenter handles node provisioning. It watches for unschedulable pods, calls the AWS EC2 API directly, and selects the optimal instance type from a broad candidate pool. Provisioning completes in 45–90 seconds, compared to 3–5 minutes for Cluster Autoscaler. For teams coming from the older autoscaler, this is a genuine step forward.
Karpenter also runs continuous disruption. The WhenEmptyOrUnderutilized policy identifies underutilized nodes, reschedules workloads, and terminates them. No node groups, no Auto Scaling Group intermediary. That is the full scope of what the zero-dollar license covers.
What it does not cover: pod-level resource management, cost allocation by namespace or team, Reserved Instance coordination, and fleet governance across clusters. These are not design flaws in Karpenter. They are simply outside its scope.
Cost 1: Engineering Time
Getting a single cluster right takes 5–15 hours upfront. That work covers NodePool design, taint configuration for workload isolation, resource limits to prevent runaway provisioning, and consolidateAfter tuning. Spot interruption handling adds another 4–8 hours per cluster: one SQS queue, five EventBridge rules, and the queue name wired into the EC2NodeClass interruptionQueue field (Karpenter v1.x) or the --interruption-queue controller flag (v0.x). Without that wiring, Karpenter cannot proactively drain nodes within the two-minute EC2 Spot interruption window. None of this is automatic.
The ongoing cost is where multi-cluster fleets feel the pressure. Version upgrades land on a roughly quarterly cadence and cost 4–8 hours per cluster. At 10 clusters, that is 40–80 engineering hours per upgrade cycle. Some versions mark existing nodes as drifted due to hashing logic changes, which means reconciliation work piles on top of the upgrade itself rather than running in parallel.
Add it up across a multi-cluster fleet and you are looking at 0.5–1.0 FTE per year for a senior DevOps engineer, equivalent to $80,000–$165,000 at a US median loaded salary of $165,000. An external benchmark from Qovery puts the self-managed overhead at $24,000–$48,000 per year for teams running Karpenter without a managed service (source: Qovery blog, 2025). That cost scales linearly with cluster count, not with workload complexity.
Cost 2: Savings Not Captured
Karpenter provisions to pod resource requests. The problem is what those requests actually contain. Across more than 23,000 production clusters, the Cast AI 2026 State of Kubernetes Optimization Report found that pods request 69% more CPU than they actually consume at runtime. One documented production cluster showed 44.87 CPU provisioned, 24.9 CPU requested, and 3.94 CPU actually used. Karpenter’s bin-packing was working exactly as designed. The compute bill still reflected what the requests specified, because that is the only signal Karpenter has.
To find out where you stand on your own fleet, run this PromQL query against Prometheus. It uses three-label vector matching to avoid silent aggregation on multi-container pods:
max by(namespace, pod, container)(
rate(container_cpu_usage_seconds_total[5m])
/
on(namespace, pod, container)
(kube_pod_container_resource_requests{resource="cpu"} > 0)
)The > 0 filter on the denominator excludes BestEffort pods, which carry zero requests and produce a division-by-zero result without it. A ratio below 1.0 indicates overprovisioning. Fleet averages around 0.08 are not unusual. Values below 0.2 are high-confidence rightsizing candidates. Automated rightsizing that adjusts requests continuously to p95 actual usage reduces wasted compute by approximately 50%.
Native consolidation has limits that compound this savings gap. Topology spread constraints configured with maxSkew: 1 force one pod per node, which blocks multi-node coordinated drains; reduce to maxSkew: 2 or switch topologyKey from hostname to zone to give Karpenter room to consolidate. Tight PDBs—say, minAvailable: 8 of 10 pods—allow only two simultaneous evictions; set minAvailable to replicaCount - 1 rather than replicaCount - 2 to give Karpenter more eviction headroom without risking availability. DaemonSet overhead sets a CPU floor that prevents bin-packing on small nodes; use Node Feature Discovery to scope DaemonSets to specific node pools rather than running them cluster-wide. Finally, drift compounds the cost: 10% of 200 nodes means 20 nodes cycling per period; at roughly $0.20 per hour per c5.large amortized across 200 hours, that adds approximately $800 per month in unnecessary re-provisioning overhead.
Cost 3: Surrounding Gaps
Karpenter has no native cost allocation. If you want to know what a namespace or a team is actually spending, you need OpenCost or Kubecost deployed alongside it. Both are useful visibility tools, but neither resizes pods, shifts workloads to Spot, nor coordinates Reserved Instance commitments automatically. Maintaining OpenCost with custom alerting and billing pipelines adds 0.1–0.25 FTE per year to the operational load, which at a $180,000 loaded rate translates to $18,000–$45,000 per year before you have written a single line of rightsizing logic.
The commitment coordination gap is the one that surprises most teams. Karpenter has no awareness of Reserved Instances or Savings Plans. If you run heavy Spot adoption to reduce per-hour costs, those Spot hours do not consume your Savings Plan commitments, and the commitment sits partially idle. Without automated coordination, typical commitment utilization sits at 50–70%. Automated management can push that to 98%, which for an $800K annual cloud spend is a meaningful recovery.
Fleet governance is the third gap. Karpenter provides no centralized policy management across clusters. At 10 or more clusters, propagating a NodePool policy change across the fleet is a fully manual operation, and the risk of configuration drift between clusters grows with every change. Before enabling consolidation on any cluster, verify that stateful and latency-sensitive workloads have minAvailable PDBs set. Karpenter can drain all replicas of a deployment simultaneously without them.
TCO Model: 5-Cluster Fleet
Rows 1–9 in the inputs table below are substitutable. Replace them with your actual numbers before drawing conclusions. The cost breakdown rows are calculated from those inputs, not from your reality – do not mistake the model assumptions for your own situation.
| Input | Model value |
|---|---|
| Clusters | 5 |
| Nodes per cluster | 40 |
| Total managed nodes | 200 |
| Average vCPU per node | 4 |
| Total managed CPUs | 800 |
| Loaded DevOps salary | $165,000 |
| FTE allocation (OSS operations) | 0.6 |
| Annual cloud spend | $800,000 |
| Current CPU overprovisioning rate | 69% |
| Current commitment utilization | 60% |
| Target commitment utilization | 98% |
Real-world validation: a 7-day benchmark on EKS eu-central-1 (July 2026), run under adversarial conditions, topology spread constraints, tight PDBs, heterogeneous pod footprints, showed native Karpenter at $703.08 versus full Cast AI at $400.83, a 43% cost reduction.
| Cost category | OSS Karpenter | Commercial overlay |
|---|---|---|
| Engineering (FTE) | $99K (0.6 FTE) | $33K (0.2 FTE) |
| Cost allocation tooling | $27K (0.15 FTE OpenCost) | $0 (built-in) |
| Savings gap (overprovisioning) | ~$160K (20% of $800K) | ~$0 |
| Commitment underutilization | ~$32K | ~$0 |
| License | $0 | ~$48K (800 CPUs × $5/CPU/mo) |
| Total | ~$318K/year | ~$81K/year |
Scale Thresholds
At 1–3 clusters, open-source is the clear choice. Drift has not accumulated, upgrade overhead is manageable, and a single engineer can hold the configuration in their head. Between 3 and 10 clusters, drift accumulates faster than most teams expect, and the gap between what Karpenter provisions and what workloads actually consume starts showing up in the cloud bill in a way that is harder to ignore. Past 10 clusters, the commercial overlay math typically tips clearly in favor of a managed solution, not because Karpenter degrades, but because the surrounding operational work scales with cluster count and the savings opportunity scales with CPU under management.
When Free Is Genuinely the Right Answer
If you have one to three clusters and a dedicated engineer who owns Karpenter configuration full-time, the open-source path is correct. The engineering overhead is proportionate to the fleet size, the upgrade cadence is manageable, and the savings available from a commercial overlay will not reliably exceed the license cost at that scale. There is no TCO case to make, and you should not try to make one.
Cloud spend matters too. If your annual cloud spend is under $200,000, the arithmetic rarely works in favor of a commercial layer. The overprovisioning savings and commitment coordination gains are percentage-based. At $200K total spend, a 20% overprovisioning gap is $40,000 and a commercial license may consume most of that margin before you see net benefit. Run your own numbers against the model above before assuming otherwise.
Workload profile matters as well. If your pods are stateless, your resource requests are reasonably accurate, and your engineers actively manage PDBs and topology constraints, Karpenter’s native consolidation handles most of the efficiency work without additional tooling. The 69% average overprovisioning figure comes from a fleet of 23,000 clusters. Your cluster may not reflect that average, measure it with the PromQL query above before assuming you do.
If you are migrating from Cluster Autoscaler, run native Karpenter for 60–90 days before adding anything on top. That window gives you real data on where drift accumulates, which workloads have problematic PDBs, and what your actual CPU request-to-usage ratio is. Without that baseline, any commercial decision is guesswork.
The honest conclusion: open-source Karpenter is the right call when its total cost of ownership — engineering overhead, tooling costs, and savings not captured — stays lower than the commercial alternative. For small fleets with a dedicated operator and accurate resource requests, that condition often holds. Know your numbers before you decide.
The Commercial Layer: On Top of Karpenter, Not Instead of It
Cast AI runs as a set of Kubernetes controllers in a dedicated namespace, alongside Karpenter — not as Karpenter plugins or node overrides. Karpenter continues to handle all node provisioning. Cast AI extends the control plane around it.
Workload rightsizing (PrecisionPack) measures actual CPU usage and sets pod requests at the p95 percentile, continuously. It applies changes via Container Live Migration — no restart required for stateless workloads. EBS RWO StatefulSets use a standard restart because volume reattach adds 30–90 seconds of delay. Memory requests are rightsized against working-set peaks (max_over_time of container_memory_working_set_bytes) rather than averages, to avoid OOMKills during GC spikes. Across the fleet, this closes approximately 50% of wasted compute.
The Continuous Rebalancer finds additional efficiency that static rightsizing cannot. In the 7-day EKS benchmark referenced above, it added a further 15.8% in savings on top of rightsizing alone. Commitment management brings RI/SP utilization to 98%, regardless of how Spot mix shifts day to day. Customers report compute savings of 30–50% in the first 90 days after onboarding, depending on starting overprovisioning rate (Cast AI internal data). Yotpo reduced cloud spend by 40% after onboarding. Real-time cost visibility is built in — no OpenCost deployment to maintain.
Predictive Spot reduces Spot interruptions by up to 94% for stateless, multi-AZ workloads (Cast AI internal data, multi-cloud fleet cohort, 2026; results vary by workload type and interruption rate).
Frequently Asked Questions
The license is free. Engineering overhead, surrounding tooling, and savings not captured are not. For a 10-cluster fleet, the real cost runs $80,000–$165,000 per year in engineering time alone.
0.5–1.0 FTE per year for a multi-cluster fleet, plus 0.1–0.25 FTE for cost allocation tooling if you add OpenCost or Kubecost. Initial setup runs 9–23 hours per cluster.
Not necessarily. The question is whether the savings and automation from a commercial overlay justify its cost given your fleet size and cloud spend. Under $200K annual cloud spend and three or fewer clusters, the math usually does not support it.
When the three cost gaps — engineering overhead, savings not captured, and surrounding tooling costs — exceed what a commercial license costs. Use the TCO model above with your actual inputs.
No. Cast AI runs as Kubernetes controllers alongside Karpenter. NodePool configurations stay in place. Karpenter continues provisioning nodes.
Initial setup is 9–23 hours per cluster. Ongoing operations, including quarterly upgrades and drift reconciliation, run 0.5–1.0 FTE per year for a 10-cluster fleet. That number scales linearly with cluster count.
