<p>I have a deploy in gke associated with an horizontal pod autoscaler, based on an external metric (pubsub subscription).</p>

<p>For some reason, the autoscaler is creating a ripple (or thrashing) effect on my pods, making them keep being scaled up and down to the same values each minute (as seem on the graph below).</p>

<p><a href="https://i.stack.imgur.com/eJxEt.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/eJxEt.png" alt="Graph of pods and nodes going up and down every 1 minute"></a></p>

<p><a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-cooldown-delay" rel="nofollow noreferrer">I found out</a> that there is a flag for the <em>kube-controller-manager</em> component that introduces a cooldown time between downscale events (<code>--horizontal-pod-autoscaler-downscale-stabilization</code>).</p>

<p>However, I can't access the configurations for the <em>kube-controller-manager</em> in GKE. Is there any workaround for it? And if it's impossible to configure it in GKE, is there another way to mitigate this effect?</p>

<p>GKE clusters are fully managed by Google which means the control plane (the master(s)) is hosted in a Google tenant project and fully managed by the platform. There is no way for you to make any changes to the master or any of the control plane components. </p>

<p>There is no way for you to add the <code>--horizontal-pod-autoscaler-downscale-stabilization</code> flag on GKE. </p>

<p>However, the end result you are trying to address is either due to an issue with how your HPA is configured (metric and/or metric thershhold) or possibly an issue with how the cluster is ingesting and consuming these metrics which is leading to this constant scale up and down. I strongly recommend reviewing the custom metric you are using to ensure it is a reliable source to base your pod scaling on.</p>
