Automation

Automation lets EcoScale apply trusted resource recommendations without requiring manual review of every change.

Automation Scope

For selected workloads, operators enable automation by turning on apply mode in the dashboard or by setting updateMode: Auto in the WorkloadScaler spec.

The decision to automate should be intentional. A workload should earn automation through stable behavior, reliable metrics, and a history of recommendations that operators would have accepted manually.

Automation settings determine when EcoScale can move from recommendation to action. Use preview mode while recommendations are still stabilizing, the workload is changing frequently, or the setup is still being validated. Use automatic updates only when the recommendation stream has become trustworthy.

apiVersion: escale.dev/v1alpha1
kind: WorkloadScaler
metadata:
  name: catalog-api
  namespace: retail
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catalog-api
    namespace: retail
  optimize:
    - resource
  interval: 1d
  resources:
    updatePolicy:
      updateMode: Auto
    resourcePolicy:
      containerPolicies:
        - name: api
          cpu:
            scalingGoal: Balanced
            scalingPolicy: RequestsOnly
          memory:
            scalingGoal: Balanced
            scalingPolicy: RequestsAndLimits

Use Auto only for workloads where your team has established confidence. For new workloads, critical services, or volatile traffic patterns, keep updateMode: Preview until the recommendation history is proven.

This example shows the minimum automation shape. Production policies usually add request and limit bounds, metric thresholds, limit-to-request ratios, and eviction requirements. See WorkloadScaler CRD for the full field guide, including update policy and requests and limits guardrails.

updateMode: Auto controls workload-level resource automation policy, but the connected cluster agent must also be installed with apply-capable permissions before EcoScale can patch target workloads. Use Scaling Goals and Scaling Policies to tune recommendation behavior before promoting a workload to automation.

Good Automation Candidates

Strong candidates have stable traffic, strong metric history, clear ownership, and repeated recommendations that operators have already accepted manually. These workloads allow EcoScale to save cost continuously while keeping performance within expected boundaries.

Non-critical services and stable internal workloads are often good starting points. They help teams validate the automation model before expanding to broader namespaces or production-critical systems.

Poor Automation Candidates

Avoid automation when a workload has incomplete metric history, volatile resource usage, recent reliability incidents, or unclear ownership. Large resource deltas also deserve manual review because they can indicate either a major savings opportunity or a workload that needs deeper investigation.

Automation should never be used to bypass operational judgment. It should reduce repetitive safe work, not hide risk.

Rollout Pattern

Start in preview mode, apply several recommendations manually, and verify the outcome. When a workload consistently produces stable recommendations your team would accept, enable automation for that workload or a narrow namespace. Review periodically and expand only when the results support it.

GPU-intensive workloads should be treated as high-review candidates. Use EcoScale to surface cost and utilization opportunities, but keep accelerator-specific changes deliberate because GPU workloads often depend on specialized runtime behavior, scheduling policy, and hardware configuration.