Apply Settings

Enable automatic deployment, set optional thresholds to skip low-impact recommendations, and choose a patch or admission webhook apply method

You can define how Optimize Live deploys the complete recommendations that are generated when the workload’s learning period is over.

Apply settings:

Deploy recommendations automatically

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

Annotation Default value
live.stormforge.io/auto-deploy "false"
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: "true" or "enabled"
  • To disable auto-deploy: "false" or "disabled"
Settings that require auto-deploy

The following settings 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
live.stormforge.io/auto-deploy.thresholds.cpu.percent None
live.stormforge.io/auto-deploy.thresholds.memory.percent None
live.stormforge.io/auto-deploy.thresholds.cpu.unit None
live.stormforge.io/auto-deploy.thresholds.memory.unit None
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

Apply method

Defines how the Optimize Live Applier applies recommendations to a workload.

Annotation Default value
live.stormforge.io/apply.method "PatchWorkloadResources"
Description

By default, Optimize Live uses server-side patches to directly modify Deployments, StatefulSets, and other Pod-owning workload resources.

You can choose to configure Optimize Live to use a mutating admission webhook to modify Pods when they are created. After Optimize Live applies a recommendation, the Applier triggers a rollout or restart of the pods, which are re-created with the recommended requests and limits values. You might choose the webhook method if you use third-party tools to monitor for configuration drift or have many custom resources.

You can set the default apply method at the cluster, namespace, or workload level. For example, you might choose to enable the webhook method on a subset of workloads for testing before enabling it for an entire cluster.

At times, the pod and workload might show different recommended values. For example:

  • When changing a workload’s apply method, the recommended values on the deployment might be out of sync with the recommended values in the pods until the next recommendation is applied.
  • In a CI environment, StormForge-recommended values are shown on the pod and the developer-supplied values from Git are shown on the Deployment.
Key points:
  • Continuous reconciliation (if enabled on the Applier) does not occur on workloads that are configured to use the webhook apply method.

  • If a workload’s apply method is set to DynamicAdmissionWebhook, you can still apply recommendations manually as a Deployment patch. The patch is avaiable on the Patches tab of the workload details page.

  • If a workload’s apply method is set to DynamicAdmissionWebhook but the webhook.allowlist or webhook.denylist restricts the namespace or if the feature is not enabled on the Applier, recommendations are still generated on the configured schedule but the Applier cannot apply them.

    When this scenario occurs, the UI or command line output shows different request and limits values than those on the pod. The Applier updates the workload to indicate what the recommended values are; however, the pods are not updated with the recommended values.

Valid values

One of the following enums:

  • "PatchWorkloadResources" (default): Use server-side apply patches to modify Deployments, StatefulSets, and other Pod-owning workload resources directly.
  • "DynamicAdmissionWebhook": Use a mutating admission webhook to insert resources into the Pods when they are created after rollout/restart.
Last modified November 20, 2024