Apply settings

Define how Optimize Live deploys generated recommendations.

Apply settings:

• Auto-deploy
• Learning period
• Auto-deploy thresholds
• Apply method
• Incremental rollout

Deploy recommendations automatically

These settings define whether Optimize Live deploys new recommendations automatically.

Auto-deploy

When "true", Optimize Live automatically applies new recommendations when they are generated on the configured schedule.

Description

When auto-deploy is enabled (see Examples below), Optimize Live automatically applies new recommended settings when they are generated on the configured schedule.

The Applier must be installed in order for recommendations to be applied automatically.

Examples

• To enable auto-deploy: "Enabled"
• To disable auto-deploy: "Disabled"

Settings that require auto-deploy

The following settings are in effect only when auto-deploy is enabled:

• Auto-deploy thresholds
• Continuous reconciliation
• OOM events response

Learning period

Acts as an automation gate, defining how long Optimize Live observes a new workload before providing recommendations that can be auto-deployed.

Description

During this observation or learning period, Optimize Live generates preliminary recommendations based on the metrics it has collected. Preliminary recommendations are not auto-deployed, but they can be applied on demand.

If you want to automatically deploy recommendations sooner-for example, for short-running workloads, branch-based deploys, or other ephemeral environments-you can shorten the learning period. Otherwise, it typically isn’t necessary to change this value.

The shortest valid duration is one day (P1D).

Recommendations generated after the learning period is complete are deployed automatically if auto-deploy is enabled.

Duration expressions

Only valid ISO 8601 Duration strings can be specified.

Examples

• “P1D” – One day (minimum value)
• “P3D” – Three days
• “P7D” – One week (default)

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.

Description

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 the live.stormforge.io/auto-deploy annotation 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".

General apply options

These settings define how Optimize Live applies recommendations, regardless of whether auto-deploy is enabled.

Apply method

Defines how the Applier applies recommendations to a workload, and what happens to running Pods.

Description

When a recommendation is applied, the apply method controls:

• How the Applier communicates resource changes to Kubernetes
• What happens to running Pods

By default, Optimize Live uses Server-Side Apply patches (with PatchImmediateRollout) to directly modify Deployments, StatefulSets, and other Pod-owning workload resources.

Alternatively, you can configure Optimize Live to use a mutating admission webhook (with WebhookImmediateRollout, WebhookHybridRollout, or WebhookDeferredRollout) to modify Pods at admission.

WebhookImmediateRollout and WebhookHybridRollout support in-place Pod resizing, a Kubernetes feature (enabled by default from Kubernetes v1.33) that allows resource requests and limits to be updated on running Pods without a restart.

If Pods can’t be resized in-place (for example, on clusters running earlier Kubernetes versions), the supporting methods either trigger a rollout/restart or defer changes until the workload restarts by itself. See Choosing an apply method for details.

PatchImmediateRollout always triggers a rollout, and WebhookDeferredRollout always defers changes until the next restart.

Depending on the configured apply method and the cluster’s Kubernetes version, applying a recommendation may result in:

• Pods being resized in-place
• A rollout/restart being triggered
• Changes being deferred until the next rollout or restart

You can configure the apply method at the cluster, namespace, or workload level.

Valid values

PatchImmediateRollout (default)

Use Server-Side Apply patches to modify Deployments, StatefulSets, and other Pod-owning workload resources directly when a recommendation is applied.

This is the default apply method.

WebhookImmediateRollout

Use a mutating webhook to modify Pods at admission. Pods are resized in-place when a recommendation is applied. If Pods can’t be resized in-place, a rollout/restart is triggered.

WebhookHybridRollout

Use a mutating webhook to modify Pods at admission. Pods are resized in-place when a recommendation is applied. If Pods can’t be resized in place, changes are deferred until the next rollout.

WebhookDeferredRollout

Use a mutating webhook to modify Pods at admission. Pods aren’t modified and the workload doesn’t restart when a recommendation is applied. Changes are deferred until the next restart.

Choosing an apply method

Incremental rollout

Incremental rollout lets you configure Optimize Live to apply changes to resource settings gradually over time, rather than all at once.

Description

Optimize Live normally applies its rightsizing recommendations in full, regardless of how much larger than or smaller than current values they are.

Incremental rollout, controlled with max percent increase and max percent decrease options, allows users to restrict the magnitude of individual changes Optimize Live applies. This results in Optimize Live applying a series of incremental changes to workloads that eventually converge them with their optimal values, rather than applying a single large change.

The allowed percent increase or percent decrease is based on the workload’s current request values. For example, if a workload currently has a CPU request of 100m, Optimize Live is recommending a CPU request of 50m, but the max-percent-decrease is set to "20", Optimize Live will apply the following changes over time:

• Change 1: From 100m to 80m (reducing 100m by 20%)
• Change 2: From 80m to 64m (reducing 80m by 20%)
• Change 3: From 64m to 52m (reducing 64m by 20%)
• Change 4: From 52m to 50m (reaching the final recommended CPU request)

When each change is applied depends on the workload’s schedule. If the schedule is @daily, the recommendation will be applied incrementally over 4 days.

Examples

• To let Optimize Live always apply recommendations in full:

  # Don't configure either of these settings.
  

• To let Optimize Live always increase requests by its full recommended amount, but limit any reduction of requests to 20% at a time:

  live.stormforge.io/apply.max-percent-decrease: "20"
  

• To prevent Optimize Live from raising request values at all:

  live.stormforge.io/apply.max-percent-increase: "0"