Container-level settings

The purpose of this topic is to list and describe the supported optimization configuration settings that apply to individual containers. For settings that apply to the whole workload, see the Workload-level settings topic.

Container-level settings are applied to workloads, just like workload-level settings, but they specify values which can vary from container to container within it.

Container-level settings:

• Optimization policy
• Min and max for requests
• Min and max for limits
• Limit-to-request ratio

For details about how to set these values using annotations, see the Configure namespaces or Configure workloads topic.

Container-level settings syntax

When specifying configuration values for container-level settings, you can specify a default value for all containers, one or more values for specific named containers, or a comma-separated list.

• Default ("RequestsOnly"): default values for all containers are simple strings with a valid value for the setting. The default value will be used for any containers that do not have a named value.
• Named ("istio-proxy=DoNotOptimize"): named container settings apply the value to containers with the given name. The name is specified first, followed by an = sign, then the value to apply to that container.
• Comma-separated ("RequestsOnly,istio-proxy=DoNotOptimize"): an optional default, and one or more named values, can be specified as a comma-separated list. When specifying multiple values, start with the default (if you are including one), then list each named container value.

Annotation examples

live.stormforge.io/containers.cpu.requests.min: "10m"
live.stormforge.io/containers.cpu.requests.max: "16000m,jenkins=4000m,logshipper=20m"
live.stormforge.io/containers.memory.requests.min: "128Mi,jenkins=1Gi"
live.stormforge.io/containers.memory.requests.max: "logshipper=512Mi"

Container settings

The following settings specify per-container values.

Optimization policy

Indicates what to optimize for a container, for each resource (CPU and memory).

Description

The configured optimization policy for a resource dictates how (and whether) Optimize Live will recommend and make changes to a resource (CPU or memory). There are several ways organizations might like to manage limits, and there are use cases for choosing not to optimize a workload or container at all. Selecting an appropriate value for this setting should enable organizations to implement the resource management style of their choice.

Valid values

• RequestsOnly (default): Optimize requests only and do not modify limits. If limits are set, the existing limits will act as a constraint on the maximum value that Optimize Live can recommend for requests.
• RequestsAndLimits: Optimize both requests and limits. If limits don’t exist, Optimize Live will add them.
• DoNotOptimize: Optimize neither requests nor limits. Optimize Live will not suggest modifications to any existing settings for the resource.

Key points

• Optimization policy defines how and whether requests and limits will be optimized.

• Injected containers cannot be optimized without extra configuration. One way to handle this is to set both the CPU and memory policies for injected sidecar containers to DoNotOptimize. For example:

  live.stormforge.io/containers.cpu.optimization-policy: "istio-proxy=DoNotOptimize"
  live.stormforge.io/containers.memory.optimization-policy: "istio-proxy=DoNotOptimize"
  

Minimum and maximum bounds for requests

Values indicate the lower bound and upper bound of the range for CPU or memory requests.

Description

The minimum and maximum request bounds for each resource act as a constraint on what request values Optimize Live will recommend, regardless of the observed usage for the resource. These bounds can be used to set a floor below which requests will never drop and a ceiling above which Optimize Live will never raise them.

When used as defaults for the cluster, request bounds can be used to implement default automation policies such as “never allocate less than 10m of CPU” or “never allocate more than 16Gi of memory without a specific exception”. Exceptions can then be implemented by overriding the cluster default settings on a per-namespace or per-workload basis.

Valid values

Any positive Kubernetes quantity, appropriate to the resource. Examples:

• "10m" (for CPU)
• "32Gi" (for memory)

Minimum and maximum bounds for limits

Values indicate the lower bound and upper bound of the range for CPU or memory limits.

Description

The minimum and maximum limit bounds for each resource act as a constraint on what limit values Optimize Live will set, regardless of the request value for the resource. These bounds can be used to set a floor below which limits will never drop and a ceiling above which Optimize Live will never raise limits.

When used as defaults for the cluster, limit bounds can be used to implement default automation policies such as “never set a CPU limit of less than 1 full core” or “never limit memory to less than 512Mi”.

Valid values

Any positive Kubernetes quantity, appropriate to the resource. Examples:

• "1000m" (for CPU)
• "512Mi" (for memory)

Limit-to-request ratio (LRR)

This value is used to calculate limits when the optimization policy is set to RequestsAndLimits.

Description

When Optimize Live is configured to set limits, the limit it sets is computed as the recommended request value multiplied by the LRR. This ratio can be adjusted separately for each resource, CPU or memory.

Valid values

• "2.0" (default)
• "1.0" (Guaranteed QoS)
• Any value >= "1.0" to a maximum of two decimal places

Key points

• LRR only applies to workloads that use an optimization policy which sets limits. If a policy such as RequestsOnly is in use, the LRR setting has no effect.
• Using an LRR that permits bursting, such as "2.0", lets workloads occasionally exceed their request values without being throttled or OOM-killed. This is advisable when automating request settings, because it gives Optimize Live time to come back and adjust resource requests as necessary, rather than the workload being immediately OOM-killed or unnecessarily throttled.