Most Kubernetes clusters run at 8% average CPU utilization and 79% memory overprovisioning. Pod rightsizing tools fix this, but they split into two categories: tools that recommend changes and tools that apply them automatically. This guide compares the four leading options so you can pick the right one for your team and workload profile.
Key takeaways #
- Average CPU utilization across production clusters sits at 8% in 2026, down from 10% in 2025, according to the Cast AI State of Kubernetes Optimization Report measured across tens of thousands of clusters. - CPU overprovisioning affects 69% of clusters (up from 40% year-over-year). Memory overprovisioning hits79%. - Pod rightsizing tools fall into two groups: recommendation-only(Goldilocks, KRR, VPA in Off/Initial mode) and** continuous automation**(Cast AI). - VPA Auto mode evicts pods to apply changes. Fewer than 1% of organizations use it in full Auto mode in production. - OOM kills dropped from 40–50 per hour to near zero across representative Cast AI customer clusters after automated rightsizing. - In-place pod resizing, introduced in Kubernetes 1.33 behind the InPlacePodVerticalScaling feature gate, removes the restart requirement for CPU changes on nodes with cgroup v2. It becomes default-on in Kubernetes 1.35.
- Cast AI is the only tool in this shortlist that applies in-place resizing in production automation today, combining CPU resize (restartless on cgroup v2), HPA awareness, and live migration for stateful workloads into a single continuous workflow.
- 37% of organizations have 50% or more workloads that need rightsizing (Fairwinds data). At that scale, manual recommendations do not keep up.
The Two Approaches to Pod Rightsizing #
Setting Kubernetes requests and limits correctly is one of the highest-leverage infrastructure actions a platform team can take. However, keeping those values accurate is a continuous job, not a one-time task. Workload behavior changes. Traffic patterns shift. Helm chart defaults never get revisited. The result is the 8% CPU utilization number above: clusters running at a fraction of their provisioned capacity, burning real money on idle compute.
Pod rightsizing tools address this problem in two fundamentally different ways.
Recommendation-Only Tools
These tools analyze historical metrics and surface suggested request values. Your team reviews the suggestions and applies changes through normal change management: a PR, a Helm values update, a Kustomize patch. Goldilocks, KRR, and VPA in Off mode all work this way.
The upside is control. Every change goes through a human. The downside is throughput. For a cluster with 50 workloads, a quarterly rightsizing review is manageable. For a cluster with 500, recommendations accumulate faster than teams can act on them. Additionally, recommendations become stale quickly: a static value set in week one may be wrong by week eight when traffic patterns change.
Continuous Automation Tools
These tools observe metrics continuously and apply resource changes without human intervention each cycle. Cast AI’s Workload Autoscaler fits here. The key engineering question is how they apply changes: pod eviction (the VPA Auto approach) or in-place resizing (the Cast AI approach on K8s 1.33+).
In-place resizing matters for production. Eviction-based approaches restart pods, which introduces latency spikes, drains connections, and breaks strict availability requirements. The emergence of in-place resizing in Kubernetes 1.33+ changes the risk calculus for automation significantly. Automation without restarts is a different proposition from automation with eviction.
Note: in-place CPU resizing is restartless. Memory resize is more complex. On cgroup v2 nodes (Linux 4.15+ kernel), memory changes may work in place. On cgroup v1 nodes (still common in managed EKS and older GKE versions), memory resize always requires a pod restart, regardless of resizePolicy. Always verify cgroup version before relying on in-place memory resize. For CPU: in-place resize is reliable from K8s 1.33+ on cgroup v2 nodes.
What to Evaluate #
Before picking a tool, answer these eight questions. Your answers will point you to a clear shortlist.
Evaluation Criteria
Scale: How many workloads need rightsizing? Below 50, recommendations are manageable. Above 50, automation is required to keep pace with drift.HPA compatibility: VPA Auto mode conflicts with HPA when HPA scales on CPU or memory metrics. However, VPA and HPA can coexist if VPA is scoped to memory-only recommendations while HPA handles CPU scaling, or when HPA uses custom metrics (not CPU or memory). If you run HPA on CPU or memory, VPA Auto is off the table without careful resource scoping.Workload type: Stateless workloads tolerate restarts better. Stateful services with persistent connections or long-running jobs need in-place resizing or live migration to avoid disruption.Observability stack: KRR requires Prometheus (or Thanos, Mimir, VictoriaMetrics). Goldilocks requires VPA to be installed. Cast AI brings its own metrics pipeline and requires no specific observability setup.Change frequency: A static recommendation goes stale by day 90 in most clusters. If you cannot run the tool and act on results weekly, you need a tool that does it for you.In-place resizing: In-place pod resizing, introduced in Kubernetes 1.33 behind the InPlacePodVerticalScaling feature gate, removes the restart requirement for CPU changes on nodes with cgroup v2. It becomes default-on in Kubernetes 1.35. Note: managed Kubernetes services (EKS, GKE, AKS) typically lag 1–2 minor versions behind the upstream release. Cast AI supports this in production automation today. VPA added experimental InPlace mode in version 1.7.0, but it remains in alpha and not production-ready. Cast AI is the only tool in this shortlist that applies in-place resizing in production automation today, combining CPU resize (restartless on cgroup v2), HPA awareness, and live migration for stateful workloads into a single continuous workflow.Kubernetes version: In-place resizing reaches GA in K8s 1.35. Verify your cluster version before factoring this into your decision.True TCO: Open-source tools cost engineering time to maintain, schedule, and act on. Commercial tools cost a subscription. Factor both honestly.
Decision Matrix
Use this table to map your team profile to the right starting point.
| Team Profile | Recommended Starting Point |
|---|---|
| New to rightsizing, fewer than 30 workloads, strict change management | Goldilocks |
| Running Prometheus, GitOps workflow, multi-cluster, human approval required | KRR |
| Stateless workloads, no HPA, acceptable restart window, dev/staging focus | VPA (Off or Initial mode) |
| More than 50 workloads, HPA in use, stateful services, OOM kill problem, compound savings needed | Cast AI Workload Autoscaler |
| Open-source only requirement, any scale | KRR (most flexible) or VPA Off mode |
The Shortlist #
Below are the four tools that cover the full spectrum of rightsizing approaches. Each includes a comparison of approach, license, dependencies, HPA safety, and automation level.
Comparison Table
| Tool | Approach | License | VPA Required | HPA Safe | Automation Level |
|---|---|---|---|---|---|
| Goldilocks | Recommendation-only | Open source | Yes | Yes (read-only) | None |
| KRR | Recommendation-only | MIT | No | Yes (read-only) | None |
| VPA | Recommendation + optional automation | Open source | N/A (is VPA) | No (Auto mode conflicts) | Optional (eviction-based) |
| Cast AI | Continuous automation | Commercial | No | Yes (HPA-aware) | Full (in-place resizing) |
- Goldilocks (Fairwinds)
Category: Recommendation-only | License: Open source | GitHub
Goldilocks creates a VPA object in recommendation mode for each workload in labeled namespaces. It then queries those VPA objects and surfaces results in a visual dashboard. Goldilocks surfaces recommendations as two QoS classes: Guaranteed mode (requests = limits, highest priority) and Burstable mode (requests < limits, more flexible). It does not apply any changes. No changes go to your cluster without your explicit action.
When to use it: You are new to rightsizing and want a visual, zero-risk starting point. Your organization requires human approval for resource changes. You are working through a staging environment before touching production.
Key limitations: Goldilocks requires VPA installed in your cluster. Recommendations use VPA’s default observation window, which can be short. There is no HPA conflict detection, no cost attribution, and no automated application of changes. At hundreds of services, the manual workflow does not scale.
- KRR (Robusta Kubernetes Resource Recommender)
Category: Recommendation-only | License: MIT | GitHub
KRR is a Python CLI that queries Prometheus (or Thanos, Mimir, VictoriaMetrics) using PromQL. It calculates CPU recommendations at p95 and memory recommendations at max plus a configurable buffer. The tool does not write anything back to the cluster. Instead, it outputs recommendations you can pipe into a GitOps PR workflow.
krr simple --prometheus-url http://prometheus:9090 --namespace production
krr simple --prometheus-url http://prometheus:9090 --namespace production --output json
When to use it: You run Prometheus and want a no-VPA-required tool. You want recommendations that feed a GitOps pull request workflow. Your team spans multiple clusters and needs a portable CLI.
Key limitations: KRR is recommendation-only, so you must schedule recurring runs and act on results. It requires Prometheus. It also has no seasonality modeling, which means weekly or monthly traffic spikes may not reflect in its baseline recommendations if your observation window is too short.
- Kubernetes VPA (Vertical Pod Autoscaler)
Category: Recommendation + optional automation | License: Open source | GitHub
VPA is the native Kubernetes controller for vertical scaling. It has three components: the Recommender (builds histograms from historical data), the Updater (evicts pods when values drift from recommendations), and the Admission Controller (sets requests at pod creation time). Three modes control behavior: Off (recommendations only), Initial (apply at creation, no eviction), and Auto (continuous eviction-based updates).
When to use it: Off mode works safely for any workload as a recommendation source. Initial mode suits stateless workloads where restart at deploy time is acceptable. VPA is also the backing engine that Goldilocks depends on.
Key limitations: VPA Auto evicts pods to apply changes-fewer than 1% of organizations run it in full Auto mode in production. VPA Auto mode conflicts with HPA when HPA scales on CPU or memory metrics. However, VPA and HPA can coexist if VPA is scoped to memory-only recommendations while HPA handles CPU scaling, or when HPA uses custom metrics (not CPU or memory).
If you run HPA on CPU or memory, VPA Auto is off the table without careful resource scoping. VPA 1.7.0 added an experimental InPlace mode for in-place resizing, but it is in alpha and not production-ready. VPA Auto mode can issue concurrent eviction requests across multiple pods. Each individual request passes the PDB check, but the overlap can collectively violate your PDB’s maxUnavailable intent. For applications with strict availability requirements, either use minReplicas in PDB carefully, or choose a tool that supports live migration rather than eviction. At scale, the operational overhead of managing VPA objects per workload adds up.
- Cast AI Workload Autoscaler (PrecisionPack)
Category: Continuous automation | License: Commercial | Cast.AI
Cast AI is the only tool in this shortlist that combines fully automated rightsizing with in-place pod resizing (on K8s 1.33+), HPA awareness, and compound node savings through PrecisionPack bin-packing. It deploys an agent that analyzes metrics continuously and applies resource changes without pod restarts for CPU on supported cluster versions.
Note: in-place CPU resizing is restartless. Memory resize is more complex. On cgroup v2 nodes (Linux 4.15+ kernel), memory changes may work in place. On cgroup v1 nodes (still common in managed EKS and older GKE versions), memory resize always requires a pod restart, regardless of resizePolicy. Always verify cgroup version before relying on in-place memory resize. For CPU: in-place resize is reliable from K8s 1.33+ on cgroup v2 nodes.
For stateful workloads, Cast AI offers Live Migration rather than eviction. The OpsPilot feature walks through three configuration questions (workload type, risk tolerance, target namespace) and auto-generates a rightsizing policy. Teams running Prometheus or Cast AI’s built-in metrics agent typically see first recommendations within the first few hours of deployment. PrecisionPack then bin-packs workloads onto fewer nodes after pod rightsizing, compounding the savings beyond what pod-level changes alone produce.
When to use it: You want automation rather than recommendations. You run HPA alongside workloads that also need vertical scaling. Your stateful services cannot tolerate eviction. You operate across multiple clusters on EKS, GKE, or AKS. You have an active OOM kill problem.
Key limitations: Cast AI is a commercial product with pricing that requires a conversation with their team. It requires deploying an agent into your cluster, which introduces a third-party dependency. For a single small cluster with a small team happy to manage manual changes, the open-source options are sufficient.
How to Run a Trial #
A two-week staged evaluation gives you enough signal without committing to production automation on day one. The sequence below works for any of the four tools, with notes on where the workflow differs.
Week One: Baseline and Recommendations
Day 1-2: Capture your baseline. Before touching anything, record current CPU and memory utilization against requests. These commands give you the starting picture:
kubectl top pod -n <namespace> --containers
kubectl get events --all-namespaces | grep OOMKilled
sum(rate(container_cpu_cfs_throttled_periods_total[5m])) by (pod, container) /
sum(rate(container_cpu_cfs_periods_total[5m])) by (pod, container)
Day 3-5: Run your chosen tool in recommendation mode. For KRR, run against a two-week Prometheus window to catch weekly traffic patterns. When using Goldilocks, install via Helm and label one non-critical namespace. For VPA, use Off mode across the same namespace. For Cast AI, the agent starts producing recommendations within hours of deployment.
quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{container!=''}[5m])[2w:5m])
by (namespace, pod, container)
quantile_over_time(0.99, container_memory_working_set_bytes{container!=''}[2w:5m])
by (namespace, pod, container)
Week Two: Staged Apply and Measurement
Day 8-10: Apply to a staging or low-risk namespace first. Use the recommended target values (not upper bounds) for CPU. For memory, apply max-plus-buffer to avoid OOM kills. Verify throttling does not increase after the change.
Day 11-14: Measure and gate for production. Compare OOM kill events before and after. Check throttling ratios. Confirm latency metrics are stable. If all three are green, the values are suitable for production rollout.
Rollback plan: Before applying any recommendation, note the current resource values (kubectl get pod <name> -o jsonpath='{.spec.containers[*].resources}'
). If you observe latency regression, throttling increase, or OOM events after rightsizing, roll back by updating your Helm values.yaml or Kustomize overlay with the prior values and reapplying. Update version control to prevent the next CI/CD run from re-applying the changed values.
For teams evaluating Cast AI specifically, the trial path is shorter. The agent handles the baseline, recommendation, and application loop automatically. Therefore, your evaluation focuses on confirming that the policies it generates match your risk tolerance, rather than building the workflow yourself.
For a deeper look at what automated workload rightsizing looks like in production, see the Cast AI guide on automated workload rightsizing.
Conclusion #
The choice between pod rightsizing tools is really a choice between advice and action. Goldilocks and KRR give you a solid visual and CLI-based view into what your cluster should look like. VPA extends that to optional automation, with real caveats around eviction and HPA compatibility. Cast AI closes the loop with continuous, in-place automation that compounds savings at the node level through PrecisionPack.
If you manage fewer than 50 workloads and your team has the capacity to act on recommendations regularly, start with KRR or Goldilocks. Also consider whether your Kubernetes version supports in-place resizing before deciding automation is too risky.
If you run HPA, manage stateful services, operate at scale, or simply want the drift problem solved without a recurring manual workflow, automated workload rightsizing is the better path. The 8% average CPU utilization across production clusters is not a fixed constant. It is the baseline before optimization runs.
For a broader view of where rightsizing fits in a full optimization program, see the roundup of best Kubernetes cost optimization tools.
Frequently Asked Questions #
What tools rightsize Kubernetes pods? The main Kubernetes pod rightsizing tools in 2026 are Goldilocks, KRR (Robusta Kubernetes Resource Recommender), Kubernetes VPA, and Cast AI Workload Autoscaler. Goldilocks and KRR are recommendation-only: they surface suggestions your team must apply manually. VPA adds optional automation via pod eviction, but fewer than 1% of organizations use VPA Auto in production. Cast AI is the only tool that combines fully automated rightsizing with in-place resizing (no pod restarts for CPU on K8s 1.33+) and HPA-aware automation.
What is the difference between recommendation-only and automated rightsizing? Recommendation-only tools analyze historical metrics and surface suggested resource values. Your team reviews and applies the changes through a normal change process such as a PR or Helm update. Automation tools apply resource changes continuously without requiring a human in the loop each cycle. Recommendation tools suit teams with strict change management requirements or fewer than 50 workloads. Automation tools scale better and handle drift automatically. VPA Auto applies changes via pod eviction, which restarts pods. Cast AI applies CPU changes in place (without restarts on K8s 1.33+); memory resize is more complex: on cgroup v2 nodes it may work in place, but on cgroup v1 nodes (still common in managed EKS and older GKE versions) a pod restart is always required regardless of resizePolicy. For stateful workloads, Cast AI uses Live Migration rather than eviction, avoiding the disruption that makes VPA Auto impractical for most production environments.