WEBVTT

1
00:00:00.167 --> 00:00:02.000
Three quiet days of metrics.

2
00:00:02.000 --> 00:00:05.933
A tool sees low memory use, and suggests cutting the request

3
00:00:05.933 --> 00:00:06.867
in half.

4
00:00:06.867 --> 00:00:08.967
Then the weekly job runs.

5
00:00:09.433 --> 00:00:11.767
Monitoring data is rarely complete.

6
00:00:11.767 --> 00:00:14.267
Scrapes are missed, pipelines restart,

7
00:00:14.267 --> 00:00:16.667
and labels stop matching pods.

8
00:00:16.667 --> 00:00:20.267
On a chart, a gap can look exactly like low usage.

9
00:00:20.733 --> 00:00:23.567
Short observation windows miss weekly cycles,

10
00:00:23.567 --> 00:00:27.133
month-end peaks, and releases that change how a workload

11
00:00:27.133 --> 00:00:28.133
behaves.

12
00:00:28.600 --> 00:00:31.700
A recommendation built on that data looks precise.

13
00:00:31.700 --> 00:00:35.100
But nothing supports it, and in production it can cause

14
00:00:35.100 --> 00:00:37.967
throttling, or out-of-memory restarts.

15
00:00:38.433 --> 00:00:41.833
RATIVERA checks the evidence before it concludes.

16
00:00:41.833 --> 00:00:45.967
When this workload on our own AKS test cluster was assessed,

17
00:00:45.967 --> 00:00:50.167
RATIVERA had a tenth of an hour of usable CPU evidence.

18
00:00:50.167 --> 00:00:52.700
It needs a hundred and sixty-eight hours,

19
00:00:52.700 --> 00:00:56.467
at ninety percent coverage, before it will size the workload.

20
00:00:56.467 --> 00:01:00.233
So no recommendation was made, and the page says exactly what

21
00:01:00.233 --> 00:01:01.400
is missing.

22
00:01:01.867 --> 00:01:05.400
A trustworthy optimization platform must know when not to

23
00:01:05.400 --> 00:01:07.067
recommend a change.

24
00:01:07.533 --> 00:01:11.933
RATIVERA. Understanding Kubernetes, one problem at a time.