Concepts
7 minute read
Cluster
In the context of Optimize Live, a cluster is a Kubernetes cluster where the workloads you want to optimize are deployed and on which you have installed the StormForge Agent using the cluster name (clusterName) that you provide.
A cluster can have only one Agent installed. In the context of Optimize Live, “adding a cluster” and “installing the Agent” have equivalent meaning and are used interchangeably.
For installation instructions, see Install the Agent on a cluster in the Install topic.
Workloads
A workload is a component that runs inside one or more Kubernetes pods. In the context of Optimize Live, a workload is a named Workload resource from a namespace in a cluster. Optimize Live observes the resource utilization of workloads in order to produce recommendations—sets of optimal values for requests and limits—for them.
Optimize Live can produce recommendations for the following Workload types: DaemonSet, Deployment, ReplicaSet, ReplicationController, and StatefulSet.
Custom workloads
A custom workload is a custom workload type defined by a Custom Resource Definition (CRD). StormForge monitors for resources matching the Group and Kind defined by the workloadResourceTypes parameter, and generates request and limit recommendations for identified custom workloads the same as for standard workloads.
Related information:
StormForge Agent
The StormForge Agent (“the Agent”) consists of a Kubernetes controller and a Prometheus metrics forwarder. The controller component watches workloads and configuration, while the metrics forwarder component streams a limited set of resource-related metrics to the StormForge platform.
The Agent discovers and gathers metrics for all DaemonSet, HPA, Pod, ReplicaSet, ReplicationController, and StatefulSet types across all the namespaces on the cluster on which it’s installed.
To minimize the footprint in a cluster, Optimize Live requires only the StormForge Agent to be installed on a cluster. By default, the Agent is installed in the stormforge-system namespace.
The StormForge Agent leverages the Kubernetes view role, granting read-only permissions on all resources in the cluster.
Related information:
StormForge Applier
The StormForge Applier is a Kubernetes controller that manages request and limit settings for each workload and applies the recommendations generated by StormForge machine learning. The Applier uses the same StormForge credentials file as the Agent and runs in the same namespace.
Install the Applier if you plan to:
- Deploy recommendations automatically on a schedule of your choosing. This option enables you to skip manually reviewing the recommended settings and ensures your settings track closely to actual CPU and memory use.
- Deploy recommendations on demand. For example, you can apply a single recommendation in any environment as you experiment with recommendations or if you need to quickly deploy a recommendation outside of a schedule.
The Applier applies recommendations using a combination of In-place Pod Resizing, Server-Side Apply patches, and Mutating Admission Webhooks. Use the apply method configuration option to control how recommendations are applied for individual workloads.
The Applier leverages the Kubernetes edit role, enabling it to update and patch all optimizable workloads (and HPA, if enabled). You can grant additional permissions by specifying additional RBAC in the Helm install command.
Related information:
- Should you install the Applier?
- Additional RBAC permission
- Apply method setting
- Optimize Live architecture
Schedule
The schedule defines how frequently Optimize Live generates (and optionally deploys) a recommendation for a workload.
By default, a new recommendation is generated once daily (@daily) for a workload, which is considered a best practice.
With a once-daily schedule, Optimize Live can account for daily traffic patterns. For example, recommendations generated on a Monday might differ from those generated on a Saturday because resource usage patterns often differ between weekdays and weekends.
If auto-deploy is enabled, recommendations are deployed as soon as they’re generated.
To ensure that numerous workloads aren’t restarted simultaneously, Optimize Live staggers the generation and deployment of recommendations throughout the schedule period (when the schedule is an ISO 8601 Duration string or equivalent schedule macro). For details, see the Schedule setting topic linked below.
Learn about how the validity period affects the lifetime and request values of recommendations.
Learn about how a workload’s learning period determines how soon recommendations can be auto-deployed after workload discovery.
Related information:
- Schedule setting
Validity period
You usually don’t need to change the validity period. Consider extending it only if you want recommendations to remain valid beyond the schedule interval.
The validity period defines how long a recommendation remains valid after generation.
By default, the validity period is based on the recommendation schedule. For example, when recommendations are generated daily, the validity period for each recommendation is automatically set to ≥ 1 day.
The validity period can also be configured independently from the schedule, extending recommendation lifetime while recommendations continue to be generated according to the schedule.
For example, with the schedule set to @daily and the validity period set to P7D:
- Recommendations are generated daily
- Each recommendation remains valid for 7 days
New recommendations reflect recent usage patterns, while existing recommendations remain valid for the duration of the validity period. This configuration can be useful for teams that generate recommendations frequently but may not deploy them immediately, such as those using manual deployment processes.
In contrast, a weekly schedule with a 7-day validity period generates only one recommendation per week, making it less responsive to day-to-day traffic changes.
The validity period also affects how aggressively Optimize Live adjusts resource requests. Longer validity periods generally result in more conservative recommendations to keep workloads stable throughout the validity period.
Setting a longer validity period can therefore result in lower savings, because Optimize Live must account for a wider range of usage patterns.
Key points:
- The default validity period is sufficient for most cases.
- A recommendation shouldn’t be used beyond its validity period.
- Validity period must be greater than the recommendation schedule frequency.
Related information:
- Validity period setting
Learning period
The learning period acts as an automation gate, defining the number of days that must pass after discovering a workload before the Applier is permitted to deploy recommendations automatically.
Because CPU and memory usage patterns can vary from day to day, it can take up to 7 days to collect a robust set of metrics and generate well-informed recommendations. For this reason, the default learning period duration is 7 days (P7D).
During the learning period, Optimize Live collects metrics on the workload and generates preliminary recommendations. You can review and apply these recommendations on demand (by clicking Apply Now on the workload details page), but they can’t be auto-deployed, even if auto-deploy is enabled.
Preliminary recommendations are generated hourly for the first 23 hours, then as defined by the schedule—by default, once daily (@daily)—for the remainder of the learning period and beyond. If auto-deploy is enabled, recommendations are deployed immediately following generation.
See Recommendations for details about how the schedule and learning period determine how frequently recommendations are generated and how soon they can be auto-deployed.
Related information:
- Learning period setting
Auto-deployment sooner than 7 days
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, for typical workloads, be aware that metrics collection might not be complete. Consider reviewing and manually applying the preliminary recommendations instead.
Shortening the learning period changes how soon recommendations can be auto-deployed. See the Recommendations section for schedule and learning period examples.
Related information:
- Auto-deploy setting
Recommendations
A StormForge recommendation is the set of resource requests and limits that the machine learning algorithm has determined to be optimal for a workload, based on historical utilization observations.
StormForge can produce recommendations for the following items:
- Kubernetes Workload types: DaemonSet, Deployment, ReplicaSet, ReplicationController, and StatefulSet
- Custom workload types defined by CRDs
- HPA, when enabled and scales on at least one resource metric (see HPA recommendations)
Related information: