Automatic Workload Rightsizing

Overview

Komodor’s Automated Rightsizing capability helps you continuously optimize your Kubernetes workloads by adjusting CPU and memory requests based on real usage patterns.

This feature moves beyond manual recommendations by:

• Mutating pod specs automatically on creation/update
• Enforcing safe, policy-driven resource limits
• Providing full auditability and control

With Autopilot Rightsizing, you can reduce overprovisioning, cut cloud costs, and improve application reliability - all with minimal manual intervention.

What Is Rightsizing?

Rightsizing is the process of adjusting a container’s CPU and memory requests to match actual usage. Overprovisioned workloads waste money; underprovisioned workloads risk OOMKills, throttling, or instability.

Without Komodor:

• You monitor usage manually
• Apply changes via YAML or GitOps
• Hope developers follow best practices

With Komodor:

• Daily evaluations per workload
• Automated enforcement with guardrails
• Real-time observability and impact analysis

How Komodor Automates Rightsizing

Komodor uses a Kubernetes Admission Controller to:

• Intercept pod creation/update events
• Evaluate whether a pod is eligible for mutation
• Apply optimized CPU/memory requests automatically
• Label the pod for easy tracking of changes
• Only pods are changed, therefore Komodor is GitOps friendly as it does not mutate the deployment, and therefore not leading to drifts. 

Eligibility Criteria

Workloads must meet the following:

• At least 7 days of historical usage data
• Included in a rightsizing policy (manual or dynamic)
• Not explicitly excluded by the user

Rightsizing Policies

Policies define when, where, and how Komodor can apply resource changes. Each policy can define the optimization strategy (the base percentile fed into the rightsizing recommendation algorithm), limits on the change magnitude (only apply if delta ≥ X%), Request buffers, configuration to allow upscaling/downscaling (independently toggleable), and more. 

These guardrails ensure safe, stable behavior, even in sensitive environments.

How policy matching works

Komodor matches policies at the workload level. A workload can fall inside more than one policy.

When that happens, Komodor picks one effective policy:

1. Manual selection wins. A policy pinned to the workload on the Right-Sizing page is used.
2. Otherwise, highest priority wins. Among the matching policies, the one with the highest priority value is used.

Komodor then generates and applies the recommendation using that policy. Overlaps always resolve to one explicit result.

Setting a policy scope scope

Policies live under Cost Settings → Policies.

Set these fields:

• Policy Name is required.
• Priority is a required integer. Higher wins on conflict.
• The combination of name and priority must be unique.

Define what the policy covers in the Rightsizing Policy Scope builder. Each row is a statement. Statements are joined with AND. Add more rows with Add statement.

Each statement has three parts:

• Field — Cluster, Namespace, Resource Type, or Workload.
• Operator — Matches wildcard or Is.
• Value — a pattern, a name, or a list.

The workload count in the top-right corner updates as you refine the scope.

Targeting multiple clusters with a wildcard

Use the Cluster statement to cover more than one cluster at once.

1. Set the operator to Matches wildcard.
2. Enter a pattern in the value field.

Patterns:

• * matches every cluster.
• *-staging matches every cluster whose name ends in -staging.
• prod-* matches every cluster whose name starts with prod-.

The policy then applies to all matching clusters. You do not recreate it per cluster.

Excluding namespaces or workloads

There are two ways to exclude work from a policy.

Within a policy — carve values out of a wildcard match

1. Open the three-dot menu on a scope statement.
2. Choose Add exclusion.
3. Enter the namespaces or workloads to exclude.

Across all policies — exclude a single workload everywhere

1. Go to the Right-Sizing page.
2. Turn off the workload's Automated toggle.

The workload is added to the global exclusion list and excluded from Right-Sizing under every policy.

Opting Out via Annotation

Workloads can be explicitly excluded from Komodor Rightsizing by adding the following annotation to the workload:

metadata:
  annotations:
    komodor.io/rightsizing-opt-out: "true"

When this annotation is present, Komodor will skip modifying both existing and newly created pods.

Optimization Strategy

Specify the base percentile value (between 70 and 99) to be used in the rightsizing recommendation algorithm.

Komodor calculates this percentile over a 30-day sliding window and uses it as the baseline for the recommended resource values. The final recommendation also considers additional guardrails defined in your cost optimization policy.

Assigning a policy to a workload

On the Right-Sizing page, each workload row shows a Policy column with the effective policy. 

• Click the policy name to pin a different policy. 
• A manually selected policy overrides priority-based matching.

Managing Automation from the Rightsizing Dashboard

The Rightsizing dashboard has two main tables:

Potential Savings Table

• Lists workloads that could benefit from rightsizing
• Includes:
  • Current vs recommended requests
  • Monthly savings estimate
  • Under provisioned containers that may require rightsizing up
  • Option to enable automation directly per workload

Active Savings Table

• Lists workloads already managed by Komodor
• Includes:
  • Applied request values
  • Number of affected pods out of the total number of replicas
  • Estimated monthly savings
  • Option to configure the rightsizing policy 

Enabling or disabling automation updates the policy scope dynamically (manual vs excluded).

Top Summary Metrics

Visible at the top of the Rightsizing page:

Identify Automatic Rightsized Workloads

All rightsizing actions are auditable and can be tracked through the pod view itself.

Komodor can also issue full reports on all workload changes upon request (this will be added to the platform down the road). 

You can also keep track easily using the labels Komodor creates on the pod.

Manual Rightsizing is Still Available

Komodor still provides the ability to manually change the requests of workloads based on its recommendations (calculated based on the last 30 days).

All functionality remains the same:

• For non-automated workloads, an option to drill down to the usage and recommendation will exist.
• In that modal, you can easily modify the requests of each container based on what you see fit (and potentially based on Komodor’s recommendation)