Goldilocks: Right-Sizing Kubernetes Workloads with the VPA Recommender

The Vertical Pod Autoscaler has a genuinely useful feature that has nothing to do with auto-scaling anything: its recommendation engine. Set a VPA's updateMode to Off and it computes what a workload's CPU/memory requests should be, based on its actual observed usage, without ever touching a running pod. Nothing changes automatically — you just get a number.

The problem is reading that number at scale. A VPA object's recommendation lives in its status field, one object per workload, in raw YAML. Right-sizing 40 deployments means deploying 40 VPA objects and running kubectl describe vpa 40 times. Goldilocks, an open-source tool from Fairwinds, turns that into a dashboard.

How It Works

Goldilocks doesn't reimplement anything — it's a thin, opinionated layer on top of the Vertical Pod Autoscaler that already needs to be installed in your cluster:

1. You label a namespace to opt it in.
2. Goldilocks' controller watches that namespace and creates a VerticalPodAutoscaler object (in updateMode: "Off") for every Deployment, StatefulSet, and DaemonSet it finds.
3. The standard VPA recommender computes requests/limits recommendations the same way it always does — based on historical CPU/memory usage.
4. Goldilocks' dashboard reads those VPA status.recommendation fields and renders them as a table you can actually scan.

Nothing here is a Goldilocks-specific mechanism — it's the same VPA recommender you'd get by deploying the objects yourself. The value is entirely in not having to.

Installation

Requires the Vertical Pod Autoscaler already installed and running in the cluster — Goldilocks doesn't ship its own copy of the recommender.

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm repo update

helm install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks \
  --create-namespace

This installs Goldilocks' controller and dashboard. Expose the dashboard locally to try it out:

kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80

Enabling a Namespace

Goldilocks only acts on namespaces you explicitly label:

kubectl label namespace production goldilocks.fairwinds.com/enabled=true
kubectl label namespace staging goldilocks.fairwinds.com/enabled=true

Once labeled, Goldilocks creates a VPA object for every Deployment, StatefulSet, and DaemonSet already running in that namespace — no restart or redeploy required, since updateMode: "Off" only observes, it never mutates anything.

Give it real traffic time before trusting the numbers — the VPA recommender needs several days of representative usage (including your actual peak load, not just idle baseline) to produce a recommendation worth acting on. Checking it an hour after enabling a namespace will show you whatever the last hour happened to look like, not a real operating range.

Reading the Dashboard

For each workload, the dashboard shows the current request/limit alongside three VPA-computed recommendation tiers:

• Lower bound — the minimum the recommender is confident is safe
• Target — the recommended request value
• Upper bound — a ceiling that accounts for usage spikes

It also flags which QoS class a given recommendation would produce if applied — Guaranteed (requests == limits) versus Burstable — which matters if you're deliberately targeting Guaranteed QoS for latency-sensitive workloads and the recommendation would knock you out of it.

Goldilocks doesn't apply anything. Reading a recommendation and deciding it's wrong for your workload (a batch job with a legitimately bursty CPU profile, say) is a normal, expected outcome — it's advisory, not a policy engine.

What Goldilocks Doesn't Do

It's purely a visualization and object-management layer over VPA recommendations:

• It doesn't apply the recommendations — you still edit the Deployment/StatefulSet manifest yourself, or wire a separate automation to do it.
• It doesn't compute anything the VPA recommender doesn't already compute — there's no additional intelligence, just aggregation and a UI.
• It doesn't help with horizontal scaling — that's HPA's job, a separate concern from per-pod sizing.
• It doesn't work retroactively across a whole cluster instantly — each namespace needs the label, and each workload needs enough observed history before its recommendation is trustworthy.

Frequently Asked Questions

Does labeling a namespace with Goldilocks risk changing my running workloads?

No. Every VPA object Goldilocks creates uses updateMode: "Off", which is purely observational — it computes and reports a recommendation but never evicts or restarts a pod to apply it. That's a hard behavioral guarantee of that VPA mode, not a Goldilocks-specific safety feature layered on top.

Can I use Goldilocks recommendations to set values in a Helm chart's values.yaml?

Yes, and that's the common workflow — read the recommendation from the dashboard, then update your chart's or manifest's resource block manually. Goldilocks doesn't automate that step; it's a research tool, not a GitOps sync target.

How is this different from just running kubectl top pods?

kubectl top shows current, instantaneous usage — a snapshot. The VPA recommender behind Goldilocks analyzes a rolling window of historical usage (via the metrics pipeline it's configured against) and produces a recommendation that accounts for variance over time, not just what's happening right now. For right-sizing, the historical view is what you actually want.

Does Goldilocks work with metrics-server, or does it need Prometheus?

The underlying VPA recommender can run against either metrics-server (the default, lower-resolution) or a Prometheus-backed history provider for more accurate longer-term recommendations. Goldilocks itself doesn't require Prometheus — it works with whatever the VPA recommender in your cluster is already configured to use.

For the underlying autoscaler this tool visualizes, see Kubernetes Vertical Pod Autoscaler. For the manual sizing methodology if you'd rather not stand up another tool, see Kubernetes Resource Management: Requests, Limits, and QoS.

Running dozens of workloads with guessed resource requests? Talk to us at Coding Protocols — we help platform teams right-size clusters without an all-hands manual audit.

Official References

• Goldilocks documentation — installation, dashboard, and configuration
• Kubernetes Vertical Pod Autoscaler — the recommender API Goldilocks builds on