Kubernetes Resource Optimization Platforms: Compared by Layer

Most teams do not begin Kubernetes optimization with a long-term strategy. They begin by eliminating the most visible waste.

The first thing a team commonly notices is a high cloud bill that nobody can attribute to a specific application workload. So they start by focusing on cost visibility. Once they identify spending by namespace, they begin manually rightsizing CPU and memory requests of over-provisioned pods for that application workload. Manual right-sizing remains the standard operating procedure until it can no longer keep pace with the rapid changes in workloads. The next steps usually involve implementing Kubernetes-native pod and node auto-scaling, creating a complex environment that requires additional configuration and ultimately intelligent automation.

We evaluated multiple tools used for Kubernetes cost reporting and auto-scaling to explain the strengths, weaknesses, specializations, and differences. By the end, you should be able to decide which tool belongs at each layer of the application and Kubernetes control planes, and which is better suited to your needs.

Summary of the differences between Kubernetes resource optimization platforms and features

Category	Platform	Pros and Cons
Vertical Pod Autoscaler(VPA) and open-source tooling	Kubernetes’ native VPA	Generates rightsizing recommendations and can apply them, but its Recreate path evicts pods.
	Goldilocks	Wraps VPA output in a dashboard for teams that want visibility without an automated application.
Node-level autoscaling	Karpenter	Optimizes cluster cost by provisioning and removing nodes based on aggregate demand. Addresses waste at the infrastructure layer but not per-workload over-provisioning.
Cost visibility platforms	Kubecost and StormForge by CloudBolt	Attribute spend and surface rightsizing suggestions next to cost-impact estimates.
ML-based optimization	StormForge by CloudBolt	Build workload-specific models from historical usage data, then apply changes automatically without pod disruption

Platforms differ across five operational dimensions: 

1. Automation depth
2. Recommendation methodology
3. Disruption handling during spec changes
4. Multi-cluster scope
5. Integration with cost governance.

Selection depends on team maturity, cluster scale, and whether the goal is visibility, governance, or automated optimization. Most production environments combine tools from several categories.

Why over-provisioning persists

Before comparing tools, it helps to see the waste they target, which is structural rather than careless.

The Kubernetes scheduler places pods based on requests, not actual usage. When a pod requests 2 vCPUs, the scheduler reserves 2 vCPUs on a node, whether the pod uses them or not. The reserved capacity is billed even when it sits idle.

Consider a deployment with 20 replicas, each requesting 2 vCPUs and 4 GiB of memory. This reserves 40 vCPUs and 80 GiB across the cluster. Now suppose the workload’s P95 usage is 0.5 vCPU and 1.5 GiB per pod — meaning 95% of observed usage stays at or below that level. Real demand across the deployment is only 10 vCPU and 30 GiB. That’s 25% CPU utilization against what’s reserved, or 75% of the reserved CPU paid for but never used. Memory tells a similar story: 37.5% utilized, meaning 62.5% of reserved memory sits idle.

Multiply that pattern across hundreds of deployments, and the gap becomes the single largest line item in a Kubernetes bill. The root cause is that engineers set requests once, pad them for safety, and rarely revisit them. This is the gap every tool category below tries to close, but through different approaches.

How platforms differ in their Kubernetes resource optimization approach

Kubernetes can scale in three directions, and each category operates on a different one. These three approaches are independent. A workload can have the right replica count, the wrong per-pod size, and be on oversized nodes all at once, which is why most production setups combine multiple tool categories.

Vertical scaling 

Vertical scaling changes the amount of CPU and memory each pod requests. These tools try to answer how big each pod should be. It corrects requests that were set once and never matched to real usage. The Vertical Pod Autoscaler (VPA) works here.

Horizontal scaling

Horizontal scaling changes the number of pod replicas. These tools try to answer how many copies the workload needs right now.

The Horizontal Pod Autoscaler (HPA) adds replicas when a metric such as CPU utilization climbs and removes them when it falls. 

Running Kubernetes-native HPA and VPA on the same metric simultaneously creates an inefficient, infinite feedback loop. 

