Is VPA “Good Enough”? How Kubex Delivers Enterprise-Ready Workload Optimization

Kubernetes workload rightsizing is one of those tasks everyone agrees is important and almost nobody enjoys doing by hand. Set requests too high and you pay for capacity that sits idle; set them too low and you invite CPU throttling, out-of-memory kills, and late-night pages. It’s no surprise, then, that many teams reach for the Vertical Pod Autoscaler (VPA) as their first step toward automated rightsizing.

And for good reason. VPA is an open-source project maintained by the Kubernetes community, it’s free, it’s well documented, and it does exactly what it says on the tin: it observes how your containers actually use CPU and memory, recommends better values, and can apply those recommendations automatically. For a single cluster, a development environment, or a team just starting its optimization journey, VPA is a genuinely useful tool and a great way to build confidence in automation.

But as environments grow, so do expectations. Organizations running hundreds of workloads across many clusters need more than “pretty good” recommendations. They need automation that coexists safely with other autoscalers, understands the full shape of their workloads, never leaves a pod stranded, and gives operators and executives clear visibility into what’s happening and why. That’s where many enterprises turn to Kubex.

In this article we’ll look at where VPA shines, where it reaches its limits, and how Kubex builds on the same core idea to deliver Kubernetes workload rightsizing that’s ready for production at scale.

Comparing VPA and Kubex for Kubernetes Workload Rightsizing

Working alongside the Horizontal Pod Autoscaler 

Most production workloads don’t rely on vertical scaling alone. The Horizontal Pod Autoscaler (HPA) is widely used to add or remove replicas as demand changes, often scaling on CPU or memory utilization.

This is where VPA requires some care. VPA should not be used together with HPA when both are acting on the same metric. Because HPA’s utilization targets are calculated as a percentage of the container’s request, a VPA change to that request shifts the very number HPA is reacting to. The two controllers can end up working against each other, and the result can be an uncontrolled scaling event: replicas multiplying or collapsing while requests swing back and forth. The usual workaround is to avoid the combination entirely, or to have HPA scale on custom or external metrics instead, which isn’t always practical.

Kubex takes this problem off your plate. It automatically detects when an HPA is managing a workload and identifies which metric that HPA is scaling on. Kubex then declines to adjust that resource, leaving HPA in full control of horizontal scaling. Importantly, it doesn’t simply walk away from the workload: Kubex continues to optimize the resource HPA isn’t using, such as memory per replica, so you still capture savings and stability gains without any risk of the two systems fighting.

Independent tuning of CPU and memory 

VPA’s approach to limits is straightforward. When it updates a container, it adjusts requests based on observed usage and, depending on configuration, scales limits proportionally to preserve the ratio between the original requests and limits defined in the manifest. If your manifest had a limit twice the size of the request, VPA keeps that two-to-one relationship as it moves the request up or down.

That’s a sensible default, but it assumes the original ratio was right in the first place, and it ties the behaviour of limits to a decision someone may have made months or years ago. Real workloads rarely behave that neatly. A service might need a generous CPU limit to absorb short bursts while its memory footprint stays flat and predictable, or the reverse.

Kubex adjusts CPU and memory requests and limits independently, each based on its own observed utilization. Think of it like the difference between a solid axle and four-wheel independent suspension in a car. With a solid axle, a bump under one wheel affects the others; with independent suspension, each wheel responds to the road beneath it on its own terms. The result is a smoother ride and far greater flexibility, and in Kubernetes terms, that means each resource setting is tuned to what the workload actually needs rather than to a fixed ratio inherited from the original manifest.

Safety checks before making changes 

Automation is only as good as its guardrails, and both VPA and Kubex take safety seriously. Each respects resource quotas, pod disruption budgets, and limit ranges, so changes stay within the policies your platform team has already put in place.

There’s one important difference, though. When VPA applies a new recommendation by evicting and recreating a pod, it doesn’t first confirm that a node exists with enough free capacity to accept the newly sized pod. If the recommendation grows the pod beyond what any available node can accommodate, the pod can end up stuck in a Pending state, turning an optimization into an outage.

