1
00:00:00,167 --> 00:00:02,100
Three quiet days of metrics.

2
00:00:02,000 --> 00:00:06,033
A tool sees low memory use, and suggests cutting the request

3
00:00:05,933 --> 00:00:06,967
in half.

4
00:00:06,867 --> 00:00:08,967
Then the weekly job runs.

5
00:00:09,433 --> 00:00:11,867
Monitoring data is rarely complete.

6
00:00:11,767 --> 00:00:14,367
Scrapes are missed, pipelines restart,

7
00:00:14,267 --> 00:00:16,767
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,667
Short observation windows miss weekly cycles,

10
00:00:23,567 --> 00:00:27,233
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,800
A recommendation built on that data looks precise.

13
00:00:31,700 --> 00:00:35,200
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,933
RATIVERA checks the evidence before it concludes.

16
00:00:41,833 --> 00:00:46,067
When this workload on our own AKS test cluster was assessed,

17
00:00:45,967 --> 00:00:50,267
RATIVERA had a tenth of an hour of usable CPU evidence.

18
00:00:50,167 --> 00:00:52,800
It needs a hundred and sixty-eight hours,

19
00:00:52,700 --> 00:00:56,567
at ninety percent coverage, before it will size the workload.

20
00:00:56,467 --> 00:01:00,333
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,500
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.