RecommendationsApply recommendations
Apply recommendations using the method that suits your environment
Define how StormForge deploys generated recommendations.
Apply settings:
These settings define whether StormForge deploys new recommendations automatically.
When "true", StormForge automatically applies new recommendations when they are generated on the configured schedule.
| Annotation | Default value |
|---|---|
live.stormforge.io/auto-deploy |
"Disabled" |
When auto-deploy is enabled (see Examples below), StormForge 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.
"Enabled""Disabled"The following settings are in effect only when auto-deploy is enabled:
Acts as an automation gate, defining how long StormForge observes a new workload before providing recommendations that can be auto-deployed.
| Annotation | Default value |
|---|---|
live.stormforge.io/learning-period |
"P7D" |
During this observation or learning period, StormForge 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.
Only valid ISO 8601 Duration strings can be specified.
P1D” – One day (minimum value)P3D” – Three daysP7D” – One week (default)Optional. Prevent StormForge 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 |
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.
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.
Any positive integer string. Examples:
"5""10"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.
Any positive Kubernetes quantity, appropriate to the resource. Examples:
"10m" (for CPU)"64Mi" (for memory)live.stormforge.io/auto-deploy annotation is set to "true"."0".These settings define how StormForge applies recommendations, regardless of whether auto-deploy is enabled.
Defines how the Applier applies recommendations to a workload, and what happens to running Pods.
| Annotation | Default value |
|---|---|
live.stormforge.io/apply.method |
"PatchImmediateRollout" |
When a recommendation is applied, the apply method controls:
By default, StormForge uses Server-Side Apply patches (with PatchImmediateRollout) to directly modify Deployments, StatefulSets, and other Pod-owning workload resources.
Alternatively, you can configure StormForge 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:
You can configure the apply method at the cluster, namespace, or workload level.
webhook.enabled=true on the Applier. If the webhook feature isn’t enabled, recommendations are still generated, but can’t be applied. See Using a webhook-based apply method for details.webhook.denyNamespaces list.ignoreDifferences element for HPA objects in the argocd-cm ConfigMap. See the How to use StormForge and Argo CD together guide for details.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.
WebhookImmediateRolloutUse 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.
WebhookHybridRolloutUse 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.
WebhookDeferredRolloutUse 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.
| Apply method | Mechanism | In-place resize | If Pods can’t be resized in-place |
|---|---|---|---|
PatchImmediateRollout |
Patch workload resources | No | N/A |
WebhookImmediateRollout |
In-place Pod resizing, mutating webhook | Yes | Rollout/restart triggered |
WebhookHybridRollout |
In-place Pod resizing, mutating webhook | Yes | Changes deferred until the next restart |
WebhookDeferredRollout |
Mutating webhook | No | N/A |
With the introduction of support for in-place Pod resizing, the apply methods PatchWorkloadResources and DynamicAdmissionWebhook are deprecated. Use PatchImmediateRollout, WebhookImmediateRollout, WebhookHybridRollout, or WebhookDeferredRollout instead.
Incremental rollout lets you configure StormForge to apply changes to resource settings gradually over time, rather than all at once.
Note: Using this feature may affect the projected cost impact shown in the StormForge UI.
Cost projections are based on the next change StormForge will apply, not on the final optimization state. Using this feature therefore restricts the magnitude of the total impact projection shown.
Incremental rollout is eventually consistent. The optimization results with and without use of this feature will eventually converge, even if the cost projection doesn’t show it.
| Annotation | Default value |
|---|---|
live.stormforge.io/apply.max-percent-increase |
None |
live.stormforge.io/apply.max-percent-decrease |
None |
StormForge 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 StormForge applies. This results in StormForge 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, StormForge is recommending a CPU request of 50m, but the max-percent-decrease is set to "20", StormForge will apply the following changes over time:
100m to 80m (reducing 100m by 20%)80m to 64m (reducing 80m by 20%)64m to 52m (reducing 64m by 20%)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.
To let StormForge always apply recommendations in full:
# Don't configure either of these settings.
To let StormForge 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 StormForge from raising request values at all:
live.stormforge.io/apply.max-percent-increase: "0"