Apply and manage Pod rightsizing with CLI

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

Policies are stored on the cluster as Kubernetes custom resources.

Use the following workflow to apply Pod rightsizing from the cluster:

1. Select a policy (built-in or custom).

2. Define workload selection (by using appList or appSelector label selectors, or a workload policy annotation).

3. Update the Policy resource in the cluster so the updated selectors and parameters take effect.

No Policy resources?

If your cluster does not show Policy resources, rather APC and JPC resources, you are running an older version of the Insights agent.

See Deprecated Pod rightsizing topics.

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 and manage Pod rightsizing for 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 in addition to extra parameters to temporarily increase resources during Pod initialization. For more information, see Boost startup resources.

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
  startupBoost:
 	duration: 5m
 	cpu:
   	  multiplier: 1.5
 	memory:
   	  multiplier: 3
  preferInPlace: true
  priority: 2

Policy parameters reference

All parameters are validated when a policy is created or updated. Policies with missing or invalid parameters cannot be applied.

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:

1. Add the custom definition to Helm values.yaml:

   rightsizing:
     config:
       customReplicaAggregationMethods:
         cpu:
           custom1: 70
           custom2: 71
         memory:
           custom1: 80
           custom2: 81
   

   Note that both CPU and memory are in the same section.

2. 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.replicaAggregationMethod to custom value 1.

Boost startup resources

Some workloads require higher CPU or memory during initialization than during normal operation. To accommodate this, you would need to manually assign extra resources for startup (to prevent OOM or throttling) and then to reduce those assignments for ongoing operation.  

With Pod rightsizing and Startup boost, you can temporarily increase CPU and memory resources for new Pods during initialization. After a configured duration, the resources automatically revert to initial values and then Pod rightsizing is applied.

With Startup boost:

• Startup-related spikes are excluded from the steady state recommendation logic.

• Steady-state requests are aligned with actual runtime usage.

You apply Startup boost to a workload by adding startupBoost to a custom Pod rightsizing policy that manages the workload.

spec:
   startupBoost:
 	duration: 5m
 	cpu:
   	  multiplier: 1.5
 	memory:
   	  multiplier: 3

For more information about creating and editing custom policies, see Create and manage custom policies - CLI.

For the description of the parameters, see Policy parameters reference.

Startup boost limitations and considerations

• Applies to all containers in a Pod.

• Requires in-place Pod mutation support.

• Cannot be used if preferInPlace: false

• If a Pod needs to be evicted to a different node due to insufficient node capacity, it will be evicted even if the policy includes: spec.evictPodsInDeferredState = false