Deployed 7508935 with MkDocs version: 1.5.3

index.html

@@ -223,5 +223,5 @@ <h3 id="welcome-to-the-kubernetes-cost-optimization-guide">Welcome to the Kubern
 
 <!--
 MkDocs version : 1.5.3
-Build Date UTC : 2024-04-16 13:26:05.329225+00:00
+Build Date UTC : 2024-04-16 15:23:13.078266+00:00
 -->

over-under-idle-waste/index.html

@@ -169,13 +169,16 @@ <h1 id="the-4-focus-areas">The 4 Focus Areas</h1>
 <p>When optimizing our cluster costs we want to focus on all of these areas iteratively - in order to keep our clusters as cost-effective and performant as needed.</p>
 <p>Now let's explain each of these focus areas in more detail.</p>
 <h2 id="wasted-resources">Wasted Resources</h2>
-<p>Pinpointing the exact memory and CPU requests for our pods is hard - it requires observing the application behaviour under production load over a significant time period. 
-Therefore most engineers prefer to err towards overprovisioning  - i.e setting requests much higher than the application will ever use.
-This delta between what an app actually uses and the number set in the pod container requests is <strong>wasted resources</strong>.
-This leads to a large amount of allocated but unutilized resources all across the cluster. Just imagine your cluster runs 200 pods and each of them requests 100Mb more memory than it actually uses. Altogether you'll have 20Gb of wasted RAM across the cluster. These resources will be provisioned, paid for, but never actually used.</p>
+<p><mark>Wasted resources</mark> are the resources that have been allocated but not utilized. 
+In most unoptimizaed clusters we're observing up to 50% of waste, which translates to thousands of dollars or euros monthly.</p>
+<p>This waste comes from over-provisioning the containers in our pods.
+Read on to understand the reasons and perils of over-provsioning.</p>
 <h2 id="idle-resources">Idle Resources</h2>
 <p>Kubernetes comes with a promise of automatic bin packing. I.e - it is supposed to fit the largest possible amount of pods on every node in the cluster. But this is again dependent on engineers correctly defining 1) resource requests and 2) node sizes. Even with smart and well-tuned autoscaling tools like Karpenter this doesn't always work and we find ourselves with nodes that are more than half empty - with resources that were neither requested nor utilized. All these are <strong>idle resources</strong> and taking care of reducing them is an important focus area of Kubernetes Cost Optimization.</p>
 <h2 id="over-provisioning">Over Provisioning</h2>
+<p>Pinpointing the exact memory and CPU requests for our pods is hard - it requires observing the application behaviour under production load over a significant time period. 
+Therefore most engineers prefer to err towards <mark>overprovisioning</mark>  - i.e setting requests much higher than the application will ever use.</p>
+<p>This leads to a large amount of allocated but unutilized resources all across the cluster. Just imagine your cluster runs 200 pods and each of them requests 100Mb more memory than it actually uses. Altogether you'll have 20Gb of wasted RAM across the cluster. These resources will be provisioned, paid for, but never actually used.</p>
 <h2 id="under-provisioning">Under Provisioning</h2>
 <div id="mkdocs_search_modal" class="w3-modal">
   <div class="w3-modal-content">