Skip to main content

Beyond Autoscaling: What True Kubernetes Optimization Actually Requires

Andrew Hillier
Densify

Kubernetes has become the backbone of cloud infrastructure, but it's also one of its biggest cost drivers. Recent research from CloudBolt Software shows that 98% of senior IT leaders say Kubernetes now drives cloud spend, yet 91% still can't optimize it effectively. After years of adoption, most organizations have moved past discovery. They know container sprawl, idle resources and reactive scaling inflate costs. What they don't know is how to fix it.

Autoscalers and schedulers promised efficiency, but they were never built to deliver full optimization. They simply react to workload changes by adding or removing capacity. That functionality helps maintain performance, but it doesn't prevent waste. Real optimization requires a deeper understanding of how compute, memory and storage interact, which requires expertise that platform owners rarely have the bandwidth to build.

The Limits of Reactive Scaling

Autoscaling solved one of the earliest challenges in container management: keeping applications online during demand spikes. It adjusts resources in real time and expands and contracts as workloads grow or shrink. But autoscaling is reactive by design and can't tell if a workload is oversized, misconfigured or idle. It only reacts when utilization crosses a threshold.

Over time, those small inefficiencies compound. Containers get deployed with default limits that are far higher than they need, old workloads linger after releases, and resource requests go unchecked. The result is a steady drift toward over-provisioned clusters that perform well but waste money.

Platform engineers can see the symptoms but not always the cause. They have dashboards full of metrics but no easy way to connect them to actual workload behavior. The autoscaler keeps things running, so the problems stay hidden.

Why Optimization Requires a Different Skill Set

Kubernetes administrators are experts in orchestration, networking and security, but optimization requires a different mindset. Optimization takes workload analysis, predictive modeling and capacity planning, which are skills more common in data science than DevOps.

Even with the right data, optimization is hard to operationalize. Engineers need to interpret performance metrics across thousands of pods and nodes, identify anomalies and test configuration changes without risking downtime. Manual tuning doesn't scale, and without automated guidance, teams revert to the safer option of over-allocating capacity.

That safety margin provides stability but drains budget. Many organizations operate their Kubernetes clusters at half the efficiency they could achieve. They think they're optimizing because the autoscaler is active but they're actually maintaining uptime instead of improving performance.

The Cost Awareness Era Is Over

The early years of Kubernetes adoption focused on education. Teams had to justify why container sprawl mattered and why cost control should be a priority. That conversation is over. Every CIO knows that Kubernetes efficiency directly affects cloud budgets. The challenge now is moving from cost awareness to continuous optimization.

Efficiency has become a competitive differentiator. When every organization runs similar technologies, the ones that can extract more performance from the same resources gain an advantage in scale and speed.

What AI Workloads Can Teach Us

The explosion of AI workloads has created a parallel challenge. As organizations race to build and deploy models, they've begun hoarding GPUs. That stockpiling behavior mirrors early Kubernetes over-provisioning, which was essentially buying insurance against scarcity. But waste is created in the process.

Some enterprises now sit on GPU clusters worth millions of dollars and running at minimal utilization. Engineers over-reserve capacity because visibility is limited, and they'd rather pay for idle resources than risk missing demand. It's an understandable response, but it exposes the same problem: a lack of proactive optimization.

The answer is to make buffering more intelligent. Teams need to know how much excess capacity is prudent and how much is waste. With data-driven utilization tracking, they can maintain readiness without turning idle hardware into a permanent expense.

From Reactive Scaling to Proactive Control

Modern optimization approaches view Kubernetes as a living system rather than a set of pods. They correlate workload behavior with resource allocation and identify when performance can be maintained with less capacity. Instead of responding to utilization spikes, they predict them and make preemptive adjustments.

A proactive optimization process typically includes four steps:

  • Workload mapping: Identify how applications consume compute, memory and storage resources across the cluster.
  • Demand forecasting: Use historical patterns to predict usage rather than reacting to it.
  • Configuration tuning: Adjust requests, limits and placement rules to balance performance with efficiency.
  • Continuous validation: Monitor performance after each change and recalibrate automatically.

These steps close the loop between capacity planning and real-world behavior and turn optimization from a one-off cleanup project into an ongoing discipline.

Efficiency as a Shared Responsibility

Kubernetes optimization used to fall entirely on platform teams but today it sits at the intersection of engineering, operations, and finance. The problem is that each group views efficiency differently. Developers think in performance, finance thinks in cost, and platform owners think in availability. The challenge is unifying those perspectives around a single measure of success.

