WEBVTT

1
00:00:00.167 --> 00:00:02.700
This workload requests a full CPU core.

2
00:00:02.700 --> 00:00:06.167
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.700
In Kubernetes, a request is what the scheduler reserves for a

5
00:00:12.700 --> 00:00:16.100
container. Usage is what it actually consumes.

6
00:00:16.100 --> 00:00:18.667
When requests run far above real demand,

7
00:00:18.667 --> 00:00:22.533
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.167
But a low average is not proof.

10
00:00:26.167 --> 00:00:29.000
Averages hide bursts, weekly batch jobs,

11
00:00:29.000 --> 00:00:30.733
and CPU throttling.

12
00:00:30.733 --> 00:00:34.733
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.767
RATIVERA starts from the evidence.

15
00:00:40.767 --> 00:00:44.733
For CPU, it checks every replica, and keeps safety headroom

16
00:00:44.733 --> 00:00:47.367
above the highest usage observed.

17
00:00:47.367 --> 00:00:50.833
For memory, it does the same: the highest usage observed,

18
00:00:50.833 --> 00:00:52.100
plus headroom.

19
00:00:52.100 --> 00:00:55.867
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.433
RATIVERA also recommends increases, when the evidence shows a

22
00:01:03.433 --> 00:01:05.067
request is too low.

23
00:01:05.067 --> 00:01:07.600
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.