<p>We have a Flask application that is served via gunicorn, using the eventlet worker. We're deploying the application in a kubernetes pod, with the idea of scaling the number of pods depending on workload.</p>

<p>The recommended settings for the number of workers in gunicorn is <code>2 - 4 x $NUM_CPUS</code>. See <a href="https://docs.gunicorn.org/en/stable/settings.html#workers" rel="noreferrer">docs</a>. I've previously deployed services on dedicated physical hardware where such calculations made sense. On a 4 core machine, having 16 workers sounds OK and we eventually bumped it to 32 workers.</p>

<p>Does this calculation still apply in a kubernetes pod using an async worker particularly as:</p>

<ol>
<li>There could be multiple pods on a single node.</li>
<li>The same service will be run in multiple pods.</li>
</ol>

<p>How should I set the number of gunicorn workers? </p>

<ol>
<li>Set it to <code>-w 1</code> and let kubernetes handle the scaling via pods?</li>
<li>Set it to <code>2-4 x $NUM_CPU</code> on the kubernetes nodes. On one pod or multiple?</li>
<li>Something else entirely?</li>
</ol>

<h1>Update</h1>

<p>We decided to go with the 1st option, which is our current approach. Set the number of gunicorn works to 1, and scale horizontally by increasing the number of pods. Otherwise there will be too many moving parts plus we won't be leveraging Kubernetes to its full potential.</p>

<p>For better visibility of the final solution chosen by original author of this question as of 2019 year</p>
<blockquote>
<p>Set the number of gunicorn works to 1 (-w 1), and scale horizontally
by increasing the number of pods (using Kubernetes HPA).</p>
</blockquote>
<p>and the fact it might be not applicable in the close future, taking into account fast growth of workload related features in Kubernetes platform, e.g. some distributions of Kubernetes propose beside HPA, Vertical Pod Autoscaling (VPA) and  Multidimensional Pod autoscaling (MPA) too, so I propose to continue this thread in form of community wiki post.</p>