Kubex adds that missing check. Before evicting a pod to apply a resize, it confirms that a node with sufficient capacity is available to schedule the updated pod. If there isn’t one, Kubex holds off rather than taking a workload offline. It’s a small step that makes a big difference to the confidence teams can place in fully automated optimization.

Depth of historical data 

Good recommendations depend on good data. By default, VPA bases its recommendations on roughly eight days of history. That’s enough to capture a typical weekly cycle, but it can miss patterns that unfold over longer periods: month-end processing, quarterly reporting runs, seasonal peaks, or batch jobs that only spike occasionally. Sizing to a short window risks under-provisioning a workload just before it needs its headroom most.

Kubex uses a configurable historical window that defaults to a full business quarter. That longer view captures the less frequent but often most critical demand peaks, so recommendations reflect how a workload really behaves across the business cycle. And because the window is configurable, teams can shorten or lengthen it to suit workloads with very different rhythms.

Visibility and observability 

VPA is a command-line and API experience. Its recommendations live in custom resources that you query with kubectl or surface through your own tooling. That’s perfectly workable for an engineer investigating a single deployment, but it offers little help to someone trying to understand optimization across an entire fleet, or to explain its value to the business.

Kubex includes a graphical interface and observability dashboards out of the box. Engineers can drill down to an individual workload to see what changed, when, and why, watching the automation in action. Platform leads and executives can zoom out to the macro view, with total resources reclaimed and costs saved across clusters. Having both perspectives in one place builds trust in the automation and makes it much easier to demonstrate the return on the investment.

VPA vs Kubex for Kubernetes workload rightsizing at a glance

Conclusion

So, is VPA “good enough”? For many teams, especially those starting out or working in smaller environments, the honest answer is yes. VPA is a solid, community-backed tool, and it deserves credit for making automated Kubernetes workload rightsizing accessible to any team.

Enterprise environments, however, raise the stakes. When workloads are scaled horizontally and vertically at the same time, when limits need tuning on their own terms, when a stranded pod means a customer-facing outage, when quarterly peaks matter, and when leadership wants to see the savings, organizations need more than a good starting point. Kubex builds on the same idea VPA introduced and adds the intelligence, safeguards, and visibility that production at scale demands.

Ready to see what enterprise-ready Kubernetes workload rightsizing looks like in your own clusters? Request a Kubex demo today and discover how much capacity, cost, and peace of mind you could be reclaiming.

FAQs

What is Kubernetes workload rightsizing?

Kubernetes workload rightsizing is the process of setting CPU and memory requests and limits to match what each container actually uses. Done well, it cuts spend on idle capacity while preventing CPU throttling and out-of-memory kills.

Can VPA and HPA be used together?

Yes, but not on the same metric. If HPA scales on CPU or memory utilization, VPA changes to that request shift the value HPA reacts to, which can trigger uncontrolled scaling. The common workaround is to have HPA scale on custom or external metrics. Kubex detects the HPA’s metric automatically, leaves that resource alone, and keeps optimizing the others.

Can VPA leave pods stuck in Pending?

Yes. VPA isn’t aware of node sizes, so it can recommend more CPU or memory than any available node can provide. When the resized pod is recreated, it can sit in Pending with nowhere to schedule. Even VPA’s newer in-place resize mode falls back to evicting the pod when the current node can’t fit the change. Kubex confirms a node has enough capacity before evicting, and holds off if none does.

How much historical data does VPA use for recommendations?

About eight days by default. That covers a weekly cycle but can miss month-end, quarterly, or seasonal peaks. Kubex uses a configurable window that defaults to a full business quarter.

When is VPA enough, and when should you consider Kubex?

VPA is a good fit for single clusters, dev environments, and teams starting out with automated rightsizing. Kubex is built for environments running many workloads across clusters, where HPA coexistence, node capacity checks, longer history, and fleet-wide visibility matter.