Core Concepts
Resource Efficiency
How Kubeadapt measures the gap between what workloads request and what they actually use — the lever behind every right-sizing recommendation.
In Kubernetes, you pay for what you request, not what you use. A pod that asks for 2 cores but only uses 200m still reserves the full 2 cores on the node — and the cluster bill reflects the reservation, not the consumption. Resource efficiency is the ratio between the two, and it's the lever behind every right-sizing recommendation Kubeadapt produces.
The metric
Efficiency = Actual Usage / Requested × 100% (capped at 100%)CPU and memory are tracked independently. GPU utilization is also tracked, but as separate metrics — it isn't folded into the single headline efficiency number, because GPU is request-based, not usage-based, in Kubernetes scheduling. See How costs are computed.
How Kubeadapt measures it
Usage is measured against requests, not limits. Requests determine scheduling and billing, so the gap between actual usage and requested resources is the waste you pay for. Limits exist to cap anomalies and have no effect on what gets reserved.
The measurement window is the cluster's right-sizing lookback — 7 days by default. Production clusters use the P99 of usage over that window; non-production clusters use P50. The percentile is configurable per cluster through the analysis policy. See Right-sizing for the full policy model.
Example
A deployment requesting 2000m CPU and 4Gi memory, where actual usage over the lookback window is:
CPU usage (P99): 400m → 400 / 2000 = 20% efficiency
Memory usage (P99): 1.5Gi → 1.5 / 4 = 37.5% efficiency80% of the CPU budget and 62.5% of the memory budget are going unused. That gap is what right-sizing recovers.
Efficiency bands
These bands drive the dashboard color-coding and right-sizing recommendation severity.
CPU
| Range | Level | What it means |
|---|---|---|
| 70–85% | Excellent | Well-sized; no action needed. |
| 50–70% | Good | Acceptable; minor optimization possible. |
| 30–50% | Moderate | Right-size to reduce requests by 20–40%. |
| 15–30% | Poor | Right-size urgently; reduce by 40–60%. |
| Below 15% | Very poor | Severe over-provisioning; reduce by 60–80%. |
Memory
| Range | Level | What it means |
|---|---|---|
| 75–90% | Excellent | Well-sized; no action needed. |
| 60–75% | Good | Acceptable; minor optimization possible. |
| 40–60% | Moderate | Right-size to reduce requests. |
| 20–40% | Poor | Right-size urgently. |
| Below 20% | Very poor | Severe over-provisioning. |
Roll-up: pod → workload → namespace → cluster
Efficiency aggregates at every level you can drill into.
Workload
The workload's efficiency is its containers' usage divided by their requests, weighted by request size.
Namespace
Namespace: backend
Requested: 80 cores, 320 GiB
Usage: 24 cores, 160 GiB
CPU efficiency: 30% | Memory efficiency: 50%Namespace efficiency rolls up every workload it contains. Use it for per-team visibility into waste.
Cluster
1Total requested CPU: 450 cores
2Total actual usage: 180 cores
3Cluster CPU efficiency: 40%
4
5Total requested memory: 1.8 TiB
6Total actual usage: 720 GiB
7Cluster memory efficiency: 40%The cluster dashboard also surfaces a single Efficiency Score — a weighted blend of CPU and memory efficiency across the running workloads — useful for cluster-to-cluster comparisons.
Node
Nodes show two layers of waste:
- Scheduling waste — unallocated capacity on the node (requests don't fill it).
- Over-provisioning waste — pods request more than they use.
Node capacity: 8 cores
Allocated (requests): 6 cores → 75% node utilization
Actual usage: 3 cores → 50% efficiency against requests, 37.5% against capacityFixing scheduling waste is a bin-packing problem (more pods per node, fewer nodes). Fixing over-provisioning waste is a right-sizing problem (smaller requests, same nodes). They compound.
Efficiency vs. utilization
Two related-but-distinct metrics:
- Efficiency — usage ÷ requests. How well pods use what they asked for.
- Utilization — usage ÷ capacity. How well nodes are filled.
Node capacity: 8 cores
Pod requests: 2 cores
Pod usage: 400m
Efficiency: 400m / 2000m = 20%
Utilization: 400m / 8000m = 5%Where you see efficiency in the product
- Cluster dashboard — headline Efficiency Score plus per-namespace CPU/memory bars.
- Namespace view — per-workload efficiency, sortable.
- Workload details — efficiency history alongside the request-vs-usage chart.
- Pod details — per-container CPU and memory efficiency.
- Node monitoring — node-level efficiency and the two-layers-of-waste breakdown.
- Available Savings — every right-sizing recommendation includes the workload's current efficiency.
Closing the gap
Kubeadapt's right-sizing recommendations analyze actual usage over the lookback window using the percentiles described above, then add a small growth buffer and spike buffer so the new requests still cover normal variance. Apply them, wait a week, and efficiency rises while cluster cost drops — typically 20–40% in the first round.
For the step-by-step process — including the safe-rollout order for production workloads — see the Right-sizing guide.