1. Per node utilization goes up.
2. VPA raises a pod’s CPU request
3. Per node utilization drops
4. HPA removes replicas
5. Per node utilization goes back up.

The standard guidance is to let HPA scale on a custom or external metric whenever VPA manages CPU and memory, so the two do not conflict over the same signal. 

A newer class of ML-based Kubernetes resource optimization platforms resolves this conflict directly, as discussed later in this article.

Node scaling

Node scaling changes the underlying machines. Karpenter and the Cluster Autoscaler add and remove nodes based on the combined requests of all scheduled pods, which is the infrastructure layer beneath both pod-scaling directions.

Evaluation criteria for Kubernetes resource optimization platforms

We propose below a set of criteria for evaluating Kubernetes resource optimization tools.

Automation depth

Automation depth is the primary differentiator. Recommendation-only tools reduce manual analysis, but an engineer still has to review each suggestion and apply it. In contrast, fully automated tools remove that operational overhead. The trade-off is that automation demands higher confidence in the model, because incorrect estimates now ship without a human in the loop.

Recommendation methodology

Rule-based tools apply a usage percentile target, such as “set requests at the P95 of the last seven days,” while machine learning tools model each workload’s usage distribution separately. The difference is most evident in workloads with seasonal or event-driven traffic.

Disruption handling during spec changes

Disruption behavior during spec updates is where tool mechanics become critical. A tool that applies changes by evicting and recreating pods introduces restart risk for stateful workloads and long-running jobs. In-place pod resizing, a Kubernetes feature that changes a running pod’s requests without restarting it, reached beta in 1.33 and went stable in 1.35, so the same recommendation can be safe or disruptive depending on how the tool applies it.

Multi-cluster and multi-cloud scope

A team running workloads across EKS, AKS, and GKE needs recommendations and cost data aggregated across cloud boundaries. A tool that operates per cluster in isolation pushes that aggregation back onto the team.

Integration with cost governance

This differentiates whether savings flow into chargeback and budget workflows or stop at the cluster edge as a dashboard number that finance never sees.

The table below summarizes how the various tools perform against the selection criteria

Dimension	VPA / Goldilocks	Karpenter	Kubecost / OpenCost	ML platforms (StormForge by CloudBolt)
Automation depth	Recommendation, or apply via eviction	Automated at the node layer	Recommendation only	Automated at the workload layer
Methodology	Percentile over a lookback window	Bin-packing on declared requests. Fits pods onto as few nodes as possible.	Configurable percentile targets	Per-workload ML models
Disruption handling	Recreate by default; in-place is newer	Node churn during consolidation	Not applicable, no actuation	In-place resize where supported
Multi-cluster scope	Per cluster	Per cluster	Per cluster, aggregation add-on	Cross-cluster and multi-cloud
Cost governance	None	None	Strong attribution, weak enforcement	Chargeback and policy via CSMP

VPA and open-source recommendation tooling

The first layer most teams reach for is the free, native one. The Vertical Pod Autoscaler monitors actual usage and suggests CPU and memory requests that fit the workload.

VPA update modes

VPA runs in several update modes. 

• Off mode – It only writes recommendations to its status field
• Initial mode – It sets requests when a pod is created and never changes them. 
• Recreate mode – Evicts a pod to apply new requests and lets the scheduler recreate it. 
• InPlaceOrRecreate mode – Attempts an in-place resize first and falls back to eviction only when in-place is not possible.

The older Auto mode is deprecated as of VPA 1.4.0, released in May 2025, so current setups should name the update mode directly rather than rely on Auto. 

The eviction behavior creates challenges. For a stateless web service, a restart is cheap, but for a database replica or a multi-hour batch job, an eviction can significantly escalate costs. Until in-place resize is widely available across managed clusters, VPA in an applying mode stays best suited to workloads that tolerate restarts.

Running VPA in recommendation mode avoids the disruption:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  updatePolicy:
    updateMode: "Off"   # write recommendations only, do not evict

Goldilocks as a dashboard layer

