Kubernetes Costs: More Than Meets The Eye

(Transcription below) 

In this webinar, you’ll learn why Kubernetes cost overruns are so common — and how they often stem from avoidable issues like over-provisioned workloads and poor resource visibility. We’ll explore the limitations of autoscalers, and why they can’t solve inefficiencies rooted in inaccurate requests or misconfigured pods. You’ll gain a clearer understanding of how resource mismanagement affects not only spend, but also performance and reliability. The session dives into practical strategies for right-sizing workloads, improving bin packing, and managing headroom to reduce cold starts. By the end, you’ll walk away with actionable techniques to run your Kubernetes environment more efficiently, confidently, and cost-effectively.

TL;DR – Why Cost Optimization Matters

• Kubernetes environments often suffer from hidden inefficiencies due to over-provisioning, under-provisioning, and guesswork around resource requests.
• Autoscalers (like Carpenter) help with node scaling but don’t solve inefficiencies at the workload level.
• Poor visibility into real-time usage and team-level consumption drives unnecessary cloud spend and operational risk.
• Cost optimization isn’t just about reducing bills — it’s about improving reliability, scalability, and engineering velocity.
• Real-time visibility, intelligent automation, and actionable guardrails are critical to closing the gap between engineering decisions and financial outcomes.
  

Key Takeaways from the Webinar

• Resource Guesswork Is Costly: Most teams over-allocate resources “just in case,” or under-allocate and suffer outages — both contribute to waste.
• Autoscalers Alone Aren’t Enough: Tools like Carpenter only respond to existing workload definitions; they don’t evaluate whether those definitions are optimal.
  
• Komodor Bridges the Visibility Gap: By analyzing real-time CPU/memory usage and pod behavior, Komodor offers actionable right-sizing and pod placement
  
• Built-in Guardrails Create Safe Automation: Users can control how aggressive automation is with buffer settings, change frequency caps, and CPU/memory rules.
  
• Bin Packing & Headroom Management Matter: Intelligent scheduling improves autoscaler efficiency and reduces cold starts by reserving just enough idle capacity.
  
• Cross-Team Accountability Is Essential: Komodor makes cost data visible across namespaces, teams, and clusters — tying spend directly to engineering actions.
  
• Proven Impact: Organizations implementing Komodor report 30–50% cost savings without compromising application reliability or performance.

Please note that the following text may have slight differences or mistranscription from the audio recording.

Ilan Adler: All right, we’re going to get started today. So welcome, everyone, to Kubernetes Costs More Than Meets the Eye: Strategies for Effective Kubernetes Cost Optimization. Thank you all for joining us.

I’m just going to go to the agenda and do quick housekeeping and introductions. So we’re going to talk about, obviously, Kubernetes costs, resource efficiency, how autoscalers play a part, some best practices and strategies, beyond some tools. We’ll do a quick demo of the new Komodor Cost Optimization features, and we’ll open it up at the end for Q&A.

So yes, this webinar is being recorded, as you probably heard. For that Q&A section, you’re welcome to use the Q&A button on the bottom of your Zoom screen, and you can ask questions, and then we’ll get to them at the end. The webinar today will be about 45 minutes long, give or take a few minutes.

And let me quickly introduce our speakers. I’m, by the way, Ilan Adler, Product Marketing Manager at Komodor. With me today is Kelly Freeman, Regional VP of Enterprise Sales, and Phil Edwards, a Solution Engineer from the Komodor Solution Architecture team. Welcome, Kelly and Phil. Just say hi, so I know you guys are there.

Kelly Freeman: Hello.

Phil Edwards: Good morning. Good afternoon, everybody.

Ilan Adler: All righty. And having said that, just before I hand it over to Kelly for the bulk of a presentation, we’re going to do like, just like, to see where people are standing, we’re going to do a quick 30-second poll. I’m going to launch the poll right now.

And the poll, as you see, is: What is the biggest contributor to Kubernetes cost overruns in your organizations? And I’ll give that, like, 15 more seconds for people to answer. Obviously, spoiler alert, a lot of the things are things that we see in the field and we’re going to talk about today. And a few more seconds…

So I’m going to end the poll. What we saw: 40% are incorrect or poorly configured resources, requests, and limits, and the rest were 20% for each of the following — inefficient scaling, idle and unused resources, and lack of visibility into what teams can consume which resources. Pretty in line with what a lot of customers and prospects share with us during calls.

