The 5 Kubernetes cost levers most DevOps teams never touch

You're running Kubernetes. Your infra works. Your team ships fast.

But every month, the cloud bill lands in your inbox and you think "wait, that's a lot" — and then you close the tab and move on.

Sound familiar?

Here's the thing: Kubernetes cost optimization is one of those topics everyone puts on the backlog and nobody actually prioritizes — until the CFO starts asking questions. Most teams are leaving between 30% and 50% of their Kubernetes spend on the table. Not because they don't care. Because the waste is invisible. You don't see it in your dashboards, you don't feel it in production — it just quietly burns through your budget.

We analyzed usage patterns across dozens of European startup clusters. The average waste? Around 40% of monthly cloud spend — mostly from oversized resources and idle non-prod environments.

Let's fix that.

1. Your containers are asking for way too much (and nobody's checking)

When a developer writes resources: requests: memory: 512Mi, they're making a guess. A cautious guess. And that's fine — except when you multiply that by 200 containers across your cluster.

The result? Your nodes look "full" on paper, but half the memory is never actually used. You end up spinning up more nodes than you need, paying for compute that's just sitting there.

The fix is called right-sizing — matching what your containers actually use with what they ask for. Tools like VPA (Vertical Pod Autoscaler) can automate this. But even without automation, just auditing your top 20 workloads once a quarter makes a huge difference.

The impact: typically 20-35% cost reduction on compute alone.

2. Your nodes are half-empty and nobody's packing them properly

Even with good resource requests, your cluster scheduler has a hard job: fitting pods onto nodes like a 3D Tetris. It often leaves gaps — nodes that are 60% used while new nodes keep getting added.

This is a bin packing problem, and your default autoscaler doesn't solve it aggressively enough. It's great at scaling up. It's terrible at consolidating down.

The smarter approach: simulate what your cluster could look like if you reshuffled workloads, then make it happen. Some teams do this manually. Some use tools (more on that below). The point is — it's not automatic, and someone needs to own it.

The impact: fewer nodes, same workloads, lower bill.

3. You're running everything on on-demand when Spot could handle most of it

Spot instances (or preemptible nodes, depending on your cloud provider) can be 60-80% cheaper than on-demand. Most teams don't use them because they're afraid of workload interruptions.

Fair concern. But here's the reality: stateless workloads — your APIs, your web apps, most of your microservices — handle Spot interruptions just fine with the right setup. You just need proper pod disruption budgets and a mixed node pool strategy.

You don't need to go all-in on Spot. Even moving 40% of your workloads to Spot nodes can cut your compute bill significantly.

The impact: up to 40% off your node costs with the right workload mix.

4. You don't know which team or service is actually costing you money

Here's an underrated problem: you have one bill, but 5 teams shipping to the same cluster. When costs go up, nobody knows who's responsible. So nobody acts.

This is a visibility problem before it's a cost problem. If your CTO can see that the data pipeline team is consuming 3x their expected share, that conversation becomes easy. Without that visibility, everyone just shrugs.

Tagging workloads by team, product, or environment (prod vs staging) and tracking costs per namespace is the foundation. Once you have that, cost accountability becomes natural.

The impact: not just savings — a culture shift where teams own their spend.

5. Your staging environment runs 24/7 for no reason

This one's almost embarrassing when you catch it. Staging, QA, dev environments — full clusters, running all night, all weekend, nobody using them.

A simple scheduled scale-down (nights + weekends) can cut your non-prod costs by 60-70%. It takes an afternoon to set up and pays back immediately.

Some teams go further with ephemeral environments — spin up, run your tests, tear down. But even the basic scheduler is a huge win most teams skip because "we'll do it later."

FAQ — Kubernetes cost optimization

What is Kubernetes cost optimization? It's the practice of reducing cloud spend on Kubernetes clusters without impacting performance or reliability. It covers right-sizing containers, consolidating nodes, using Spot instances, and gaining visibility into who's spending what.

How much can I realistically save on my Kubernetes bill? Most startups save between 30% and 50% after a proper audit. Quick wins like shutting down staging environments at night and right-sizing the top 20 workloads alone can cut 20-30% within weeks.

Do I need a specialized tool to optimize Kubernetes costs? Not necessarily for the basics — scheduled scale-downs and resource audits can be done manually. But once you're running multiple teams or clusters, a dedicated tool to track costs per namespace, service, and environment becomes essential for accountability.

What's the difference between Kubernetes cost optimization tools like Cast.ai, OpenCost, and Costlyst? OpenCost is open-source and great for visibility but requires significant setup. Cast.ai is powerful but expensive and US-centric. Costlyst is built specifically for European startups on providers like OVH, Scaleway, and GKE — with GDPR compliance built in and pricing that makes sense for growth-stage companies.

Is Spot instance usage risky for production workloads? For stateless workloads (APIs, web apps, microservices), the risk is manageable with proper pod disruption budgets and mixed node pools. Spot instances are not recommended for stateful workloads like databases without additional safeguards.

So where do you start?

The honest answer: with visibility. You can't optimize what you can't measure.

Most teams don't have a clear picture of where their Kubernetes money is actually going — by service, by team, by environment. That's the gap Costlyst was built to close.

We built it for European startups and scale-ups running on GKE, OVH, or Scaleway — the ones who don't need a $50k/year enterprise platform, but do need real numbers to make smart infra decisions.

If that sounds like you, check out Costlyst →

Got a question or want to share your own cost horror story? Reach out on LinkedIn — always happy to talk infra.