Recommended Free Tools
Goldilocks helps you right-size Kubernetes workloads by displaying recommendations generated by the Vertical Pod Autoscaler (VPA). Start by reviewing those recommendations without applying them; only enable VPA updates after checking workload behavior, disruption tolerance, node capacity, quotas, and Horizontal Pod Autoscaler (HPA) metrics.
How do I set the right CPU and memory requests for Kubernetes workloads?
Use VPA recommendations as evidence about what a workload has consumed—not as values to accept blindly. VPA’s recommender considers historical and current usage to suggest CPU and memory requests. Its recommendations are available in the VPA object’s status, while Goldilocks presents them in a dashboard to help operators find a starting point for requests and limits. Neither tool guarantees a particular cost reduction or that a suggested configuration will fit the cluster.
As an Amazon Associate I earn from qualifying purchases.
VPA can recommend lowering requests for over-requested containers or raising them for under-requested ones. Memory recommendations may also account for observed out-of-memory events. Validate suggestions against peak periods and operational context, including restarts, OOM kills, latency, and scheduling constraints. See the VPA project documentation and Goldilocks project.
How Goldilocks and VPA work together
Goldilocks relies on Kubernetes VPA in recommendation mode. It creates VPA resources for workloads in selected namespaces and displays the resulting recommendations. VPA itself has three relevant components: the recommender calculates suggested requests, the updater can update or evict existing pods depending on its mode, and the admission controller can apply requests when pods are created. The VPA architecture and recommendation status are documented in the VPA documentation.
#1 Best Overall
Goldilocks is therefore a review interface, not a cost-optimization switch. Its recommendations need to be interpreted and then either translated into workload configuration or applied through an explicitly chosen VPA update mode.
A safe workflow for reviewing and applying recommendations
- Install VPA for your cluster. Follow the official VPA installation procedure for the release you intend to run. Pin the deployed version and verify its release-specific modes and feature gates.
- Enable Goldilocks in the namespaces under review. Its recommendation-mode approach creates VPA objects so you can inspect suggestions in the dashboard. Check the Goldilocks repository for current installation instructions. From v4.15.0, the project documents images at
us-docker.pkg.dev/fairwinds-ops/oss/goldilocks; the prior Quay image is deprecated, and image tags are immutable. Use a full version tag or digest. - Compare suggested and current requests. Review CPU and memory recommendations alongside actual workload behavior, peak demand, restart and OOM history, and the largest node the pod could be scheduled onto.
- Keep the first phase observational. Do not enable automatic changes until you understand the recommendations and the application’s tolerance for pod replacement. Review replica capacity and PodDisruptionBudgets before choosing a mode that can evict pods.
- Set boundaries where they make sense. VPA resource policies, container resource policies, LimitRange constraints, and max-allowed settings can shape recommendations. Check the aggregate requests across every container in a pod: individual container caps do not ensure the whole pod will fit on the largest node or within quota.
- Check HPA metrics. Avoid having VPA and HPA control the same CPU or memory resource metric. Using different resource metrics—or custom or external HPA metrics—is the documented alternative.
- Monitor after applying changes. Watch for pending pods, restarts, OOM kills, CPU throttling, and workload latency. Revisit requests if observed behavior indicates that a recommendation is unsuitable.
Choose between observation and automatic updates
| Approach | What happens | Trade-off |
|---|---|---|
| Goldilocks and VPA in recommendation mode | Recommendations are surfaced for review; they are not automatically applied by recommendation mode. | Operators retain control and can account for workload context, but must review and implement changes. |
| VPA update mode | VPA can apply recommendations to newly created pods through admission control and, depending on the mode, update or evict existing pods. | More automation means less manual implementation, but can introduce disruption and scheduling failures. |
Use an explicit VPA update mode rather than relying on assumptions about defaults. The VPA quick start marks Auto deprecated and describes Recreate as the default, including eviction when requests differ significantly from recommendations. Defaults and behavior can change across versions, so consult documentation for the deployed release.
Recreation versus in-place updates
With Recreate, VPA may evict a pod so it can be created again with adjusted requests. Successful replacement is not guaranteed: a new pod can remain pending if the request exceeds node capacity or quota. Before enabling a mode that can recreate pods, confirm the service can tolerate disruption and that remaining replicas can handle demand. Review the VPA quick start and its known limitations.
In-place vertical scaling is conditional, not a universal substitute for recreation. The VPA features documentation says Kubernetes 1.33 or later with the InPlacePodVerticalScaling feature enabled is required; VPA 1.4.0 requires the InPlaceOrRecreate feature gate. Confirm the requirements against the exact Kubernetes and VPA releases in use using the VPA features documentation.
Rank #3
Keep recommendations schedulable
A recommendation that reflects observed demand can still be unusable if the resulting pod cannot be placed. Check whether the sum of requests for all containers fits on the largest eligible node and within namespace or cluster quota. A per-container maximum can limit one container without guaranteeing that a multi-container pod’s combined requests fit. VPA’s documented max-allowed recommender flags and resource policies can help constrain recommendations, but they do not replace a pod-level scheduling check. See the VPA examples, VPA API documentation, and known limitations.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check HPA and admission-webhook interactions
VPA and HPA can conflict when both act on the same CPU or memory metric. Keep them on separate resource metrics, or use a custom or external metric for HPA, as described in the VPA known limitations. Also verify how the VPA admission webhook interacts with other admission webhooks in your cluster; webhook conflicts can affect pod creation.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