And now I’m going to hand it over to Kelly Freeman for the rest of the presentation.

Kelly Freeman: Thank you so much. This is a question that we ask ourselves a lot and we hear each other ask quite often — why the heck is my bill so large? Let’s talk about that. But let’s start off by zooming out a little bit. Why are Kubernetes bills getting out of control?

Static capacity planning is not working, especially in a world of dynamic workloads. You’ve got CPU-bound, memory-hungry, and short-lived pods that are all in the same cluster. And when teams tend to over-provision just to be safe or reuse outdated configurations, it leads to two common outcomes.

Number one: over-provisioning, where you’re paying for resources that are just sitting there idle, which is not great. Or number two: under-provisioning, where you’re crashing under traffic spikes, which also isn’t great either. So the end result is inefficient bin packing, wasted capacity, and a cloud bill that’s really hard to explain, let alone justify.

The requests and limits are often guesswork. Admins say things like, “We’re overspending,” but we don’t know where. Or, “We can’t justify Kubernetes’ cost to finance.” This is what the FinOps Foundation calls the visibility gaps. So when engineers make allocation decisions with zero-cost context, there’s a gap that we’re here to close.

Kelly Freeman: So the Kubernetes resource efficiency problems — yeah, Kubernetes is powerful, but its cost efficiency relies on how well you understand and configure it. Resource requests and limits often feel like educated guesses. Teams are either over-provisioning just to be safe, or they’re under-provisioning and dealing with instability, which isn’t good. And this isn’t just about spend — it’s about performance risk.

The FinOps Foundation calls this the engineering cost disconnect, where decisions made at the pod level have major financial implications, but zero visibility to the people who are actually footing the bill. Our job is to help close that gap.

Defaults are inefficient. No one knows what’s actually needed. What this all adds up to is waste — a waste in time, a waste in compute, and a waste in budget. And the big kicker? Most of the performance issues stem from a lack of context. We’re not just fixing a spend issue — we’re actually fixing an observability and an ownership issue as well.

So we’ve spoken to a lot of Kubernetes admins over the years, and we’ve learned a couple of things and some feedback that we’ve been getting. We’re overspending, but we don’t know where to cut. Or just as important, we can’t justify our Kubernetes cost to finance — we actually hear that quite a bit. And thirdly, and just as important, is that resource requests and limits are basically guesswork. Provisioning is usually based on outdated assumptions, and defaults often go untouched.

The outcome: increased TCO — total cost of ownership, poor user experience for both your internal and your external customers, and overloaded teams dealing with performance issues without real context.

So it’s not just your platform team that are raising the red flags, though. It’s also the analysts — organizations like Gartner and IDC and others — that have spotlighted Kubernetes cost visibility and control as a top priority. And research is showing that organizations waste 30 to sometimes 40, even 50% of their Kubernetes spend. Not because they’re doing something wrong or nefarious, but because they’re missing insights — they’re missing context.

But if we bridge that gap, we don’t just save money — we’re improving reliability, performance, and just as important, team velocity. These aren’t just one-off complaints. They’re systemic issues that run across all industries and all verticals.

So let’s transition for a moment, if we can, to the concept of autoscalers, and a concept that’s really changed how many teams scale. Tools like Carpenter are dynamically provisioning and decommissioning nodes based on pod requirements in real time, which is great. They improve bin packing, they select optimal instance types, and they can leverage spot versus OD — on-demand — based on performance and trade-offs.

Yes, autoscalers were a big leap forward in Kubernetes efficiency. But as we’ll see next, they’re not the full solution.

So let’s talk about what autoscalers like Carpenter actually do well. They’re dynamically provisioned. They terminate nodes based on real-time pod requirements. They select instance types intelligently, reducing wasted space. And they also leverage different instance life cycles, like spot versus OD or on-demand, to balance cost and reliability.

These are huge gains, and many teams see significant improvements just by adopting tools like Carpenter. But while autoscalers are great, they’re not enough on their own.

So it’s important to remember that autoscalers can only optimize what they’re told to optimize, and most teams are feeding them bad data. If the workload is oversized, Carpenter will still replace it, but it doesn’t evaluate whether that pod needs four CPUs or just 400 millicores. And therein lies the challenge. It doesn’t account for bin-packing friction, evictions, and performance instability caused by poor scheduling policies.

To truly optimize, we need visibility and control beyond autoscaling. And that’s where Komodor steps in.

Now that we’ve seen the limits of autoscalers alone, let’s talk a little bit about what real Kubernetes cost optimization looks like. It’s not just about cutting spend. It’s about aligning performance, aligning efficiency, and visibility. And to do that, we need more than just node scaling. We need smarter workload management, right-sizing, and bin packing that actually works in the real world.

It’s optimization that actually sticks — no regressions, no one-size-fits-all attempts on it.

So visibility is really the first step in any cost optimization strategy. Komodor gives you the ability to track infrastructure cost by cluster, by namespace, by application, or environment. You can actually filter by team, zoom in on the anomalies, and tie financial data directly back to engineering action. This isn’t just about numbers — it’s about empowering teams to make smarter decisions with real-time feedback.

And when developers see the impact in dollars and cents, accountability becomes automatic. It actually becomes a natural course of action.

As Komodor continuously analyzes real-world usage patterns — whether it’s CPU, memory, throttling, and scheduling — it will actually make precise resource adjustments in real time. And this right-sizing isn’t just based on perception. It’s based on fact. It’s based on live behavior. So teams who have implemented this have seen anywhere between a 30% and a 50% reduction in cost without sacrificing reliability or performance. It’s really the difference between tuning for hope and tuning for reality.

As Komodor actively improves bin packing by grouping non-evictable workloads and placing pods based on scheduling constraints like affinity rules, PDBs, and resource limits, this reduces unallocated capacity and really unlocks autoscaler-driven consolidations. And again, it’s not just about saving money — this is about creating conditions for efficient scaling and high reliability.

So let’s break down Kubernetes cost optimization evolution and how it’s evolved. Moving left to right across the visual on the left, we have environments with neither Carpenter nor Komodor. It’s almost like a DIY environment. This is a manual zone. Static provisioning, no visibility, and constant firefighting. Teams rely on guesswork and over-provisioning to play it safe. The result? High costs and unpredictable performance.

As we move to the middle, you see teams using Carpenter alone. This adds autoscaling to the mix: better bin packing, lifecycle-aware provisioning, and some cost improvement. But Carpenter doesn’t address workload inefficiencies. If a pod is oversized, it’s still placed — just more quickly.

And on the far right, what you see with Komodor is where things really change. Now, workloads are right-sized in real time. Pod placement is constraint-aware. Non-evictable workloads are grouped intentionally. And autoscalers can consolidate effectively.

This is full-stack optimization. Cost, performance, and reliability — working together, not against each other.

Now what I’d like to do is bring in someone who’s been helping enterprise customers operationalize this every day. Phil Edwards is a senior solutions engineer here at Komodor. He brings years of experience helping engineering and platform teams get the most out of Kubernetes, both from a technical and a business perspective.

Phil’s going to speak briefly about best practices, and then he’s going to take us into the demo and show you exactly how all this comes to life in the Komodor platform.

Phil, over to you.

Phil Edwards: Thanks, Kelly. Go ahead and get the next slide, please.

So of course, as Kelly has been talking through, cost optimization is one thing that is very relevant and top of mind for me — cost efficiency is paramount. Of course, we want to be cost-efficient, we want to spend as little money as possible. But there are best practices and strategies that we can put in place that are going to not only help us attain those efficiencies, but also help us do it intelligently and under control, so that it’s reasonable — and ultimately, our cost efficiencies are as we expect them to be.

These four best practices are: setting guardrails, maintaining auditability, adopting a holistic approach, and correlating cost and reliability. Each of these are ways that we can gain those efficiencies while protecting our compute layer and protecting our applications as they run on Kubernetes.

When we look at setting guardrails, we’re talking about using policies and automation to limit risky manual changes and enforce best practices. We can set policies — for example, limiting how much we can right-size a workload. This protects us from problems like under-provisioning.

Then we have maintaining auditability and control. It’s great to have automation in place, and it’s great to see recommendations on how we should be making changes to our right-sizing, but we need auditability. We need something that’s logged. We need to be able to trace where and how our resources are being impacted. These auditable events should apply to both manual and automated approaches for your team.

Next, adopting a holistic approach. Cost efficiency and performance — these are organizational priorities. No single team should be responsible for them. We should work to eliminate silos. Too often we see a platform team toss a cost estimate over the wall to dev teams and say, “Fix it.” That rarely works. Instead, we need a shared approach where all teams are stakeholders in attaining efficiencies.

And lastly, correlating cost and reliability. Cost and performance are two sides of the same coin. This goes back to the problem of over-provisioning and under-provisioning. You right-size a workload, maybe too far — and suddenly you’re impacting reliability. Then you raise the limits again. It becomes a back-and-forth cycle.

Now we’re going to jump into the Komodor platform and walk through the cost optimization features that are now available. Before we do that, we’ll briefly walk through a few slides — three or four — then spend most of the time inside the product. Let’s go to the next slide.

As Kelly mentioned earlier, the cost challenge in Kubernetes is real. And now we’re talking about how Komodor solves that.

The first step is just getting visibility into your spend and allocation. Cost visibility starts with understanding overall infrastructure cost. You might think, “Well, I can just go to my cloud provider.” And sure, in many cases you can. But Komodor goes beyond that — breaking things down by namespace, by cluster, even based on annotations or labels inside workloads.

And what about real-time costs? Maybe your org is hybrid or multi-cloud. It’s not easy to get a full picture across all hosting providers — not to mention accounting for discounts, reserved instances, and usage-based pricing. That’s where Komodor helps.

Once we’ve got visibility, the next step is workload right-sizing. Komodor analyzes real-time CPU, memory usage, throttling, and scheduling data. This allows for intelligent optimization of your workloads — so we avoid both over-provisioning and under-provisioning.

Komodor is not just about cost optimization — it’s also about reliability and troubleshooting. We help make sure applications stay resilient, that teams avoid throttling, evictions, and scheduling issues.

And then there’s autopilot mode — right-sizing with guardrails. Many organizations love the idea of automation, but they want safety nets in place. We get that. So we allow for min/max thresholds, change frequency caps, buffer windows — everything you need to control the automation in a secure way.

Now let’s talk about bin packing. Kelly gave a great overview, and now we’ll dig deeper. Komodor increases the efficiency of autoscalers like Cluster Autoscaler and Carpenter by improving pod placement.

Bin packing isn’t just about maximizing node use. It also ensures autoscalers can scale up and — more importantly — scale down. That’s often where savings are missed. We avoid the issue of unevictable pods sitting on nodes you want to get rid of.

Now headroom. Carpenter doesn’t support headroom out of the box. You can hack it, sure, but Komodor gives you direct control over the conditions under which headroom is preserved. That means no more cold starts, no more pods waiting for new nodes to spin up.

That’s the last of the slides — now let’s move into the product demo. Let me go ahead and share my screen.

Okay, what we’re looking at is a demo environment inside Komodor. For those familiar with the platform, you’ll notice a new “Cost” section — this includes some new pages. These features may not yet be GA, so they might not show up in your current Komodor account. But we’ll walk through the four main pages to show you what’s new and how they help with cost efficiency.

First, we’ve got the Cost Overview page. Here we get high-level metrics: real cost, broken down into allocated (resources requested by workloads) and unallocated (idle resources). You can see monthly active savings — what Komodor is actively saving through right-sizing and bin packing. You’ll also see potential savings — areas where optimization isn’t enabled yet. For example, we’re showing nearly $36,000 in right-sizing savings — but only a portion of workloads have automation enabled. Komodor shows what more you could gain.

Below that, you’ll see cost trends — like a 30- or 60-day chart of your infrastructure spend. Ideally, we want that trending down over time.

Then we have pricing and discounts. Maybe Komodor doesn’t know your real cost because you’re on-prem or not connected to a cloud billing API. No problem — you can input pricing manually. We support custom pricing, reserved instances, and other scenarios.

Lastly, you can configure headroom directly from this UI.

Okay, now let’s jump to the Allocation tab. This goes deeper into the cost trends we just saw — more granularity. You can break things down by cluster, by namespace, by individual service. You can export this data or pull it through Komodor’s API to use in internal reporting or dashboards.

This is especially useful if automated right-sizing isn’t turned on yet — because it shows where you’re spending inefficiently.

Let’s move to Right-Sizing. This is one of the more exciting areas — showing how Komodor actively saves money through resource adjustments.

You’ll see two sections: Active Savings and Potential Savings. In Active Savings, you see real workloads that Komodor is optimizing in real time — and how much each one is saving. This is where auditability comes in. You can click into any change and understand what Komodor did and why.

