<p>I was wondering if the auto scaling feature in kubernetes is a reactive approach or proactive approach and if they are rule based only</p>
<p>please let me know</p>
<p>Thank you</p>

Thivya Thogesan
<p>It entirely depends on how you define <strong>reactive</strong> and <strong>proactive</strong>. From one hand I would say <strong>reactive</strong> as the metrics, autoscaling decision is based upon, need to reach a certain value so the autoscaling process can take place. An action is <strong>proactive</strong> only when it is based on prediction or anticipation of certain events e.g. load increase e.g. you are expecting that due to promotion campaing you're launching next week, the load on your app will increase about 3 times.</p>
<p>I would encourage you to take a closer look at <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details" rel="nofollow noreferrer">autoscaling algorithm details</a>.</p>
<p>From the most basic perspective, the Horizontal Pod Autoscaler controller operates on the ratio between desired metric value and current metric value:</p>
<blockquote>
<pre><code>desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
</code></pre>
<p>For example, if the current metric value is  <code>200m</code>, and the desired
value is  <code>100m</code>, the number of replicas will be doubled, since
<code>200.0 / 100.0 == 2.0</code>  If the current value is instead  <code>50m</code>, we'll
halve the number of replicas, since  <code>50.0 / 100.0 == 0.5</code>. We'll skip
scaling if the ratio is sufficiently close to 1.0 (within a
globally-configurable tolerance, from the
<code>--horizontal-pod-autoscaler-tolerance</code>  flag, which defaults to 0.1).</p>
</blockquote>
<p>As you can see the <strong>desired number of replicas</strong> is calculated based on a <strong>current metric value</strong> and only if this value reaches the certain critical point, the autoscaling process is triggered. So it's 100% reactive from this perspective.</p>
<p>Looking at the problem from different point of view, the decision about using <strong>horizontal pod autoscaler</strong> is kind of <strong>proactive</strong> approach. But now I'm talking about user's approach to managing their infrastructure, not about the mechanism of the <strong>hpa</strong> itself as I described above. Suppose you don't use <strong>horizontal pod autoscaler</strong> at all and you have sometimes unexpected load increases on your rigidly fixed set of pods that youre application is running on and due to those increases your application often becomes unavailable.</p>
<p>If you administer such environment manually, your <strong>reaction</strong> in such a situation is the decision about <strong>scaling</strong> your <code>Deployment</code> out. You will probably agree with me that this is totally reactive approach.</p>
<p>However if you decide to use <strong>hpa</strong>, you <strong>proactively anticipate</strong> the occurance of such load increases. It gives you the possibility of being always one step ahead and react automatically before the situation occurs. So if you decide to scale out your <code>Deployment</code> when the CPU usage reaches the certain treshhold e.g. 50% (still safe for the application so it continues running), the <strong>hpa</strong> automatically handles the situation for you, based on your predictions. However the <strong>horizontal pod autoscaler's</strong> reaction is <strong>reactive</strong> (reaction on exceeded treshhold), at the same time infrastructure autoscaling in such moment is <strong>proactive</strong>, as the <strong>autoscaler</strong> steps into action before the situation becomes critical.</p>
<p>I hope this has shed some light on your understanding of the problem.</p>
