Skip to content

Workload Optimization

Workload optimization is the core EcoScale workflow. It combines inventory, resource recommendations, efficiency signals, and cost impact so teams can make high-confidence decisions across large Kubernetes fleets.

This workflow covers standard and GPU-backed workloads under the same prioritization model so teams see all savings opportunities in one place.

EcoScale tracks optimizable workloads through WorkloadScaler resources. A WorkloadScaler connects EcoScale’s recommendation engine to a Kubernetes target workload such as a Deployment, StatefulSet, DaemonSet, Job, CronJob, or custom CRD kind.

The inventory is designed for prioritization. Each workload can include target identity, labels, optimization score, efficiency rate, per-resource scores, recommendation details, and cost impact. Together, those signals show where optimization work should start.

Use WorkloadScaler resources to manage which workloads participate in EcoScale optimization. The resource makes the optimization relationship explicit: it identifies the target workload, declares the optimization scope, and controls whether recommendations remain advisory or become eligible for automation. In many clusters, the agent creates these resources from WorkloadScalerRule discovery rules so teams do not have to hand-author a CR for every workload.

apiVersion: escale.dev/v1alpha1
kind: WorkloadScaler
metadata:
name: payments-api
namespace: payments
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: payments-api
namespace: payments
optimize:
- resource
interval: 1d
resources:
updatePolicy:
updateMode: Preview

This example keeps the workload in preview mode. EcoScale can evaluate the target workload and surface resource recommendations without automatically applying them. For custom operators and custom CRDs, use WorkloadScalerRule.resourceSelectors[*].podNamePattern when the agent creates the WorkloadScaler, or use the targetRef and podSelector fields when managing a WorkloadScaler directly.

Large clusters create large optimization backlogs. Use filters to narrow the view to a namespace, target kind, target name, label set, or cluster. Filtering keeps the conversation aligned with ownership and avoids turning optimization into an unbounded platform-wide task list.

For example, a platform team might filter to production namespaces owned by one business unit, then sort by net impact. An application team might filter by label and review only the services it owns.

SignalHow to use it
Optimization scoreUse lower scores to find workloads with more room for improvement. See Optimization Score.
Efficiency rateUse low efficiency to identify workloads that are likely overallocated. See Efficiency Rate.
Net impactUse projected savings to focus on changes that materially affect cost. See Cost Impact.
Resource scoresUse CPU and memory detail to understand which resource drives the recommendation.

The best candidates combine clear savings, stable behavior, and low operational risk. Start there before moving to critical workloads or large resource reductions.

EcoScale is most valuable when optimization becomes repeatable. Review high-impact workloads, apply safe changes, validate the result, and identify patterns that can be automated across a team or namespace.

The goal is not to tune every workload by hand forever. The goal is to establish a trusted system where manual review is focused on risk and automation handles proven, stable optimization paths.

For large environments, use workload ownership and namespace boundaries to drive the rollout. Start with teams that have clear service ownership, stable applications, and measurable savings. Expand automation only after the review-and-apply loop has produced predictable results.

GPU-intensive workloads should remain review-led. Their scheduling, runtime, and hardware constraints are often more specialized than standard CPU and memory workloads, so use EcoScale’s prioritization signals to decide where deeper operator review is justified.