StormForge Optimization Configurations
StormForge policy-based optimization ensures consistent right-sizing across workloads and gives teams the control they need over their work. For example:
-
Platform teams can set organization-wide default optimization values
-
Platform teams can provide different organization-wide default optimization values for workloads of a certain type, or matching certain label selectors
-
Development teams can fine-tune settings for workloads in namespaces they own, or that match their own specific label selectors
Configuration is defined and applied to workloads based on a series of configuration steps evaluated for and applied to workloads in the order the steps are defined in. Each step can apply new configuration to the workload, or change/override configuration that was applied in an earlier step. Steps may be defined such that they apply to all workloads, or may only apply to workloads matching certain criteria.
Optimization Configuration Resources
StormForge configuration steps are defined in one of two different Custom Resource (CR) types. Those types are:
-
ClusterOptimizationConfiguration - A cluster-scoped resource, ClusterOptimizationConfigurations are intended for use by platform teams, and can be used to define organization-wide optimization policy. ClusterOptimizationConfigurations provide rules that are always evaluated first, before any OptimizationConfiguration rules.
-
OptimizationConfiguration - A namespace-scoped resource, OptimizationConfigurations are intended for use by application or development teams who own resources in a namespace. OptimizationConfigurations apply ONLY to workloads in the namespace they are defined in. OptimizationConfigurations are evaluated after ClusterOptimizationConfigurations.
If multiple ClusterOptimizationConfiguration exists, or if multiple OptimizationConfigurations exist in a single namespace, StormForge will order the list of each CR type by their spec.order ASC then metadata.name ASC fields, and apply the list in that order.
Custom Resource Definitions
ClusterOptimizationConfiguration
ClusterOptimizationConfigurations define an ordered list of rules. Each rule in a ClusterOptimizationConfiguration can include matchConditions, workloadSelector, and/or namespaceSelector. An order field lets users indicate relative evaluation order between multiple ClusterOptimizationConfigurations.
apiVersion: optimize.stormforge.io/v1
kind: ClusterOptimizationConfiguration
metadata:
name: cluster-defaults
spec:
order: 10
rules:
- name: NAME
matchConditions: []
workloadSelector: {}
namespaceSelector: {}
settings: []
OptimizationConfiguration
OptimizationConfigurations define an ordered list of configs. Each config in an OptimizationConfiguration can include matchConditions and workloadSelector. OptimizationConfigurations only apply to workloads in the same namespace. An order field lets users indicate relative evaluation order between multiple OptimizationConfigurations.
apiVersion: optimize.stormforge.io/v1
kind: OptimizationConfiguration
metadata:
name: namespace-defaults
namespace: default
spec:
order: 10
rules:
- name: NAME
matchConditions: []
workloadSelector: {}
settings: []
Rules – Configuration Steps
Cascading rules, or configuration steps, can be defined in ClusterOptimizationConfigurations and OptimizationConfigurations as spec.rules.
spec:
rules:
- name: NAME
# CEL expressions enable non-label filtering, expressions must be truthy
matchConditions:
- name: NAME
expression: 'object.kind == "Deployment"'
# Selects workloads based on workload labels. This should be a Kube
# `metav1.LabelSelector`
workloadSelector:
matchLabels:
"app.kubernetes.io/name": "foobar"
# Selects workloads based on namespace labels. This should be a Kube
# `metav1.LabelSelector`. This is the only difference between
# "ClusterOptimizationConfiguration" and "OptimizationConfiguration"; when
# the CRD is namespaced scope the namespace selector is effectively implied.
namespaceSelector:
matchLabels:
"kubernetes.io/metadata.name": "default"
# A Kube listMap, keyed on `name`. Settings can be any supported setting
# string from https://docs.stormforge.io/optimize-live/configure/settings/
settings:
- name: "schedule"
value: "P2D"
- name: "memory.optimization-goal"
value: "Balanced"
Match Conditions and Selectors
Configuration steps include match conditions and selectors, which constrain which workloads the step applies to. MatchConditions use CEL expressions to match non-label workload characteristics, such as annotations, workload type or StormForge patch-target type. Namespace selectors can match namespaces by label. Workload selectors can match workloads by label.
Empty selectors or match conditions match all workloads.
Workloads must satisfy all of matchConditions, workloadSelector, and namespaceSelector in order for the step to match.
CEL Variables
Match conditions are evaluated using CEL. The following variables are available in the evaluation context:
object
The workload object being evaluated.apiVersion: The GroupVersion string of the workload (e.gapps/v1).kind: The workload kind (e.g.Deployment).metadata.name: The name of the workload.metadata.namespace: The namespace of the workload.metadata.labels: A map of the workload’s labels.metadata.annotations: A map of the workload’s annotations.
namespaceObject
The namespace object containing the workload.
Only available in ClusterOptimizationConfiguration.metadata.name: The name of the namespace.metadata.labels: A map of the namespace’s labels.metadata.annotations: A map of the namespace’s annotations.
Settings
If all match conditions and selectors all match a workload, the given settings will be applied to it during this step.
Settings can include any supported StormForge configuration setting. Because configuration steps are evaluated in order, settings defined in a later step can override settings defined in earlier steps.
Settings items consist of name and value (or values, for list items). The name should be a StormForge setting name like schedule or containers.cpu.requests.max. The value is a string.
Settings is a listMap keyed off of name.
CR Ordering
The optional spec.order field is used to control the relative evaluation order of CRs when multiple CRs of the same type exist. The order field follows the Higher = Stronger pattern. Higher numbers will be evaluated later, and could override settings specified in lower-order CRs.
CRs with the same spec.order will be ordered relative to each other alphabetically by name.
Order values must be between [-1000, 1000] inclusive. If not specified, order will default to 0.
spec:
order: 10