Some organizations use the concept of yield to do this. Instead of tracking utilization as a binary metric, they measure output per unit of compute. This mindset shifts the goal from minimizing cost to maximizing return on capacity and reframes optimization as a business lever, not a maintenance task.

Yield optimization also acknowledges that some redundancy is healthy. Systems need a buffer to absorb demand surges or outages. The difference is intent. Capacity should be maintained with purpose, not just out of habit. A cluster that runs at 80% utilization with a controlled buffer performs better, and costs less, than one that runs at 50% because no one wants to touch the settings.

A New Phase for DevOps Maturity

Cloud efficiency is entering a new phase where optimization is critical. Economic pressure, sustainability mandates and AI expansion have converged to make reactive scaling insufficient. Autoscalers will keep workloads online, but they won't make them efficient.

The next generation of DevOps maturity depends on visibility and control. We need to know what's running, how it's performing and how much it costs in real time. Teams that treat optimization as an engineering discipline will run faster, spend less and scale with confidence. Kubernetes doesn't just need to work. It needs to work right.

Andrew Hillier is Co-Founder and CTO of Densify

Hot Topics

The Latest

Two years ago, almost every customer conversation about AI started with the same questions: Which model should we use? What can it do? Is it ready for the enterprise? Today, those discussions have moved on. CIOs are far more interested in how to govern AI, integrate it with existing systems, prepare their workforce and make it part of everyday operations. The challenge is no longer to prove that AI can deliver value. It's instead about how to embed AI into the business in a way that's secure, scalable and delivers measurable outcomes ...

 

Two things happened to production incidents between 2023 and now, and they did not happen at the same speed. The first is that a class of dependency that barely existed three years ago now accounts for one incident in ten. Incidents disclosed by AI model and AI application providers rose from 1.7% of all disclosed unplanned incidents in 2023 to 10.7% in 2026 year to date, roughly a sixfold rise; that counts only incidents at AI companies themselves, so the true share is higher. The second is that the time to close an incident has not come down ...

When an AI assistant gives an incomplete or incorrect answer, teams often blame the model. They adjust prompts, switch models, increase context windows or test a new retrieval strategy. However the model may not be a problem. In many enterprise AI workflows, the problem begins inside the document-ingestion pipeline ...

If you talk to any security or observability teams right now, they're all fighting the same fire: their tooling was built to ingest X, but their sources are pumping Y and soon to be doing Z. The knee-jerk reaction is always the same: we need more platform. However, this reaction is wrong. Let me explain why, because the solution to this problem is foundational, not financial. Instead of hurling yet more money at the problem, make sure you've done what's needed upstream ...

Rapid AI adoption and the unique ways AI workloads operate is redefining the scope and structure of what these teams must deliver. This shift is forcing organizations to rethink how they manage scale, automation, and control, according to The State of SRE and Platform Engineering 2026, a new report from Dynatrace ...

AI is usually talked about as a software tool, but it also depends heavily on the network behind it. Whether a company is using AI for chatbots, automation, monitoring, analytics, or employee support, all of that information has to move across the network in a reliable and secure way. That means AI is not just an application decision. It is also an infrastructure decision. Before organizations rush into AI, they should ask a simple question: Is our network ready to support it? ...

Enterprise AI often lacks governed access to where business processes actually execute. Without that access, AI agents may be able to reason, but they cannot operate reliably across enterprise workflows. For AI agents to effectively carry out workflows, they will require integration-layer context and controls. Organizations can implement these prerequisites by providing AI with managed access to the middleware layer ...

Enterprise networks rarely behave the same way for very long. A routing adjustment in one region may unexpectedly alter application performance in another. A cloud migration may introduce hidden dependencies that go unnoticed until an outage occurs. All the while, the network is managed by several different teams, each of whom use different tool sets — and as a result, have different views of the network ... There’s usually an engineer who remembers why traffic fails over a certain way between sites, or which transparent firewall was added where. The problem is that human memory cannot scale alongside enterprise-scale networks ...

Ask an infrastructure team how confident they are in their ability to govern AI, and most will tell you they've got it handled. A recent survey of 406 IT decision-makers and platform engineering leaders found 86% expressing exactly that confidence. Ask the same group whether they have a formal written AI governance policy, and the number drops to 30%, according to Spacelift's Infrastructure Automation Report ...

In MEAN TIME TO INSIGHT Episode 27, Shamus McGillicuddy, EMA VP of Research, Network Infrastructure and Operations, and Parker Hathcock, EMA Research Director covering IT Service/Operations (ServiceOps), discuss observability unification in modern IT operations ... 

