Teams rarely notice their Kubernetes bill creeping up until it's already a line item someone asks about in a leadership meeting. By then, the causes are usually a year old and tangled together. In our experience, the order they show up in is fairly consistent — and fixing them out of order wastes effort.
1. Default resource requests are guesses, and guesses run high
Most teams set CPU and memory requests once, early, based on a rough guess or a copy-pasted example manifest. Nobody revisits them once the service is stable. Multiply a 30% overestimate across every pod in a cluster and you're paying for capacity that never gets used — capacity the autoscaler still has to provision nodes for.
The fix isn't guessing better. It's setting requests from actual observed usage (via kubectl top, or better, historical Prometheus data) and revisiting them on a cadence, the same way you'd revisit any other cost assumption.
2. Idle namespaces accumulate faster than anyone tracks
Feature branches get their own namespace for testing. Staging environments outlive the feature they were created for. Nobody owns cleanup, so nothing gets cleaned up. This is rarely a dramatic cost — but it's a compounding one, and it's usually invisible until someone builds a dashboard that breaks cost down by namespace instead of by cluster.
3. Autoscaling configured once, never tuned against real traffic
Horizontal Pod Autoscaler and cluster autoscaler settings that were reasonable at launch often stop matching reality within a few months. We frequently see scaling thresholds tuned for a launch-day traffic pattern still running a year later, either scaling too aggressively (cost) or too slowly (reliability risk during real spikes).
Reliability work has to come after cost visibility, not before
Here's the part that surprises teams: fixing reliability gaps — better health checks, pod disruption budgets, multi-AZ scheduling — usually increases infrastructure cost before it improves anything, because reliability work adds redundancy. If you do that work before you've addressed the cost issues above, you end up compounding an already-inflated bill and the org concludes, incorrectly, that "Kubernetes is just expensive."
The order that actually works:
- Get cost visibility by namespace, team and workload first.
- Right-size requests and clean up idle resources.
- Retune autoscaling against current, not launch-day, traffic.
- Then invest in the reliability improvements that add redundancy.
Reliability and cost aren't in tension long-term — but the sequence you address them in determines whether your Kubernetes platform earns trust or earns a reputation for being expensive.
This is a pattern we've worked through directly in our own Kubernetes platform baseline lab, which builds resource governance and autoscaling in from the start rather than retrofitting it.
Related services