A Kubernetes cluster costs what its nodes cost, and node count is driven by the sum of pod resource requests, not actual usage. When a pod requests two CPUs, the scheduler reserves two CPUs of node capacity for it even if it averages a fraction of that, so overstated requests force you to run and pay for nodes you do not need. Limits, by contrast, only cap what a pod may burst to and do not reserve capacity, so they are a stability control, not a cost lever. The biggest container saving is closing the gap between what pods request and what they actually use.
Here is how requests, limits, and usage actually translate into the bill.
Why do requests drive cost and limits do not?
The scheduler packs pods onto nodes by their requests. The total requested CPU and memory across all pods, divided by node capacity, sets how many nodes must exist. That reserved capacity is billed whether the pod uses it or sits idle, so requests are a direct claim on spend. Limits set the ceiling a pod may consume before it is throttled on CPU or killed on memory, which protects neighbours from a noisy pod but reserves nothing and so costs nothing on its own. A buyer who tunes limits to save money is pulling the wrong lever; the money is in the requests.
What is the request to usage gap, the cluster tax?
Most clusters carry a large gap between requested and used resources, often two to four times, because engineers set requests defensively from a guess and rarely revisit them. That gap is the cluster tax: reserved, billed capacity doing nothing. Measure it as the ratio of total requests to actual p95 usage across the cluster. A ratio near 1.3 is healthy headroom; a ratio of 3 means roughly two thirds of your reserved capacity, and the nodes under it, are waste. This single ratio is the fastest read on whether a cluster is overprovisioned.
| State | Total CPU requested | p95 CPU used | Nodes required |
|---|---|---|---|
| Before, defensive requests | 1200 cores | 380 cores | Sized to 1200, heavily idle |
| After, rightsized to p95 plus headroom | 500 cores | 380 cores | Sized to 500, about 35 percent fewer nodes |
How do you rightsize requests without throttling workloads?
Rightsize from measured load, not intuition. Read each workload’s p95 CPU and memory over a representative window, set the request to that plus a deliberate headroom margin, and leave a CPU limit generous or unset so the pod can burst, while setting a memory limit close to the request because memory is not compressible and overshoot gets the pod killed. Treat CPU and memory differently: CPU throttling slows a pod, memory overshoot kills it, so the headroom math is not symmetric. Roll changes per workload behind monitoring, watch p95 latency and throttling metrics, and never set requests equal to limits blindly, which removes all burst room. The Vertical Pod Autoscaler can recommend requests from history, which is a good input as long as a human approves the move.
A European SaaS company ran a 1200 core production cluster whose pods requested roughly three times their measured p95 usage. We rightsized requests workload by workload to p95 plus a 25 percent headroom margin, kept CPU limits generous to preserve burst, and tightened memory limits to avoid kills. Reserved CPU fell to about 500 cores, the autoscaler removed roughly 35 percent of nodes, and p95 request latency was unchanged. The saving came entirely from reclaimed reservation, not from running workloads hotter. Figures are verified against billing data and anonymised.
What should a buyer ask the platform team?
Three questions surface the cluster tax fast. What is the cluster wide ratio of requested to p95 used CPU and memory. Which workloads have the largest absolute gap between request and usage. And are requests reviewed on a cadence or set once and forgotten. The answers point straight at the nodes you can remove. This sits alongside overprovisioning, the default Kubernetes tax and vertical pod autoscaling in practice, inside the Kubernetes cost guide. For why the bill is hard to read in the first place, see why Kubernetes bills are so hard to read.
Frequently asked questions
Find the cluster tax in your Kubernetes bill
We measure your request to usage gap, rightsize requests to real load without throttling, and remove the nodes you are paying for and not using. It is the same discipline behind the 31 percent median reduction we see in the first 90 days, with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.