<p>So, in my use case i need to scale up an application when an event happens in the system.</p>

<p>HPA will not help here - as i don't want the pods to scale down when the metric is met, nor i don't want the pods to keep scaling up (as what HPA does - scales up until it meets its criteria, and then scale down).</p>

<p>The scale down should happen when another event happens, thus the logic is:</p>

<ol>
<li>Event is raised in the system</li>
<li>Deployment is scaled by 1</li>
<li>Work continues</li>
<li>Another "scale down" event is raised from the system</li>
<li>Deployment is scaled down by 1</li>
</ol>

<p>Should i just write a different pod that accesses the k8s API and scales up/down the deployment? it feels to me that something like that already exists but i'm missing something</p>

<p>In this scenario I would look at admission <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#experimenting-with-admission-webhooks" rel="nofollow noreferrer">Webhooks</a>, a comprehensive way to interact with K8s API server that can modify the basic behavior of some Kubernetes features by representing a <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#response" rel="nofollow noreferrer">Dynamic admission control</a> model.</p>

<p>It means that you can implement special controllers that can intercept Kubernetes API requests, and modify or reject them based on custom logic.Thus, you can create either <code>ValidatingWebhookConfiguration</code> or <code>MutatingWebhookConfiguration</code> admission webhooks; the only difference validating webhooks can reject a request, but they cannot modify the object they are receiving in the admission HTTP request, while mutating webhooks can modify objects by creating a patch that will be sent back in the admission HTTP response. I would propose to get more relevant information in this <a href="https://medium.com/ibm-cloud/diving-into-kubernetes-mutatingadmissionwebhook-6ef3c5695f74" rel="nofollow noreferrer">tutorial</a>.</p>

<p>According to the above said, it might be feasible to scale up or down relevant deployment resource based on the mutating rules in <code>MutatingWebhookConfiguration</code> within <code>AdmissionReview</code> API object as described in the official K8s <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#webhook-request-and-response" rel="nofollow noreferrer">documentation</a>.</p>
