Right-Sizing
Right-Sizing compares what each workload asked for against what it actually uses, and suggests a request that matches reality.
The five verdicts
Section titled “The five verdicts”Every workload lands in exactly one bucket:
| Verdict | Meaning |
|---|---|
| Good | The request is a reasonable fit for observed usage. |
| Under | Usage regularly exceeds the request. The workload is a throttling and eviction candidate. |
| Over | The request reserves capacity that is never used. This is the cost line. |
| Unset | No request at all. The scheduler is guessing, and the pod is BestEffort or Burstable by accident. |
| Insufficient | Not enough usage history to judge. Not a pass. |
The table
Section titled “The table”| Column | What it shows |
|---|---|
| Workload | Name and namespace. |
| CPU request | vs observed P50 and P95. |
| Memory request | Same. |
| QoS class | Guaranteed, Burstable, BestEffort — derived from requests and limits. |
| Verdict | One of the five above. |
| No-limit badge | Flags containers with a request but no limit. |
| Suggested request | Shown for Unset, Under and Over rows. |
Read P95, not the average
Section titled “Read P95, not the average”The suggestion is anchored on P95, not the mean. A workload that idles at 20m and spikes to 400m during its batch window is not a 30m workload — sizing it on the average is how you get a service that is fine for twenty-three hours and throttled for the twenty-fourth.
Insufficient is deliberately not merged into Good. A workload deployed yesterday has no usage distribution to size against, and calling that “correctly sized” would be a fabrication.