Resource Efficiency

Overview

Resource efficiency measures how much of your requested resources are actually being used. In Kubernetes, you pay for what you request, not what you use, so the gap between the two is waste.

text

Efficiency = Actual Usage / Requested Resources × 100%

Note

Industry-wide, average Kubernetes CPU efficiency sits around 10-13%. Most clusters have significant room to improve.

How Efficiency Is Calculated

Kubeadapt is request-centric: efficiency is always measured against requests, not limits. Since requests determine scheduling and billing, the gap between actual usage and requested resources is the waste you pay for.

Usage is measured using percentile-based analysis over a 7-day lookback window. Production clusters default to P99, non-production to P50. Power users can override these values per cluster through the analysis policy settings. See Right-sizing for how percentiles and policies work.

Example

A deployment requesting 2000m CPU and 4Gi memory, where actual usage over the lookback window is:

text

CPU usage (P99): 400m → 400 / 2000 = 20% efficiency
Memory usage (P99): 1.5Gi → 1.5 / 4 = 37.5% efficiency

80% of the CPU budget and 62.5% of the memory budget are going unused.

Efficiency Levels

CPU

Range	Level	Action
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	Action
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

Warning

Memory thresholds are higher than CPU because memory is incompressible. Running out of memory causes OOM kills, so keeping a larger safety margin matters.

Cluster and Namespace Efficiency

Efficiency aggregates up from pods to namespaces to the full cluster.

Cluster level

text

Total requested CPU: 450 cores
Total actual usage: 180 cores
Cluster CPU efficiency: 180 / 450 = 40%

Total requested memory: 1.8 TB
Total actual usage: 720 GB
Cluster memory efficiency: 720 / 1800 = 40%

In this example, 60% of cluster resources are going to waste.

Node level

Nodes have 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

text

Node capacity: 8 cores
Allocated (requests): 6 cores → 75% node utilization
Actual usage: 3 cores → 50% efficiency against requests, 37.5% against capacity

Namespace level

Namespace efficiency rolls up all pod efficiency within it, giving per-team visibility into waste:

text

Namespace: backend
Requested: 80 cores, 320 GB
Usage: 24 cores, 160 GB
CPU efficiency: 30% | Memory efficiency: 50%

Efficiency vs. Utilization

These are related but distinct metrics:

Efficiency: usage divided by requests (how well pods use what they asked for)
Utilization: usage divided by capacity (how well nodes are filled)

text

Node capacity: 8 cores
Pod requests: 2 cores
Pod usage: 400m

Efficiency: 400m / 2000m = 20%
Utilization: 400m / 8000m = 5%

Tip

Low efficiency means pods are over-provisioned - fix by right-sizing requests. Low utilization means nodes have too much spare capacity - fix by adding more pods or scaling down nodes. A well-optimized cluster has both high utilization (nodes are packed) and good efficiency (requests match usage).

Improving Efficiency

Kubeadapt's right-sizing recommendations analyze actual usage patterns over a 7-day window using the percentiles described above. As workloads are right-sized, waste decreases, node utilization improves through better bin-packing, and cluster costs drop.