Why it’s time to get off the manual Kubernetes optimization treadmill

By Pini Ben-Nahum

VP of R&D

Most DevOps teams managing Kubernetes environments are not fully manual anymore. They use monitoring dashboards, autoscalers, and sometimes predictive tools. The trouble we keep seeing is that these tools still need regular human involvement. Someone has to interpret the data, decide on actions, and make the changes.

This “semi-automation” gives a sense of progress but still leaves engineers stuck in the same loop. You see a problem, adjust resources, wait, and repeat. Over time, that loop burns through engineering hours, increases the chance of mistakes, and wastes money.

As workloads grow more complex, keeping up with this cycle becomes more difficult each month.

The limits of today’s optimization tools

Most Kubernetes optimization solutions fall into two main types.

1. Visibility and recommendations tools These tools might point out that a workload is over-provisioned or that CPU requests could be lowered, but they rarely execute changes automatically. They also do not always consider the trade-offs between cost and performance, or the fact that workloads often have different priorities.
2. Standalone automation tools Some tools can act on their own, but usually within a single scope. A horizontal pod autoscaler might not coordinate with vertical scaling logic. A cost optimization tool may have no connection to performance tuning. This creates a patchwork of changes that do not work together and can even cause conflicts.

The lack of integration means engineers still have to oversee coordination, validate the impact of changes, and resolve issues when tools make conflicting adjustments.

The cost and risk of incomplete automation

Partial automation still leaves room for waste and risk:

• Operational overhead: Teams spend nearly half their time on manual intervention that could be avoided.
• Human error: A missed rollback or an incorrect configuration can lead to expensive waste. Industry surveys show that preventable mistakes and manual processes account for between 21% and 50% of cloud waste, representing billions of dollars in unnecessary spend each year. Kubernetes environments are no exception. Missteps in scaling, provisioning, or rightsizing can have an immediate and costly impact.
• Slow reaction times: Manual oversight cannot match the pace of workload changes.
• Financial impact: Overprovisioning, underused commitments, and unnecessary scaling events all add up.

These scenarios are not theoretical. I have seen teams hit with five- or six-figure charges because of a misconfigured autoscaler or a forgotten resource. As environments grow, so does the scale of the damage.

Why Kubernetes optimization is getting harder

Optimization is happening in a more unpredictable environment than before.

• AI and LLM workloads are introducing new patterns in resource usage. GPU utilization spikes behave differently from CPU load, and storage needs can grow suddenly with training or inference runs.
• User behavior is more volatile. In the past couple of years, we’ve seen traffic patterns in our customers’ environments that used to shift over weeks now change in a matter of hours. Seasonal trends are less reliable, and unexpected surges are happening more often.
• Infrastructure diversity is increasing. Multi-cloud, hybrid deployments, and edge workloads make the Kubernetes optimization problem more complex. Visibility is also extremely challenging in multi-cloud deployments.
• Commitments can conflict with autoscaling. Cloud provider commitments (like Savings Plans) are still crucial in keeping cloud costs down, and most organizations use them to some extent. The problem is that when commitments aren’t managed in sync with Kubernetes autoscaling (HPA/VPA), the two can end up working against each other, leading to overprovisioning, wasted spend, and scaling decisions that don’t align with the actual workload.

The speed and unpredictability of these changes mean that any approach depending on human reaction will eventually fall behind.

The case for a unified, multi-layer automation platform

The solution is not simply to add more automation, but to connect and coordinate it across different layers.

Integrated platform approach Instead of using separate tools for cost optimization, scaling, and monitoring, these capabilities should work together in one system. This allows:

• Direct links between resource optimization and financial optimization, so scaling decisions take both into account.
• The ability to apply different automation strategies to different workloads depending on their purpose and performance needs.
• Less operational overhead from switching between tools and trying to make them work together manually.

Holistic scaling Coordinating horizontal and vertical scaling improves both performance and cost efficiency. For example, the system might scale vertically first to handle immediate load, then horizontally to sustain higher traffic, without human intervention.

Optimization across dimensions CPU, memory, storage, and cloud commitments should be tuned together. Separate adjustments in isolation leave efficiency gains unrealized.

The business impact of true multi-layer automation

From what I’ve seen, when teams move to an integrated, multi-layer automation approach, the improvements are easy to spot. In practice, that often translates into:

• Reduced cloud waste, as resources are right-sized more often and waste is caught before it piles up.
• Faster response to demand changes, which goes a long way in maintaining SLA commitments.
• More engineering time freed from repetitive manual tuning and troubleshooting.

When you put those together, you end up with more budget and brainpower for the projects that actually move the business forward.

Looking Ahead

The shift from manual and semi-automated optimization to fully integrated automation is already underway. As AI adoption accelerates and usage patterns become less predictable, the gap between early adopters and late movers will widen.

Teams that optimize before a problem appears will be in a stronger position than those that react after the fact. They will also keep their engineering talent focused on innovation rather than firefighting.

The Time of Full Automation

Manual optimization had its place. Semi-automation helped push things forward. But the systems that succeed now are the ones that coordinate optimization across every layer and every workload without waiting for a human to step in.

The technology is available. The choice is whether to keep running on the treadmill or step off it entirely.