Your Kubernetes Cluster Runs at 10% CPU. You're Still Paying for the Other 90%.

Somewhere in your cloud bill right now, nine CPUs are sitting idle for every one doing work. That's not a guess or a worst-case anecdote — it's the average, measured across more than two thousand organizations, and it got worse last year, not better. Kubernetes was adopted, almost universally, as the tool that would make infrastructure efficient at scale. The data says the opposite happened for most of the teams running it.

CAST AI's 2025 Kubernetes cost benchmark, drawn from over 2,100 organizations' real production clusters, found average CPU utilization sitting at 10% — down from 13% the year before. Memory utilization came in at 23%, up slightly, but still meaning more than three-quarters of provisioned memory sits unused at any given moment. The CNCF's own FinOps survey found a nearly identical picture — roughly 10% CPU, 20% memory — and attributed 70% of Kubernetes overspending directly to overprovisioning. Datadog's cloud cost research puts a number on where that waste concentrates: 83% of container costs fund idle resources, split between cluster-level overhead and requests sized far larger than what workloads actually use. Three independent measurement efforts, landing in the same range, is not noise. It's a pattern.

The Efficiency Layer Became the Overhead Layer

Kubernetes exists to schedule workloads efficiently across a pool of machines — bin-packing containers so hardware gets used instead of sitting idle. That's the pitch, and at genuine hyperscale, with dedicated platform teams tuning it constantly, it can deliver on that pitch. But most organizations running Kubernetes aren't operating at that scale, and the orchestration layer itself imposes a tax that the pitch conveniently leaves out.

Every pod needs CPU and memory requests — the numbers Kubernetes uses to decide where it can schedule work and how much headroom to reserve. Setting those requests accurately requires ongoing measurement most teams don't have the staffing to do, so the default behavior under uncertainty is to over-request: pad the numbers so nothing gets evicted under load, and move on to the next feature. That single, individually rational decision, repeated across every service in a growing microservices architecture, is what produces a cluster running at 10% utilization while showing green on every dashboard. Nothing is on fire. Nothing looks broken. The waste is invisible precisely because it doesn't fail — it just quietly bills you for capacity nobody is using.

Compute Was Never the Real Cost

Here's the part that gets lost in every "cut your Kubernetes bill" listicle: compute isn't even the majority of what Kubernetes actually costs an organization. A cost-structure analysis from infrastructure firm SpendArk breaks a typical Kubernetes budget down to roughly 45% compute, 25% people and operations, 12% observability, 10% networking, and 8% storage — meaning for every dollar spent on the servers themselves, organizations spend another $1.22 keeping the orchestration layer fed, monitored, and staffed. Separately, platform engineering firm Encore found compute accounting for as little as 14-18% of total Kubernetes cost of ownership when engineer time is priced in fully — with people costs alone running 70%+ of the real bill. A platform engineer commands roughly $199,000 a year on average; a typical three-person platform team, whose primary job is keeping Kubernetes itself running smoothly, costs an organization $400,000 to $600,000 annually before a single customer-facing feature ships.

That's the inversion worth sitting with. Kubernetes was adopted to reduce the cost of running infrastructure. For a large share of the organizations running it, the orchestration layer has become a cost center in its own right — one that requires a standing team to manage, largely so that team can keep tuning a system that, left unmanaged, drifts toward 10% utilization on autopilot. The same pattern shows up one layer up the stack, where the tools bought to make delivery legible end up fragmenting it instead — more infrastructure doesn't default to more efficiency. It defaults to more infrastructure.

The Company That Did the Math and Left

37signals — the company behind Basecamp and HEY, run by David Heinemeier Hansson — is the clearest public case study of an organization that ran this calculation and acted on it. In 2022, they began pulling their infrastructure off the cloud entirely, buying their own Dell hardware and deploying it in owned data centers. They deliberately skipped Kubernetes for the deployment layer, building an open-source tool called Kamal — Docker containers over plain SSH — specifically to avoid the orchestration complexity and the standing operational tax that comes with it. Hansson reported publicly that the move would save the company $7 million over five years, cutting their annual cloud bill from $3.2 million to $1.3 million. The point isn't that every company should buy servers and quit the cloud — very few are positioned to make that trade the way 37signals was. The point is that when a technically sophisticated team actually priced out what Kubernetes-style orchestration was costing them against what they needed, the complexity didn't pay for itself, and they had the conviction to say so publicly.

The Question Nobody Asks Before Adopting It

Kubernetes adoption decisions get made on future-scale reasoning: we might need this kind of elasticity eventually, better to build on it now. That reasoning skips the actual question, which is a utilization question, not a scale question — what is your baseline load, how much genuine variability does it have, and does the orchestration overhead you're about to take on actually pay for itself at the workload you have today, not the one you're forecasting for three years out. Most teams never run that math. They adopt the industry-standard tool because it's the industry-standard tool, and by the time the utilization numbers would tell them something's wrong, there's a platform team, a body of YAML, and an organizational identity built around the choice.

So Actually — Kubernetes Isn't the Problem. Unexamined Adoption Is.

None of this is an argument that Kubernetes is bad technology. At genuine scale, with the staffing to tune it continuously, it does exactly what it was built to do. The argument is narrower and less comfortable: for a large share of the organizations currently running it, Kubernetes was adopted as a scaling decision when it should have been evaluated as a utilization decision, and the CAST AI, CNCF, and Datadog numbers all converge on the same conclusion — that evaluation mostly never happened.

If your cluster's dashboard is green and your bill keeps climbing anyway, the question worth asking isn't which autoscaler to tune next. It's whether the orchestration layer you adopted for a scale you don't have yet is the thing quietly consuming the budget you needed for the scale you're actually trying to reach.