Goldilocks is the common layer on top of VPA. It deploys a VPA object in recommendation mode for each deployment and surfaces the results in a namespace-level dashboard. Teams receive rightsizing guidance without having to read the raw VPA status output. It is a low-friction way to see how far requests have drifted from reality.

Tool category limitations

The limitation is the methodology, because neither VPA nor Goldilocks accounts for time-of-day variation or workload seasonality. A recommendation built on a seven-day lookback window underfits a workload with a monthly close cycle or an event-driven spike. Your metrics may look precise even though the model was trained on a window that never saw the peak.

Key insight: VPA and Goldilocks are satisfactory tools for learning where requests have drifted, but they weaken once the question shifts from “where is the drift?” to “are these recommendations viable?”, and “how can I apply the right requests safely across thousands of variable workloads?”

Node-level autoscaling with Karpenter

Rightsizing fixes the pods, but the nodes underneath them can still be wrong, which is the problem Karpenter solves. It provisions nodes sized to match aggregate pod demand and removes nodes that fall idle, reducing waste at the infrastructure layer.

What Karpenter does not touch

What Karpenter does not do is question the pod requests it is given. It provisions capacity for whatever requests pods declare, so if those requests are oversized, it faithfully provisions larger and more expensive nodes than the workloads actually need. The cluster looks well packed while still running on inflated assumptions.

Why rightsizing and node autoscaling compound

This is why node autoscaling and pod rightsizing are complementary rather than competing. Return to the earlier example, where 20 replicas requesting 2 vCPUs each create 40 vCPUs of demand, so Karpenter provisions enough node capacity to seat 40 vCPUs. Rightsize those requests to 0.7 vCPU, and demand drops to 14 vCPUs, so Karpenter consolidates the workload onto far smaller nodes. 

Neither tool reaches that result alone. Tighter requests produce smaller bin-packing targets, which in turn lead the scheduler to fit pods onto as few nodes as possible, reducing the node bill.

Coordinating the disruption between the two

There is one interaction to plan for. Karpenter’s consolidation logic terminates and replaces nodes to cut cost, and a rightsizing tool may move pods at the same time, so both actions touch availability. Combining them means coordinating PodDisruptionBudget settings, the policy that caps how many pods of a workload can be unavailable at once, across both systems, so two optimizers do not evict the same workload together.

Cost visibility platforms with rightsizing modules

Node efficiency assumes you already know where the money goes, so cost visibility becomes the first requirement. Kubecost and OpenCost attribute spend by namespace, workload, and team, and they surface rightsizing suggestions next to projected savings. OpenCost is the CNCF-standard specification for this attribution, and Kubecost builds on it. This category is useful for finding waste and building a business case.

From recommendation to implementation

Recommendations are based on configurable usage percentile targets rather than per-workload modeling, and to apply them, a team updates specs by hand or builds custom automation on top of the tool. The platform tells you what to change and leaves the change to you.

This results in a visibility-to-actuation gap, where a team can see exactly what to fix and still spend weeks of engineering time applying fixes across hundreds of deployments.

That gap is structural, not accidental. Cost visibility is the core product for these tools, so rightsizing is an add-on module, and that shows in both the depth of the recommendations and the absence of an automated application.

The cluster boundary

Another limitation is that attribution is bounded by the cluster, so VMs, managed databases, and on-premises spend never appear in the same cost report. For an organization where Kubernetes is one part of a mixed estate, it leaves finance reconciling two systems by hand.

Key insight: Treat Kubecost and OpenCost as the diagnostic layer, excellent at finding and attributing waste but not designed to close the loop by applying changes, which is the next layer’s job.

ML-based workload optimization platforms

The earlier layers leave two challenges, recommendation accuracy and automated safe application, which are both overcome by ML-based platforms.

How the platform caters to every workload

The accuracy gap stems from uniform percentile targets because a single target applied across all workloads is too loose for a stable service and too tight for a spiky one. Machine learning models take a different approach and learn each workload’s usage distribution independently. A steady internal API gets a tight recommendation, while a variable, event-driven service gets wider margins. The model also accounts for time-of-day variation and deployment events, so a nightly batch peak does not get averaged away.

