Why does Kubernetes hide cost?

Kubernetes hides cost because a shared cluster bills as a handful of large compute, storage, and networking line items while dozens of teams and services run inside it. The provider invoice tells you the cluster cost it does not tell you which namespace, team, or workload drove it. Allocation has to be reconstructed from resource requests, actual usage, and labels.

This matters because you cannot optimise what you cannot attribute. Until each team can see the cost of the capacity it reserves, there is no incentive to give any of it back. The first move on any container estate is building a cost model that maps cluster spend down to namespaces and workloads.

Why are overprovisioned requests the biggest leak?

In Kubernetes, the scheduler places pods based on their CPU and memory requests, not their actual usage. When teams set requests far above what a workload really consumes, the scheduler reserves that capacity, nodes fill up on paper, and the autoscaler adds more nodes, all while real utilization sits low. You pay for reserved capacity that is never used.

The fix is to align requests with observed usage from real traffic, set sensible limits, and let the cluster bin pack more tightly onto fewer nodes. This is rightsizing applied to containers, and it is a continuous discipline, not a one time pass, because new services drift back toward generous defaults.

Worked example

A scaling fintech ran a multi tenant cluster where average CPU requests were set at roughly three times observed usage. Bringing requests in line with real usage and tightening bin packing let the cluster run the same workloads on materially fewer nodes, with no change to latency. The freed node capacity then made a commitment worth buying. Figures are verified against billing data and anonymised.

How do you allocate cluster cost to teams?

Allocation turns a shared cluster into a set of accountable budgets. The mechanics are consistent across the managed services:

  • Label and namespace discipline. Every workload carries team, product, and environment labels so cost can be grouped the way the business thinks.
  • Cost from requests and usage. Split node cost across pods by the greater of request and usage, so reserved but idle capacity is attributed to whoever reserved it.
  • Shared cost rules. Decide up front how control plane, system, and idle headroom costs are spread, so the numbers hold up when a team questions them.
  • Showback before chargeback. Show teams their cost first; accountability follows visibility.

The native advisors (AWS Compute Optimizer, Azure Advisor, GCP Recommender, and the OCI Cost Analysis console) help spot oversized nodes, but they recommend, they do not decide. The allocation model is what makes their recommendations actionable.

What should you commit, and what should run on spot?

Once requests are right and the cluster bin packs tightly, a clear baseline of node capacity emerges. That baseline is steady enough to commit.

Matching Kubernetes node capacity to the right purchase model (indicative)
Capacity typeBest purchase modelWhy
Steady baseline nodesSavings Plans, Reservations, or Committed Use DiscountsPredictable demand earns the commitment discount safely
Stateless, fault tolerant workloadsSpot or preemptible capacityLarge discount in exchange for interruptions the workload can absorb
Spiky, short lived burstsOn demandFlexibility is worth more than the discount at this layer

The pattern is the same baseline, burst, and interruptible split we use estate wide, applied to node pools. Commit the baseline, run interruptible work on spot, and keep the spiky remainder on demand. For how this fits commitments across the whole estate, see our cloud commitment negotiation service.

How do GPU and AI workloads change the picture?

AI workloads are the fastest growing line on most estates, and inside Kubernetes they concentrate cost in expensive GPU nodes that are easy to leave idle. A GPU reserved for a training job that runs intermittently can cost more idle than a whole namespace of CPU workloads. The governance is specific: meter GPU utilization per team, bin pack GPU jobs onto fewer nodes, scale GPU node pools to zero when idle where the platform allows, and reserve GPU capacity only against steady, scheduled demand.

Token costs, provisioned throughput, and capacity reservations for managed AI services need the same discipline as compute commitments: reserve only what steady demand supports, and keep the spend visible per team.

Frequently asked questions

Why is Kubernetes cost so hard to see?

A shared cluster bills as a few large line items while many teams run inside it, so the invoice never shows which workload drove the spend. You have to reconstruct allocation from requests, usage, and labels.

What is the biggest source of Kubernetes waste?

Overprovisioned requests. The scheduler reserves capacity based on requests, so requests set well above real usage fill nodes on paper and trigger needless scale up while utilization stays low.

Can you commit capacity for Kubernetes?

Yes. The steady baseline of node capacity suits Savings Plans, Reservations, or Committed Use Discounts, while stateless fault tolerant work fits spot or preemptible capacity at a large discount.

Do the native cost tools fix this automatically?

No. AWS Compute Optimizer, Azure Advisor, GCP Recommender, and the OCI Cost Analysis console recommend, they do not decide. You still need an allocation model and an owner to act on the recommendations.

Get the full guide and the next move

Download the complete Kubernetes cost guide, or have us model your cluster directly. Our guarantee stands behind every engagement: we reduce your cloud spend or we reimburse our service fee.

Download the Kubernetes cost guide

Get the full buyer side guide and join The Cloud Spend Navigator for monthly, numerate analysis. No provider in the room, no public email required.

Independent · buyer-side

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.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.