In-place pod resizing
In-place pod resizing and the apply methods described on this page are currently in preview and may be subject to change.
Optimize Live supports in-place pod resizing, a Kubernetes 1.32+ feature that allows resource requests and limits to be updated on running pods without restarting them. New apply method values give you control over how and when recommendations are applied to existing pods.
Apply method
Defines how the Optimize Live Applier applies recommendations to a workload.
| Annotation | Default value |
|---|---|
live.stormforge.io/apply.method |
"PatchImmediateRollout" |
Description
The apply method controls both how the Applier communicates resource changes to Kubernetes and what happens to running pods when a recommendation is applied.
These values replace the previous PatchWorkloadResources and DynamicAdmissionWebhook values. You can set the apply method at the cluster, namespace, or workload level.
Note: The three webhook-based apply methods require webhook.enabled=true on the Applier. See Enabling the webhook apply method for details.
In-place pod resizing requires Kubernetes 1.32 or later. On clusters running an earlier version, webhook-based methods will fall back to triggering a rollout/restart when applying recommendations.
Valid values
PatchImmediateRollout (default)
Use server-side apply patches to modify Deployments, StatefulSets, and other Pod-owning workload resources directly whenever a new recommendation is applied.
This is the default apply method and is equivalent to the previous PatchWorkloadResources value.
WebhookImmediateRollout
Use a mutating webhook to modify Pods at admission. Existing pods will be resized in place whenever a new recommendation is applied. If pods cannot be resized in place, a rollout/restart will be triggered.
WebhookHybridRollout
Use a mutating webhook to modify Pods at admission. Existing pods will be resized in place whenever a new recommendation is applied. If pods cannot be resized in place, changes will be deferred until the next normal rollout.
WebhookDeferredRollout
Use a mutating webhook to modify Pods at admission. Existing pods will not be modified and the workload will not restart when recommendations are applied. Changes will be deferred until the next time pods restart naturally.
Choosing an apply method
| Apply method | Mechanism | In-place resize | If pods cannot be resized in place |
|---|---|---|---|
PatchImmediateRollout |
Server-side patch | No | N/A — always triggers a rollout |
WebhookImmediateRollout |
Mutating webhook | Yes | Rollout/restart triggered |
WebhookHybridRollout |
Mutating webhook | Yes | Deferred until next normal rollout |
WebhookDeferredRollout |
Mutating webhook | Yes | Deferred until next pod restart |
Key points
- Continuous reconciliation (if enabled on the Applier) does not occur on workloads configured to use a webhook-based apply method.
- If a namespace or workload is configured to use a webhook-based method but the webhook feature is not enabled on the Applier, or a namespace allow/deny list restricts access, recommendations are still generated on the configured schedule but the Applier cannot apply them. The UI and CLI will show different values than those on the pod.
- You can still apply recommendations as a Deployment patch regardless of apply method. The patch is available on the Patches tab of the workload details page.
For more information on configuring the apply method, see Apply method in the Apply settings topic.