1
00:00:00,167 --> 00:00:02,800
This workload requests a full CPU core.

2
00:00:02,700 --> 00:00:06,267
On an average day, it uses about a fifth of it.

3
00:00:06,167 --> 00:00:08,267
So, should you cut the request?

4
00:00:08,733 --> 00:00:12,800
In Kubernetes, a request is what the scheduler reserves for a

5
00:00:12,700 --> 00:00:16,200
container. Usage is what it actually consumes.

6
00:00:16,100 --> 00:00:18,767
When requests run far above real demand,

7
00:00:18,667 --> 00:00:22,633
that reserved capacity sits idle, and other workloads cannot

8
00:00:22,533 --> 00:00:23,500
use it.

9
00:00:23,967 --> 00:00:26,267
But a low average is not proof.

10
00:00:26,167 --> 00:00:29,100
Averages hide bursts, weekly batch jobs,

11
00:00:29,000 --> 00:00:30,833
and CPU throttling.

12
00:00:30,733 --> 00:00:34,833
Cut on the average alone, and you can trade idle capacity for

13
00:00:34,733 --> 00:00:38,000
slow responses, or out-of-memory restarts.

14
00:00:38,467 --> 00:00:40,867
RATIVERA starts from the evidence.

15
00:00:40,767 --> 00:00:44,833
For CPU, it checks every replica, and keeps safety headroom

16
00:00:44,733 --> 00:00:47,467
above the highest usage observed.

17
00:00:47,367 --> 00:00:50,933
For memory, it does the same: the highest usage observed,

18
00:00:50,833 --> 00:00:52,200
plus headroom.

19
00:00:52,100 --> 00:00:55,967
Before any reduction, it needs seven days of usable history.

20
00:00:55,867 --> 00:00:58,967
Without that, it makes no recommendation.

21
00:00:59,433 --> 00:01:03,533
RATIVERA also recommends increases, when the evidence shows a

22
00:01:03,433 --> 00:01:05,167
request is too low.

23
00:01:05,067 --> 00:01:07,700
Either way, your team reviews the reasoning,

24
00:01:07,600 --> 00:01:08,800
and decides.

25
00:01:09,267 --> 00:01:13,667
RATIVERA. Understanding Kubernetes, one problem at a time.