Kubernetes cost blind spots: what namespace-level allocation actually fixes

A cluster-level cost dashboard telling you "the cluster costs £40,000 a month" is true and almost useless. It doesn't tell you which team, namespace, or workload is driving that number, which means nobody has a reason to change their behaviour — the bill is everyone's problem, which in practice means it's nobody's.

Namespace-level cost allocation changes that. Once a specific namespace is shown to be responsible for £8,000 of the monthly bill — and once that's attributed to the team that owns it — the conversation shifts from "the cluster is expensive" to "your service's memory requests are three times its actual usage," which is a conversation an engineering team can actually act on.

The two blind spots we see most often once allocation is switched on:

Over-requested resources. A pod requesting 2 CPU and using 200m most of the time isn't just wasting its own allocation — it's preventing the scheduler from bin-packing other workloads onto the same node, which drives up node count and therefore cost across the whole cluster, not just that one pod's slice of it.

Idle non-production environments. Staging and dev namespaces that mirror production sizing twenty-four hours a day, seven days a week, despite being used for maybe eight hours on weekdays. Once cost is visible per namespace, this is usually the single fastest saving available — often 60-70% of that namespace's cost, just from scaling down or shutting down outside working hours.

None of this requires exotic tooling — it requires consistent labelling/annotation conventions so cost data can actually be joined back to team ownership, and a platform that surfaces the resulting numbers somewhere people will actually see them. That combination is what we build as part of our Kubernetes Performance & Cost Optimisation work.