Are your Kubernetes workloads requesting more resources than they need?

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.

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.