Beyond Autoscaling: What True Kubernetes Optimization Actually Requires

Andrew Hillier
Densify

Kubernetes has become the backbone of cloud infrastructure, but it's also one of its biggest cost drivers. Recent research from CloudBolt Software shows that 98% of senior IT leaders say Kubernetes now drives cloud spend, yet 91% still can't optimize it effectively. After years of adoption, most organizations have moved past discovery. They know container sprawl, idle resources and reactive scaling inflate costs. What they don't know is how to fix it.

Autoscalers and schedulers promised efficiency, but they were never built to deliver full optimization. They simply react to workload changes by adding or removing capacity. That functionality helps maintain performance, but it doesn't prevent waste. Real optimization requires a deeper understanding of how compute, memory and storage interact, which requires expertise that platform owners rarely have the bandwidth to build.

The Limits of Reactive Scaling

Autoscaling solved one of the earliest challenges in container management: keeping applications online during demand spikes. It adjusts resources in real time and expands and contracts as workloads grow or shrink. But autoscaling is reactive by design and can't tell if a workload is oversized, misconfigured or idle. It only reacts when utilization crosses a threshold.

Over time, those small inefficiencies compound. Containers get deployed with default limits that are far higher than they need, old workloads linger after releases, and resource requests go unchecked. The result is a steady drift toward over-provisioned clusters that perform well but waste money.

Platform engineers can see the symptoms but not always the cause. They have dashboards full of metrics but no easy way to connect them to actual workload behavior. The autoscaler keeps things running, so the problems stay hidden.

Why Optimization Requires a Different Skill Set

Kubernetes administrators are experts in orchestration, networking and security, but optimization requires a different mindset. Optimization takes workload analysis, predictive modeling and capacity planning, which are skills more common in data science than DevOps.

Even with the right data, optimization is hard to operationalize. Engineers need to interpret performance metrics across thousands of pods and nodes, identify anomalies and test configuration changes without risking downtime. Manual tuning doesn't scale, and without automated guidance, teams revert to the safer option of over-allocating capacity.

That safety margin provides stability but drains budget. Many organizations operate their Kubernetes clusters at half the efficiency they could achieve. They think they're optimizing because the autoscaler is active but they're actually maintaining uptime instead of improving performance.

The Cost Awareness Era Is Over

The early years of Kubernetes adoption focused on education. Teams had to justify why container sprawl mattered and why cost control should be a priority. That conversation is over. Every CIO knows that Kubernetes efficiency directly affects cloud budgets. The challenge now is moving from cost awareness to continuous optimization.

Efficiency has become a competitive differentiator. When every organization runs similar technologies, the ones that can extract more performance from the same resources gain an advantage in scale and speed.

What AI Workloads Can Teach Us

The explosion of AI workloads has created a parallel challenge. As organizations race to build and deploy models, they've begun hoarding GPUs. That stockpiling behavior mirrors early Kubernetes over-provisioning, which was essentially buying insurance against scarcity. But waste is created in the process.

Some enterprises now sit on GPU clusters worth millions of dollars and running at minimal utilization. Engineers over-reserve capacity because visibility is limited, and they'd rather pay for idle resources than risk missing demand. It's an understandable response, but it exposes the same problem: a lack of proactive optimization.

The answer is to make buffering more intelligent. Teams need to know how much excess capacity is prudent and how much is waste. With data-driven utilization tracking, they can maintain readiness without turning idle hardware into a permanent expense.

From Reactive Scaling to Proactive Control

Modern optimization approaches view Kubernetes as a living system rather than a set of pods. They correlate workload behavior with resource allocation and identify when performance can be maintained with less capacity. Instead of responding to utilization spikes, they predict them and make preemptive adjustments.

A proactive optimization process typically includes four steps:

  • Workload mapping: Identify how applications consume compute, memory and storage resources across the cluster.
  • Demand forecasting: Use historical patterns to predict usage rather than reacting to it.
  • Configuration tuning: Adjust requests, limits and placement rules to balance performance with efficiency.
  • Continuous validation: Monitor performance after each change and recalibrate automatically.

These steps close the loop between capacity planning and real-world behavior and turn optimization from a one-off cleanup project into an ongoing discipline.

Efficiency as a Shared Responsibility

Kubernetes optimization used to fall entirely on platform teams but today it sits at the intersection of engineering, operations, and finance. The problem is that each group views efficiency differently. Developers think in performance, finance thinks in cost, and platform owners think in availability. The challenge is unifying those perspectives around a single measure of success.

