Your autoscalers are scaling. They’re not optimizing.

Karpenter, HPA, and Cluster Autoscaler do exactly what you tell them: they multiply whatever resource requests your workloads carry. If those requests are wrong, and in most environments they are, your autoscalers scale the waste right along with the workload. Kubex fixes the inputs so the whole stack works the way it was meant to.

Autoscalers react to resource requests. Kubex makes sure those requests are right.

Wrong requests cut both ways: over-provisioning burns money, under-provisioning causes OOM kills, throttling, and evictions

Fully compatible with Karpenter, HPA, VPA, Cluster Autoscaler, KEDA, Argo CD, and Flux CD

No rip and replace. Kubex works with the stack you already run.

The Misconception

“We already have autoscaling, so we’re optimized.” Not quite.

Autoscaling and optimization are different jobs. Autoscalers decide how many pods or nodes to run. They never question whether each pod is the right size in the first place. A workload requesting 4 CPUs when it needs 1 gets faithfully replicated at 4 CPUs, ten times over at peak. The scaling worked perfectly. The environment is still 4x over-provisioned.

Engineers over-request to play it safe, and autoscalers amplify every one of those decisions

The under-provisioned workloads are worse: starved requests mean OOM kills, CPU throttling, and eviction pressure that no autoscaler can fix

Manual request tuning can't keep up: configs are stale the moment they ship

Kubex continuously analyzes actual workload behavior and keeps requests accurate in both directions, so scaling decisions start from the truth

How Kubex fits with each component

Karpenter

Karpenter is excellent at picking the right nodes fast. But it provisions nodes based on what your pods request, not what they actually use. Kubex optimizes the pod templates underneath, so Karpenter bin-packs real requirements instead of padded guesses.

Right-sized requests mean Karpenter selects smaller, cheaper, better-fitting nodes

Better bin packing and higher node utilization without touching your Karpenter config

Karpenter scales faster and consolidates further when the inputs are accurate

HPA

HPA adds and removes replicas as load changes. Every replica inherits the same resource template. If that template is oversized, HPA multiplies the waste with every scale-out event. Kubex keeps the template right, so horizontal scaling stays efficient at any replica count.

Kubex optimizes the per-pod resources HPA replicates

Accurate requests improve HPA's utilization-based scaling decisions

Scale out on demand without scaling out the over-provisioning

VPA

“Why not just use VPA?” Fair question.

VPA is the native attempt at the problem Kubex solves, and it’s worth taking seriously. But VPA sets requests from simple percentile math over recent usage, with no understanding of workload patterns, cycles, or what’s coming next. It famously conflicts with HPA when both act on CPU or memory. And its recommendations still need someone to trust them enough to apply them.

Kubex models actual workload behavior over time, including patterns VPA's percentiles can't see

Vertical and horizontal scaling work together instead of fighting over the same metric

Kubex uses Kubernetes-native in-place resizing, so pods are right-sized without restarts

Policy-driven automation with guardrails, so recommendations get applied instead of piling up in a backlog

Cluster Autoscaler

Cluster Autoscaler does the same job as Karpenter with less sophistication: it adds nodes when pods can’t schedule and removes them when they’re empty. Its effectiveness depends entirely on workload sizing. Kubex ensures pods request what they need, so Cluster Autoscaler triggers less, packs tighter, and scales down sooner.

Fewer unnecessary scale-up events driven by inflated requests

Nodes drain and consolidate faster when workloads are right-sized

Works whether you run Cluster Autoscaler today or plan to move to Karpenter

KEDA

KEDA extends HPA with custom metrics, scale to zero, and scheduled scaling. It decides when and how many. Kubex decides how big. The two are complementary: KEDA-driven scaling events replicate pod templates that Kubex has already optimized.

Full compatibility with KEDA scalers, including scale to zero and cron-based scaling

Event-driven replicas launch at the right size from the first pod

Kubex analyzes the workload patterns behind your scaling behavior and surfaces where policies can improve

Argo CD & Flux CD

GitOps teams ask the right question: won’t an optimizer fight with my source of truth? Kubex was built for this. It mutates pods at admission, not deployments in Git, so Argo CD and Flux CD never see drift. Your manifests stay clean. Your sync stays green.

Pod-level mutation means no drift detection conflicts, ever

Full support for Helm chart deployments

Git remains the source of truth for intent; Kubex handles the runtime reality

Prometheus

Kubex deploys its own lightweight Prometheus instance via Helm, collecting the data it needs for analysis without touching your existing observability stack. No metric conflicts, no configuration changes, no risk to the monitoring you rely on.

Self-contained data collection, live in hours, first insight in under a day

Your existing Prometheus setup stays exactly as it is

No dependency on your monitoring configuration, so onboarding never stalls on integration work

The Result

The same stack. Actually efficient. Noticeably more stable.

Nothing gets replaced. Karpenter still picks nodes. HPA and KEDA still scale pods. Argo and Flux still deploy from Git. The difference is that every one of those components now operates on accurate resource definitions, continuously maintained by Kubex within guardrails your team defines.

20–30%

Typical infrastructure spend reduction, with more available as trust in automation grows

2x

Better resource utilization across the cluster

Stable

Right-sized workloads mean fewer evictions, OOM kills, and noisy-neighbor issues

Your autoscalers are ready.
Give them the right inputs.

Kubex connects to your existing stack in hours and starts showing where the waste lives on day one. Automation when you’re ready, guardrails from the start.