StormForge by CloudBolt sits in this category. It builds workload-specific models from historical usage, then applies the result using in-place resource updates where the cluster supports them, so changes land without evicting pods.

Joint scaling and automatic scope

Two capabilities separate this approach from the earlier layers. The first is joint scaling: a patented forecast-based model tunes CPU and memory requests alongside the HPA target utilization from a single model, resolving the feedback loop that otherwise forces teams to keep VPA and HPA on separate signals. 

In effect, it is bi-dimensional pod autoscaling, vertical and horizontal optimized together rather than one at a time. This is automatic: new pods are discovered and classified as they appear, so a workload that ships today is profiled and brought under optimization without anyone adding it by hand. That keeps automated rightsizing ahead of workloads that change faster than a manual review cycle can keep up with.

The staged path to automation

Users develop trust in automation if it’s presented in multiple stages. A platform of this kind starts in a read-only recommendation mode, so a team can compare its numbers against real workload behavior before anything changes. When the team is ready to automate, changes roll out progressively to a percentage of pods to monitor error rates. Rollback is built in, so a workload that regresses returns to its prior spec without manual intervention. Read-only first, then a controlled rollout, then full automation, is the sequence that lets a team hand over rightsizing without handing over availability.

Feeding savings into governance

The second reason to consider this category is what sits above the cluster. Workload-level savings can feed a governance layer, where rightsized data flows into a multi-cloud cost model and into chargeback and budget workflows rather than stopping at a cluster dashboard. How far that link extends and how specific products implement it are questions of named tools rather than categories, and that comparison lives in the companion article noted below.

The trade-off is honest because this category carries license costs and asks a team to trust automated changes. Trust is earned through the staged rollout above rather than assumed. For a small cluster with stable workloads, VPA recommendations may be enough, and the case for an ML platform strengthens as workload count, variability, and the need for cross-cloud chargeback grow.

Choosing the right tool for your environment

The right category depends on where your team sits on the progression from the introduction, and three questions narrow it down.

Match the tool to team maturity

A team new to rightsizing should start with visibility and accuracy. It’s not enough to surface rightsizing opportunities. Teams need to trust the recommendations a tool provides, and that’s where StormForge’s ML-based engine stands apart from basic tools like the VPA. Teams with established GitOps workflows can feed those trusted recommendations directly into existing deployment pipelines.

Combine tools by layer

Combine tools by layer rather than expecting one tool to cover everything. The layers stack like this:

Layer	Job	Representative tools
Visibility	Attribute spend, find waste	Kubecost, OpenCost, StormForge
Workload rightsizing	Set accurate pod requests	VPA, Goldilocks, StormForge by CloudBolt
Node efficiency	Pack and scale nodes	Karpenter
Governance	Chargeback, budgets, policy	CloudBolt CSMP

Pick one tool per layer and avoid overlap, because two tools optimizing the same dimension will eventually make conflicting decisions, such as one widening requests for safety while another tightens them for cost.

Build automation readiness

Move from recommendation-only to automated application when the conditions are right, not before. Two conditions matter most: 

• Recommendations have been validated against a representative sample of workloads
• PodDisruptionBudget policies are in place to protect availability while specs change. 

Once you know which layer is your current bottleneck, the next decision is which specific product fits it. We have measured StormForge by CloudBolt, Cast AI, Kubecost, and ScaleOps against rightsizing automation, cost visibility, chargeback, governance, and pricing in another article on Kubernetes resource optimization solutions.

Conclusion

No single tool covers the full scope of Kubernetes resource optimization, and the categories align with the challenges teams encounter and in the order they encounter them.

VPA and Goldilocks lower the barrier to getting started but reach practical limits for stateful and variable workloads. Karpenter addresses a different layer and works best alongside workload-level rightsizing. Kubecost gives strong cost attribution but stops short of automated actuation. 

An ML-based platform like StormForge by CloudBolt closes the automation and governance gap, which matters most to teams whose workloads change faster than manual rightsizing can keep pace.

Choose the right tool at each layer and adopt it based on the priority of the challenge you currently face.