<p>I'm trying(learning) to figure out the best way to utilize CPU (and RAM) on k8s <strong>nodes</strong>.
My final goal is to make sure CPU utilization on each node in the cluster is above X%</p>
<p>Till now I've read about <a href="https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler" rel="nofollow noreferrer">cluster-autoscaler</a> and <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/" rel="nofollow noreferrer">HPA</a>, but not sure if they'd help me with the use case.</p>
<p>From what I've read:</p>
<ul>
<li><code>cluster-autoscaler</code> is used to autoscale nodes based on a comparison between replica count and <code>resources.request</code> Vs available CPU on the target ec2 instance - which is NOT based on traffic/actual CPU usage</li>
<li><code>HPA</code> is based on CPU/actual cpu usage, but for individual pods</li>
</ul>
<p>I essentially wanna get to a point where <code>kubectl top nodes</code> would show all nodes are using &gt; X% (let's say 60%) - and ideally trigger the autoscaling if we reach X2% (let's say 80%)</p>
<p>any suggestion/pointer on how to go about this use case? (or I should somehow use the combination of these 2 autoscaling mechanisms)</p>

Mahyar
<p>You can a combination of the HPA or/and Cluster autoscaler and/or the cloud providers' autoscaling group.</p>
<ul>
<li><p>HPA based on CPU/Memory of your pods and scale up and down your K8s Deployments for example.</p>
</li>
<li><p>Cloud provider ASG or autoscaling group. Using the VMs or instances based and you can scale up and down based on their own CPU and memory metrics.</p>
</li>
<li><p>Cluster autoscaler. It works when pods are pending and they have nowhere to run, but if you are handling the case above this is more of a safe fail mechanism or perhaps for workloads that don't require to come up very quickly.</p>
</li>
</ul>
<p>In summary, you can use all 3 above (or less) but you have to see what works for you so that they don't conflict with each other. One potential problem is that when your cloud ASG starts scaling down then you also have pods in pending state then your cluster autoscaler (if you have it enabled) will kick in and you may have both of them trying to do the opposite causing your cluster to just not being able to schedule any pod.</p>
<p>✌️☮️</p>
