Workload-level settings

Review the complete list of workload optimization settings and their descriptions

The purpose of this topic is to list and describe the supported optimization configuration settings that apply to workloads. For settings that apply to individual containers within a workload, see the Container-level settings topic.

Workload-level settings:

For details about how to set these values using annotations, see the Configure namespaces or Configure workloads topic.

Workload-level settings syntax

When specifying configuration values for workload settings, you can specify one value only, which applies to the workload as a whole.

Annotation examples "@daily" "true"

Workload settings

The following settings specify single values for the whole workload.


The schedule on which Optimize Live generates new recommendations for a workload.

Annotation Default value "@daily"

Recommendations are generated automatically for workloads on a schedule, defined by a schedule string.

The schedule also affects every recommendation’s TTL, or time-to-live. The TTL is how long the recommended values are considered valid for. After a recommendation’s TTL expires, the recommended values are replaced by new values from an updated recommendation.

The shortest valid recommendation schedule is once an hour.

Duration expressions

Valid ISO 8601 Duration strings can be specified as schedules.

  • PT1H – Once an hour
  • P1D – Once a day
  • P7D – Once a week
Cron expressions

Cron strings can be used to designate schedules with more specific requirements, such as day-of-week. Cron expressions should specify five fields. For day-of-week, friendly terms such as WED or THU are acceptable in place of numbers. Optimize Live recognizes the special value H in a field to mean “hash” this value, and use a deterministic, but functionally random value for that field.

Cron times must always be specified in UTC.

  • H H * * THU – Once every Thursday
  • 0 30 * * SAT,MON – 12:30am each Saturday and each Monday UTC
  • H H(0-2) * * * – Every day between 12:00am and 2:59am UTC
Schedule macros

Macros are shorthand that can be used as syntactic sugar for common schedules. The available macros are described below and compared with their duration and cron equivalents.

Macro Duration Cron Description
@never P0D N/A Do not generate recommendations at all.
@hourly PT1H H * * * * Once every hour.
@daily P1D H H * * * Once every day.
@weekly P7D H H * * H Once every week.
@midnight N/A H H(0-2) * * * Every day between 12:00am and 2:59am UTC
Key points
  • Each workload can have one and only one schedule string defined for it, of either a duration, cron expression, or schedule macro.
  • Exact times are not guaranteed for recommendation generation. For exact cron strings, recommendations are generated within an hour of the time specified.
  • To avoid concentrated pod churn when new recommendations are applied, use schedules that spread optimization over a period of time. The H capability in cron expressions or using non-specific durations can both help achieve an appropriate scheduling distribution.


Whether or not to automatically apply new recommended settings when they are produced on a schedule.

Annotation Default value "false"

When auto-deploy is enabled ("true"), Optimize Live automatically applies new recommended settings when they are produced on the configured schedule.

The Applier must be installed in order for recommendations to be applied automatically. Other settings, such as auto-deploy thresholds, are in effect only when auto-deploy is enabled.

Auto-deploy thresholds

Optional. Prevent Optimize Live from automatically applying low-impact recommendations by defining the minimum amount of change required between current and recommended values.

Annotation Default value None None None None

Auto-deploy thresholds are a constraint that can prevent automatic deployment of recommendations generated on a schedule. If a threshold is configured, the amount of change between the new recommended values and the values currently applied to the workload must meet the defined minimum for the recommendation to be automatically deployed.

Percent thresholds

To use percent thresholds, specify a percent value for both CPU and for memory. The threshold is met if the amount of change for either resource exceeds the configured minimum percent.

Valid values

Any positive integer string. Examples:

  • "5"
  • "10"
Unit thresholds

To use unit thresholds, specify a unit value for both CPU and for memory. The threshold is met if the amount of change for either resource exceeds the configured minimum unit value.

Valid values

Any positive Kubernetes quantity, appropriate to the resource. Examples:

  • "10m" (for CPU)
  • "64Mi" (for memory)
Key points
  • Thresholds have no effect unless auto-deploy is set to "true".
  • If, for at least one container, the recommendation satisfies the thresholds for at least one resource — as in, CPU (unit AND percent threshold) OR memory (unit AND percent threshold) — the recommendation will be applied automatically.
  • It is highly recommended to set percent and unit thresholds. If you set a percent threshold only, small unit changes for small containers can be a large enough percentage to meet the percent threshold, thus deploying the recommendation. Setting percent and unit thresholds ensures small changes don’t trigger a deployment.
  • To disable thresholds, set them to "0".

Optimization goal

Used in determining recommended values based on your goals and risk tolerance.

Annotation Default value "Balanced" "Balanced"

The optimization goal for a resource indicates which of two competing criteria to maximize when computing recommended request values: cost savings or workload reliability. Optimize Live will always produce values that minimally satisfy both criteria, but the goal setting can be used to shift the balance in favor of one or the other.

Valid values
  • Balanced (default): Provides a balanced approach to achieving cost savings and workload reliability.
  • Savings: Provides recommendations that are closer to actual CPU or memory usage. Consider this option when you want to maximize your resource savings.
  • Reliability: Minimizes the risk of usage bursting over request values or hitting CPU or memory limits. Consider this option for business-critical applications.
Key points
  • CPU and memory optimization goals can differ. For example, if your organization can tolerate throttling when containers exceed CPU limits but cannot tolerate restarts when containers exceed memory limits, you can set a Savings goal for CPU and a Reliability goal for memory.

HPA target utilization

Specifies the lower bound and upper bound of the range within which Optimize Live can set HPA target utilization.

Annotation Default value None None None None

HPA target utilization min and max are constraints that prevent Optimize Live from recommending HPA target utilization values outside of the defined bounds. The target utilization constraints are specified separately for CPU and for memory. These settings have an effect only if an HPA is enabled for a workload, and only if the HPA scales on CPU or scales on memory.

Valid values
  • Integer strings from "0" to "100"
Last modified May 15, 2024