Right sizing

Right-sizing

Right-sizing compares what each container requests and is limited to with what it really used over the last day or the last 7 days, and suggests requests and limits per container. It finds containers that reserve far more than they use (waste), and containers at risk: memory near the limit, recent OOM kills, CPU throttling, missing requests.

Nothing is changed in the cluster. A recommendation is a resources: snippet you copy into your manifests, Helm values or GitOps repository.

Contents: Where it is · Where the numbers come from · The page · How a recommendation is made · Findings · Limits and privacy

Where it is

• The Right-sizing page in the Workloads section: every workload and container of the namespaces you chose, grouped by namespace.
• A Right-sizing section in the details of a Deployment, Stateful Set, Daemon Set or pod: the same rows for that one workload.

Where the numbers come from

Source	What you get
Prometheus (with the cAdvisor metrics most installations scrape)	Usage history over the window: CPU at the 95th percentile of its 5-minute rate, the memory peak (working set), the share of CPU periods that were throttled, and how long the container has been running inside the window. This is the only source that gives recommendations.
metrics-server only	The current CPU and memory: a single point. Sextant shows it and checks requests and limits, but gives no recommendation ("Snapshot").
Neither	Only the requests and limits in the pod specs are checked (for example "No memory request").

Sextant uses the Prometheus of the cluster's settings (Find automatically, a manual address, or Off; see Settings). History is read when the view opens and refreshed every five minutes while it is shown.

A workload's history includes pods that were replaced during the window (after a rollout, a restart or a scale-down): Sextant recognises them by the names their controller gives them (web-7d4b9c6f5-x2k8p for a Deployment web, db-0 for a Stateful Set db), so a pod of web-api is never counted for web.

The page

1. Open Workloads → Right-sizing.
2. Choose one or a few namespaces in the namespace filter. With All namespaces the page asks you to pick: it reads the history of every container it shows, so it works on at most the first 10 namespaces of the filter.
3. Pick the window: Last day or Last 7 days (default).

Each row is one container of one workload, with:

• Pods: how many pods of the workload run now;
• CPU and Memory: the request and limit (or "not set"), the usage (p95, peak, or now for a snapshot) and the recommendation (→ 120m, → limit 512Mi);
• Findings: badges explained on hover (see below);
• Copy resources YAML: copies the recommended resources: block to the clipboard.

Each namespace shows its totals: the CPU and memory wasted and requested. Sort by Wasted CPU, Wasted memory or Name, and tick Only containers with findings to hide the rest. Init containers that run alongside the app (native sidecars, restartPolicy: Always) are rows too.

Example of a copied snippet:

resources:
  requests:
    cpu: 120m
    memory: 192Mi
  limits:
    memory: 256Mi

How a recommendation is made

Value	Rule
CPU request	p95 of CPU × 1.15, rounded up to 10m
Memory request	memory peak × 1.15, rounded up to 16Mi
Memory limit	memory peak × 1.3. After an OOM kill in the last 7 days, at least the current limit × 1.25: the peak was cut off by the limit, so the real need is higher than what was seen
CPU limit	Only when the container has one now: p95 × 2, at least the request; when 25% or more of CPU periods were throttled, at least the current limit × 1.5

How much history the recommendation rests on is shown next to it:

• less than 6 hours of samples: no recommendation ("Not enough history");
• less than 90% of the window: a recommendation, marked "Based on N of history";
• when Prometheus cannot say since when it has samples: a recommendation, marked "History of unknown length".

Waste is how much the current request is above the recommendation.

Findings

Finding	Meaning
No CPU request, No memory request	The scheduler reserves nothing; without a memory request the pod is among the first evicted under memory pressure
No CPU limit, No memory limit	The container may use any idle CPU (often intended), or take memory from its neighbours
CPU over-provisioned, Memory over-provisioned	The request is at least twice the recommendation, and at least 50m CPU or 64Mi more
CPU request below p95, Memory request below peak	Usage is above the request most of the time, or at its peak
Memory near limit	Memory reached 90% of the limit
OOMKilled recently	The container was killed for running out of memory in the last 7 days
CPU throttled	25% or more of its CPU periods were throttled

Risks are listed first, then waste, then missing values.

Limits and privacy

• Sextant sends Prometheus fixed queries of its own; nothing you type becomes part of a query.
• At most 5000 containers come with history; the page says when a namespace selection matched more.
• Right-sizing reads only. It is not available to AI agents or extensions.

Next: Using Sextant, Settings.