Some organizations use the concept of yield to do this. Instead of tracking utilization as a binary metric, they measure output per unit of compute. This mindset shifts the goal from minimizing cost to maximizing return on capacity and reframes optimization as a business lever, not a maintenance task.

Yield optimization also acknowledges that some redundancy is healthy. Systems need a buffer to absorb demand surges or outages. The difference is intent. Capacity should be maintained with purpose, not just out of habit. A cluster that runs at 80% utilization with a controlled buffer performs better, and costs less, than one that runs at 50% because no one wants to touch the settings.

A New Phase for DevOps Maturity

Cloud efficiency is entering a new phase where optimization is critical. Economic pressure, sustainability mandates and AI expansion have converged to make reactive scaling insufficient. Autoscalers will keep workloads online, but they won't make them efficient.

The next generation of DevOps maturity depends on visibility and control. We need to know what's running, how it's performing and how much it costs in real time. Teams that treat optimization as an engineering discipline will run faster, spend less and scale with confidence. Kubernetes doesn't just need to work. It needs to work right.

Andrew Hillier is Co-Founder and CTO of Densify

Hot Topics

The Latest

Two years ago, almost every customer conversation about AI started with the same questions: Which model should we use? What can it do? Is it ready for the enterprise? Today, those discussions have moved on. CIOs are far more interested in how to govern AI, integrate it with existing systems, prepare their workforce and make it part of everyday operations. The challenge is no longer to prove that AI can deliver value. It's instead about how to embed AI into the business in a way that's secure, scalable and delivers measurable outcomes ...

 

Two things happened to production incidents between 2023 and now, and they did not happen at the same speed. The first is that a class of dependency that barely existed three years ago now accounts for one incident in ten. Incidents disclosed by AI model and AI application providers rose from 1.7% of all disclosed unplanned incidents in 2023 to 10.7% in 2026 year to date, roughly a sixfold rise; that counts only incidents at AI companies themselves, so the true share is higher. The second is that the time to close an incident has not come down ...

When an AI assistant gives an incomplete or incorrect answer, teams often blame the model. They adjust prompts, switch models, increase context windows or test a new retrieval strategy. However the model may not be a problem. In many enterprise AI workflows, the problem begins inside the document-ingestion pipeline ...

If you talk to any security or observability teams right now, they're all fighting the same fire: their tooling was built to ingest X, but their sources are pumping Y and soon to be doing Z. The knee-jerk reaction is always the same: we need more platform. However, this reaction is wrong. Let me explain why, because the solution to this problem is foundational, not financial. Instead of hurling yet more money at the problem, make sure you've done what's needed upstream ...

Rapid AI adoption and the unique ways AI workloads operate is redefining the scope and structure of what these teams must deliver. This shift is forcing organizations to rethink how they manage scale, automation, and control, according to The State of SRE and Platform Engineering 2026, a new report from Dynatrace ...

AI is usually talked about as a software tool, but it also depends heavily on the network behind it. Whether a company is using AI for chatbots, automation, monitoring, analytics, or employee support, all of that information has to move across the network in a reliable and secure way. That means AI is not just an application decision. It is also an infrastructure decision. Before organizations rush into AI, they should ask a simple question: Is our network ready to support it? ...

Enterprise AI often lacks governed access to where business processes actually execute. Without that access, AI agents may be able to reason, but they cannot operate reliably across enterprise workflows. For AI agents to effectively carry out workflows, they will require integration-layer context and controls. Organizations can implement these prerequisites by providing AI with managed access to the middleware layer ...

Enterprise networks rarely behave the same way for very long. A routing adjustment in one region may unexpectedly alter application performance in another. A cloud migration may introduce hidden dependencies that go unnoticed until an outage occurs. All the while, the network is managed by several different teams, each of whom use different tool sets — and as a result, have different views of the network ... There’s usually an engineer who remembers why traffic fails over a certain way between sites, or which transparent firewall was added where. The problem is that human memory cannot scale alongside enterprise-scale networks ...

Ask an infrastructure team how confident they are in their ability to govern AI, and most will tell you they've got it handled. A recent survey of 406 IT decision-makers and platform engineering leaders found 86% expressing exactly that confidence. Ask the same group whether they have a formal written AI governance policy, and the number drops to 30%, according to Spacelift's Infrastructure Automation Report ...

In MEAN TIME TO INSIGHT Episode 27, Shamus McGillicuddy, EMA VP of Research, Network Infrastructure and Operations, and Parker Hathcock, EMA Research Director covering IT Service/Operations (ServiceOps), discuss observability unification in modern IT operations ...