Containers

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

Container-level settings:

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

For details about how to set these values using annotations, see one of these topics: Configure clusters, Configure namespaces, or Configure workloads.

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.

• RequestsRaiseLimitsIfNeeded: Always optimize requests. For resources without limits, do not add limits; optimize limits only if they already exist.

  • If an existing limit is lower than what Optimize Live recommends, raise the limit to Optimize Live’s recommended value.

  • If an existing limit is higher than what Optimize Live recommends, do not modify the limit. Optimize Live will never lower a limit when using this policy.

    Optimize Live calculates its recommended limits as follows:
    min(max-limit, recommended-requests × limit-request-ratio)

• 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"
  

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.

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)

Patch paths

A patchPath maps a container resource value from a recommendation to where it belongs in the patchTarget.

Description

For built-in Kubernetes workload types, StormForge knows which fields correspond to request and limit values and can automatically generate patches. When generating patches for workloads owned by custom resource types (CRDs), the patch path settings let you specify which CRD fields StormForge will update with recommended request or limit values.

Valid values

String. Examples:

• "/spec/resources/requests/cpu"
• "/spec/resources/limits/cpu"
• "/spec/resources/requests/memory"
• "/spec/resources/limits/memory"
• "/spec/resources/limits/cpu,fluentd=/spec/fluentd/resources/limits/cpu"