In Potential Savings, you’ll see workloads that are eligible for optimization but aren’t automated yet. Maybe it’s because your team hasn’t enabled it, or maybe you’re waiting on approvals. You can click into any of these to see usage patterns, current requests and limits, and Komodor’s recommendation.

You’ll also see a cost optimization strategy setting — this lets you adjust how aggressive or conservative Komodor is when right-sizing. You can enable Autopilot with guardrails on any workload here. That includes guardrails like:

• Only apply changes on pod creation or restart
• CPU-only or memory-only adjustment
• Right-size up and/or down
• Max % change
• Buffers for spiky workloads 

That covers right-sizing — now let’s go to Pod Placement.

This is our bin packing section. You’ll see a breakdown of:

• Potential savings
• Active savings
• How many clusters have intelligent placement enabled 

There’s also a graph showing capacity and allocation over time — so you can see if efficiency is improving.

Like before, you’ll see the same auditability: which clusters, which pods, what savings are happening. For example, if you see high unevictable pod counts, that’s a good sign pod placement needs optimization.

That’s bin packing. And with that, I’ll stop sharing and hand it back for Q&A.

Ilan Adler:Thanks, Phil. That was really helpful — seeing how the theory translates into action inside the product.

Now let’s move to the Q&A section. If you haven’t already, please use the Q&A box in Zoom to submit your questions. We’ll try to answer as many as we can in the time remaining.

Phil Edwards:  First question coming in:

 “Does Komodor support multi-cluster cost analysis?”
Yes, absolutely. Komodor was built from the ground up with multi-cluster and multi-cloud environments in mind. You can group cost data by cluster, filter by team, namespace, environment — even apply custom tags and labels. This is really helpful when you’re trying to segment cost across business units or customers.

Second question:
“What’s the difference between Komodor’s right-sizing and what my cloud provider already offers?”
Great question. Cloud providers do offer recommendations, usually at the VM or node level. But Komodor focuses on workload-level right-sizing — which is far more granular. We don’t just look at infrastructure — we look at how each pod is behaving, in real time, across CPU, memory, throttling, and scheduling. It’s a much tighter feedback loop. And you can automate it with guardrails, which cloud providers typically don’t offer.

Third question here:
“Can Komodor help with performance issues like pod evictions and throttling?”
Yes — and in fact, we find that many performance issues are cost issues in disguise. When a pod is under-provisioned, you might see OOM kills, throttling, or scheduling delays. Komodor identifies these and shows where they’re linked to resource misconfiguration. That’s part of what makes it a reliability and performance tool, not just a cost tool.

Next one:
“How hard is it to enable Autopilot mode? What’s the risk?”
It’s very simple to enable, and you can do it selectively. You don’t have to turn it on cluster-wide. You can test it on a namespace, or even a single workload. You’ll set your guardrails: like how often it makes changes, how big the changes can be, whether it should wait for restarts or not. It’s very safe and auditable — you always see what changed and why. And you can roll back if needed.

Here’s another one:
“We’re using Carpenter. Do we still need Komodor?”
Carpenter is great, but it’s focused on node-level optimization. It doesn’t look at workload configuration — which is where most of the waste is. Komodor enhances Carpenter by feeding it better data. If your pods are oversized, Carpenter will just accommodate them — not challenge the assumption. Komodor does that extra layer of efficiency.

Next question:
“Does Komodor show historical data?”
Yes. You can view trends over time — for spend, resource allocation, bin packing efficiency. This helps with planning and capacity management. You can export the data or use the API to integrate it into your own dashboards or reporting tools.

Last one we’ll take today:
“Is this part of the core Komodor platform or an add-on?”
It’s part of the core platform. We’ve introduced these features as an extension of our mission — helping engineering teams manage Kubernetes more effectively, whether it’s through troubleshooting, reliability, or cost control.

Ilan Adler: That’s all we’ve got time for today. Thanks again to everyone for attending. Thanks to Phil and Kelly for sharing your insights and demoing the product.

You’ll get a recording of this webinar in your inbox shortly, along with a follow-up email with links to the documentation and getting started guide for Komodor Cost Optimization.

If you’d like a personalized walkthrough, just reach out — we’d be happy to set something up.

Thanks again for joining and have a great rest of your day.

Bye.