Manage workloads

Learn how to add, delete, and restore workloads, as well as how to stop optimizing them

3 minute read

Topics:

Adding workloads
Deleting workloads
- Restoring workloads
Excluding a workload from optimization

Adding workloads

Optimize Live automatically detects when the following types are added to a cluster:

Any Kubernetes Workload object (CronJob, DaemonSet, Deployment, ReplicaSet, StatefulSet) and HPA
Workloads scaled by a KEDA-owned HPA (ScaledObjects in keda.sh apiGroup)

When Optimize Live detects a new workload:

Within about 2 minutes, Optimize Live starts generating preliminary recommendations for the workload and updating the UI with workload and recommendation details. Preliminary recommendations cannot be applied automatically, but can be applied on demand. Optimize Live generates these preliminary recommendations for the duration of the workload’s learning period.
When a workload’s learning period is complete, Optimize Live generates recommendations that can be deployed either automatically or on demand.

Related information:

Deleting workloads

After a workload is deleted (for example, manually or as part of a deployment process), it’s considered soft deleted for a period of 24 hours. The workload and its data are removed from the UI and can be accessed only by using the CLI.

Within this period, the workload can be restored (re-created) if needed.

Warning:

Optimize Live permanently deletes a workload, its data, and its recommendations at the end of the 24-hour soft-deletion period. These items cannot be restored.

After a workload is permanently deleted, creating a workload with the same name results in a net new workload with a new creation timestamp and new learning period, as described in Adding workloads above.

Restoring workloads

If the workload is re-created (restored) within the 24-hour soft-deletion period:

The workload’s original creation date, most recent settings, and previous recommendations are restored.
The graphs on the Impact and Recommendation tabs of a workload details page show a corresponding gap in usage and recommendations.

Related information:

Excluding a workload from optimization (without deleting it)

To exclude a workload from optimization without deleting it, use one of the methods below.

Note: To exclude entire namespaces from optimization, use a namespace allow list or deny list. See the related link below.

Set the workload’s auto-deploy setting to false, as shown below.
Optimize Live generates a recommendation for the workload but does not deploy it. However, you can apply it on demand.
```
live.stormforge.io/auto-deploy: "false"
```
Set the workload’s schedule to @never, as shown below.
Optimize Live will not generate recommendations automatically for the workload, but you can still generate and apply them on demand.
```
live.stormforge.io/schedule: "@never"
```
Set the workload’s optimization policies to DoNotOptimize, as shown below.
Optimize Live generates recommendations for the workload according to the configured schedule, but the recommendations do not suggest any changes; and, when patches are generated, the patches do not include the workload.
```
... 
live.stormforge.io/containers.cpu.optimization-policy: "DoNotOptimize"
live.stormforge.io/containers.memory.optimization-policy: "DoNotOptimize"
...
```
Note: You can also set container-level optimization policies: for example, you can set DoNotOptimize on injected containers. For details, see the Optimization policy topic.

Related information:

Last modified December 4, 2024