Compliance
Kubernetes cost blind spots: what namespace-level allocation actually fixes
06 August 2026
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's exactly what our Cloud & Kubernetes Performance & Compliance platform does out of the box, alongside the compliance scanning it runs from the same inventory — and it's the same discipline we bring to bear directly as part of our Kubernetes Performance & Cost Optimisation consultancy work.
Frequently asked questions
What's the fastest Kubernetes cost saving to find?
Non-production namespaces (dev, staging, test) that run at full production-equivalent size around the clock. Scaling these down or scheduling them off outside working hours is usually the single largest, lowest-risk saving available.
Do we need a dedicated FinOps tool to see cost per namespace?
Not necessarily a dedicated commercial tool, but you do need consistent labels/annotations on workloads so cost can be joined back to a namespace and team - that convention matters more than which specific tool reads it.
Does rightsizing requests risk application stability?
Only if done blindly. Rightsizing based on real historical utilisation data (not guesswork), with a sensible buffer, reduces waste without meaningfully increasing the risk of a pod being throttled or OOMKilled.
Want to talk this through?
Happy to go into more detail, or look at how it applies to your own setup.
Speak with us