This section describes how to apply and manage Pod rightsizing from the cluster using the CLI.
Pod rightsizing is configured declaratively using Kubernetes Policy custom resources (CRs). A policy defines Pod rightsizing behavior and how the policy selects workloads.
Policies select workloads using an appList selector, label selectors, or a policy annotation on the workload.
Each workload is managed by at most one policy at a time. When multiple policies match the same workload, precedence rules determine which policy manages it.
If no policy manages a workload, Pod rightsizing is not applied to it.
Workflow description
Use the following workflow to apply Pod rightsizing from the cluster:
Select a policy (built-in or custom).
Define workload selection (by using
appListorappSelectorlabel selectors, or a workload policy annotation).Update the
Policyresource in the cluster so the updated selectors and parameters take effect.
Kompass provides built-in policies, and you can also create custom policies.
The built-in policies - Balanced, Stability-focused, and Cost-focused - are described in Pod rightsizing workload optimization. You can see their fixed parameters at Built-in policy fixed parameter values.
You cannot delete or change built-in policies parameters.
To manage a workload by policy, you edit the policy workload selection and priority values, as described in Apply Pod rightsizing to workloads - CLI.
You can also create a custom policy by duplicating an existing policy. With a custom policy, you have full control of all parameters.
For information about creating, editing, and deleting a custom policy, see Manage custom policies.
Configuration sample
Values inside [ ] are user-specified placeholders.
spec:
appList: []
appSelector:
labels: {}
namespaces:
operator: Include
values: []
cooldownPeriod: 0s
cpu:
bufferPercentage: 30
ignoreThrottlingEvent: false
minimumImpactPercentage: 10
minimumStepForScaleUp: 100m
minimumValueForScaleDown: 10m
optimizationStrategy: max
replicaAggregationMethod: max
dataCoveragePercentage: 80
evictPodsInDefferedState: false
lookbackPeriod: 5m
memory:
bufferPercentage: 40
ignoreOomEvent: false
minimumImpactPercentage: 10
minimumStepForScaleUp: 256Mi
minimumValueForScaleDown: 256Mi
optimizationStrategy: max
replicaAggregationMethod: max
preferInPlace: true
priority: 2Policy parameters reference
All parameters are validated when a policy is created or updated. Policies with missing or invalid parameters cannot be applied.
Click here to see the policy parameter reference
Parameter | Description | Value |
| Explicit allowlist of workloads to manage with this policy. | List of workloads |
| Label-based rules for selecting workloads to manage. | Label selector |
| Specifies whether to include or exclude the namespaces listed in |
|
| Namespaces used by the namespace filter. | List of strings |
| Minimum time between consecutive Pod rightsizing changes. Longer periods promote greater stability. | Duration (for example, 2h, 30m, 0s) |
| Additional CPU buffer to add to the recommended CPU request. | Percentage (integer 0–100) |
| Specifies whether to ignore CPU throttling rollback behavior. |
|
| Minimum percentage difference required for Kompass to apply a CPU request change. Higher values increase stability (but may reduce optimization effectiveness). | Percentage (integer 0–100) |
| Minimum CPU increment for scale-up changes. | CPU quantity (for example, |
| Minimum CPU request allowed for scale-down changes. | CPU quantity (for example, |
| Specifies which CPU optimization strategy to apply. |
|
| Specifies how Pod replicas are aggregated when calculating CPU recommendations. You can configure custom values. For more information, see Define custom replica aggregation method values. |
|
| Minimum portion of the lookback period required before Kompass generates Pod rightsizing recommendations. | Percentage (integer 0–100) |
| If a Pod need to be created on a new node, evict it so it can be rescheduled on a new node. |
|
| Amount of historical workload data that Kompass uses to generate recommendations. | Duration (for example, |
| Additional memory buffer to add to the recommended memory request. | Percentage (integer 0–100) |
| Specifies whether to ignore out-of-memory (OOM) rollback behavior. |
|
| Minimum percentage difference required for Kompass to apply a memory request change. Higher values increase stability (but may reduce optimization effectiveness). | Percentage (integer 0–100) |
| Minimum memory increment for scale-up changes. | Memory quantity (for example, |
| Minimum memory request allowed for scale-down changes. | Memory quantity (for example, |
| Specifies which memory optimization strategy to apply. |
|
| Specifies how Pod replicas are aggregated when calculating memory recommendations. You can configure custom values. For more information, see Define custom replica aggregation method values. |
|
| If in-place changes are supported, adjust the resource request using in-place changes. |
|
| Policy priority. If a workload matches multiple policies, the policy with the lower numeric value has higher priority. | Integer (priority values start at 0) |
Define custom replica aggregation method values
You can define custom values for the CPU and memory replica aggregation method. This can be useful if the fixed values are overly aggressive.
To define custom aggregation method figures, you define values for custom1 and custom2 in Helm values.yaml, then define the value in the policy configuration as custom value 1 or custom value 2.
To define custom values:
Add the custom definition to Helm values.yaml:
rightsizing: config: customReplicaAggregationMethods: cpu: custom1: 70 custom2: 71 memory: custom1: 80 custom2: 81Note that both CPU and memory are in the same section.
In the policy on the cluster, change the value to the desired value.
For example, to set the memory value to 80, change the value in the policy
spec.memory.replicaAggregationMethodtocustom value 1.