Recommendations

EcoScale recommendations are based on observed workload behavior and the policies configured for the workload. They show what should change, why the change matters, and whether the workload is ready for manual apply or eventual automation.

A recommendation is not merely an output value. It is the basis for a controlled operational decision that should balance savings, performance, and reliability.

What you see in the dashboard: current and recommended requests with the resource delta.

Current vs recommended: CPU reduced from 500m to 350m, memory from 512Mi to 384Mi.

Resource Recommendations

EcoScale resource recommendations focus on CPU and memory requests and limits. Requests influence scheduling and cost allocation. Limits shape runtime behavior and can affect performance or stability when configured too tightly.

For multi-container workloads, review recommendations per container. One container might be oversized while another needs more headroom, and a safe change depends on understanding that distinction.

apiVersion: escale.dev/v1alpha1
kind: WorkloadScaler
metadata:
  name: checkout-worker
  namespace: commerce
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-worker
    namespace: commerce
  optimize:
    - resource
  resources:
    resourcePolicy:
      containerPolicies:
        - name: worker
          cpu:
            scalingGoal: Balanced
            scalingPolicy: RequestsOnly
          memory:
            scalingGoal: Balanced
            scalingPolicy: RequestsAndLimits

This policy allows EcoScale to recommend CPU request changes while allowing both memory requests and limits to be evaluated. It is a practical pattern when CPU limits are sensitive but memory limits still need active management.

Scaling Goals

Scaling goals tune how conservative or savings-oriented EcoScale should be when computing recommendations. Balanced is the default for both CPU and memory.

Goal	CPU behavior	Memory behavior	Best fit
Aggressive	Uses the lowest target percentile, minimal buffer, and the largest downscale allowance.	Still guarded, but permits more reduction than the other memory goals.	High-confidence workloads where the team is intentionally pursuing stronger savings.
Savings	Uses a cost-leaning target with a modest buffer.	Cost-aware, with more memory protection than Aggressive.	Stable workloads where savings are important and behavior is well understood.
Balanced	Uses the default CPU posture with moderate buffer.	Uses the default memory posture with conservative p99-style behavior.	Most production workloads where efficiency and reliability both matter.
Performance	Uses the highest headroom and the smallest downscale allowance.	Uses the highest memory headroom and the smallest downscale allowance.	Critical, latency-sensitive, or reliability-sensitive workloads.

Lowest buffer Modest buffer Moderate buffer Highest buffer

Scaling goals represent a deliberate trade-off: lower buffers drive stronger savings; higher buffers protect performance.

The scaling goal instructs the recommendation engine to adjust its internal thresholds — target percentile, safety margin, history window, and maximum downscale — so the same workload behavior produces different recommendations depending on the chosen goal. A production service handling customer traffic should use a more conservative goal than a batch workload with flexible runtime requirements.

Scaling Policies

Policy	Behavior
Off	Suppresses recommendations for that resource.
RequestsOnly	Recommends requests. Limits are recommended only when a current limit is already set.
RequestsAndLimits	Recommends both requests and limits.

Policy is how teams encode operational tolerance. CPU defaults to RequestsOnly, which is a safer starting point for workloads that may be sensitive to CPU throttling. Memory defaults to RequestsAndLimits, which helps EcoScale manage both scheduling posture and memory ceilings when the workload has enough history.

For workload-level defaults and guardrail fields, see WorkloadScaler CRD.

Initial Recommendations

When a workload is first discovered and doesn’t yet have enough metric history, EcoScale generates an initial recommendation from the best data available. These recommendations are marked as preliminary — they will be refined automatically as more metrics accumulate.

Initial recommendations use the same scaling goal and policy as stable recommendations, but the underlying data is still accumulating. Treat them as early guidance rather than final decisions.

Wait for the recommendation to stabilize — meaning the metric history window is sufficiently covered — before applying high-impact changes or enabling automation. Stable recommendations typically require around two weeks of observed metric history, depending on the scaling goal. Once stable, they reflect the workload’s actual behavior under the chosen scaling goal and are ready for review and eventual automation.

Recommendations progress from initial to stable, then through manual application to trusted automation.

Reviewing A Recommendation

Review the workload identity first, then the resource delta. Confirm the cluster, namespace, target workload, and container before evaluating the numbers. Large reductions deserve extra attention, especially for memory, where underallocation can lead to OOM kills.

Generate And Refresh Recommendations

EcoScale automatically regenerates recommendations on the cadence defined by spec.interval. As new metrics accumulate, the recommendation engine recomputes resource values and refreshes the recommendation state — no operator intervention required.

If you need a recommendation refreshed outside the normal interval — for example, after a major release, a traffic shift, or a policy change — trigger a regeneration from the EcoScale dashboard. The platform recomputes the recommendation immediately against the latest observed data.

For stable workloads, the automatic refresh cycle means operators can focus on exceptions. Review recommendations when they change materially, and let the platform handle the routine updates.