<p>HPA - How to avoid scaling-up for CPU utilization spike (not on startup)
When the business configuration is loaded for different country CPU load increases for 1min, but we want to avoid scaling-up for that 1min. </p>

<p>below pic, CurrentMetricValue is just current value from a matrix or an average value from the last poll to current poll duration --horizontal.-pod-autoscaler-sync-period</p>

<p><a href="https://i.stack.imgur.com/daVUt.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/daVUt.png" alt="enter image description here"></a></p>

Sandip Jadhav
<p>The default HPA check interval is 30 seconds. This can be configured through the as you mentioned by changing value of flag <code>--horizontal-pod-autoscaler-sync-period</code> of the controller manager.</p>

<p>The Horizontal Pod Autoscaler is implemented as a control loop, with a period controlled by the controller manager’s --horizontal-pod-autoscaler-sync-period flag.</p>

<p>During each period, the controller manager queries the resource utilization against the metrics specified in each HorizontalPodAutoscaler definition. The controller manager obtains the metrics from either the resource metrics API (for per-pod resource metrics), or the custom metrics API (for all other metrics).</p>

<p>In order to change/add flags in kube-controller-manager - you should have access to your <code>/etc/kubernetes/manifests/</code> directory on master node and be able to modify parameters in <code>/etc/kubernetes/manifests/kube-controller-manager.yam</code>l.</p>

<p>Note: you are not able do this on GKE, EKS and other managed clusters.</p>

<p>What is more I recommend increasing <code>--horizontal-pod-autoscaler-downscale-stabilization</code> (the replacement for <code>--horizontal-pod-autoscaler-upscale-delay</code>).</p>

<p>If you're worried about long outages I would recommend setting up a custom metric (1 if network was down in last <code>${duration}</code>, 0 otherwise) and setting the target value of the metric to 1 (in addition to CPU-based autoscaling). This way:</p>

<p>If network was down in last <code>${duration}</code> recommendation based on the custom metric will be equal to the current size of your deployment. Max of this recommendation and very low CPU recommendation will be equal to the current size of the deployment. There will be no scale downs until the connectivity is restored (+ a few minutes after that because of the scale down stabilization window).</p>

<p>If network is available recommendation based on the metric will be 0. Maxed with CPU recommendation it will be equal to the CPU recommendation and autoscaler will operate normally.
I think this solves your issue better than limiting size of autoscaling step. Limiting size of autoscaling step will only slow down rate at which number of pods decreases so longer network outage will still result in your deployment shrinking to minimum allowed size.</p>

<p>You can also use memory based scaling</p>

<p>Since it is not possible to create memory-based hpa in Kubernetes, it has been written a script to achieve the same. You can find our script here by clicking on this link:</p>

<pre><code>https://github.com/powerupcloud/kubernetes-1/blob/master/memory-based-autoscaling.sh
</code></pre>

<p>Clone the repository :</p>

<pre><code>https://github.com/powerupcloud/kubernetes-1.git
</code></pre>

<p>and then go to the Kubernetes directory. Execute the help command to get the instructions:</p>

<pre><code>./memory-based-autoscaling.sh --help
</code></pre>

<p>Read more here: <a href="https://www.powerupcloud.com/autoscaling-based-on-cpu-memory-in-kubernetes-part-ii/" rel="nofollow noreferrer">memory-based-autoscaling</a>.</p>
