One Problem at a Time
Look beyond average usage
Why requests and usage differ, and why a low average alone cannot justify a reduction.
One Problem at a Time · Episode 1 · 1:15
Are your Kubernetes workloads requesting more resources than they need?
Why requests and usage differ, and why a low average alone cannot justify a reduction.
Illustrative numbers, not a customer result or savings claim. Requests affect scheduler placement; existing containers can still use otherwise idle CPU. In the CPU example, observed peaks are based on sampled five-minute averages. Seven days is the reduction-history gate described here; protective memory increases can follow a different path.
English captions are burned into the video. An optional English caption track and transcript are also available. Use fullscreen for small screen details.
Read the episode 1 transcript
This workload requests a full CPU core. On an average day, it uses about a fifth of it.
So, should you cut the request?
In Kubernetes, a request is what the scheduler reserves for a container. Usage is what it actually consumes.
When requests run far above real demand, that reserved capacity sits idle, and other workloads cannot use it.
But a low average is not proof. Averages hide bursts, weekly batch jobs, and CPU throttling.
Cut on the average alone, and you can trade idle capacity for slow responses, or out-of-memory restarts.
RATIVERA starts from the evidence. For CPU, it checks every replica, and keeps safety headroom above the highest usage observed.
For memory, it does the same: the highest usage observed, plus headroom.
Before any reduction, it needs seven days of usable history. Without that, it makes no recommendation.
RATIVERA also recommends increases, when the evidence shows a request is too low.
Either way, your team reviews the reasoning, and decides.
RATIVERA. Understanding Kubernetes, one problem at a time.
Download transcript · WebVTT captions · Original SRT captions