<p>Might be a strange one to ask, but found myself with:</p>
<ul>
<li>An AWS Simple Queue that holds messages to process.</li>
<li>A deployment in a Kubernetes cluster on Google Cloud (GKE) that processes this queue.</li>
</ul>
<p>I want to scale the deployment according to the queue size. A simple logic for example:</p>
<ul>
<li>Queue size = 0 =&gt; deploy 3 pods</li>
<li>Queue size 0 &gt; 10 &gt; 1000 =&gt; deploy 20 pods</li>
<li>Queue size &lt; 1000 =&gt; deploy 100 pods</li>
</ul>
<p>Turns out that this isn't such a simple task, and I'm looking for ideas.</p>
<p>I tried to achieve this via the Horizontal pod autoscaler, but it looks like an impossible task.</p>
<p>My best idea is an AWS Lambda that monitors the queue (by messages or a cron schedule), and updates the Kubernetes deployment via API.
The easy part was monitoring the queue size and getting the desired scale for the deployment, but I'm not managing to physically control the deployment size via the AWS Lambda.</p>
<p>TL:DR, I would like to achieve kubectl functionality (scale deployment), but via an external lambda running node.js code, while authenticating to my google cloud platform, And it seems really tricky as well. There are a few <a href="https://kubernetes.io/docs/reference/using-api/client-libraries/" rel="nofollow noreferrer">client libraries</a>, but none of them really documents how to authenticate and connect to my cluster.
I even thought about running the bash script from my deployment system - but running that through a lambda function using node.js 'exec' seems very very wrong.</p>
<p>Am I missing an easier way?</p>

<p>There's a project called Keda: <a href="https://keda.sh/docs/2.0/scalers/aws-sqs/" rel="nofollow noreferrer">https://keda.sh/docs/2.0/scalers/aws-sqs/</a>. It supports horizontal scaling basing on a bunch of queue types. SQS is supported.</p>
<p>To securely access SQS/CloudWatch from a GKE one can use <a href="https://github.com/doitintl/gtoken" rel="nofollow noreferrer">https://github.com/doitintl/gtoken</a> which lets you assume AWS role from a GKE. Or in a simpler and less secure way - dedicated AWS user with periodic keys rotation. Also look at <a href="https://cloud.google.com/pubsub/docs/overview" rel="nofollow noreferrer">https://cloud.google.com/pubsub/docs/overview</a>, perhaps you can replace your SQS to stay in one stack.</p>
