<p>In a machine-oriented deployment, usually, people would use <code>gunicorn</code> to spin up a number of workers to serve incoming requests. (yes, the <code>worker_class</code> would further define the behavior within the worker process)</p>
<p>When deploying in a Kubernetes cluster, do we still <code>gunicorn</code> (or to be exact, do we still need multiprocess deployment)?</p>
<p>Basically, each running container is a process (in the one-container-per-pod config). Multiple pods running behind a service is already equivalent to what <code>gunicorn</code> has to offer. In other words, rely on Kubernetes service instead of <code>gunicorn</code></p>
<p>Is <code>gunicorn</code> still needed?</p>
<p>Yes, a pod is not exactly the same as a process (some overhead in each pod for the companion container), but other than that, anything else we may miss from not having <code>gunicorn</code>?</p>
<h1>Edited</h1>
<p>Clarification: yes, still need <code>gunicorn</code> or other <code>wsgi</code> <code>http</code> server to run the python app. My question is really about the <code>multiprocess</code> aspect (as the <em>multiprocess/gunicor</em> in the title).</p>

webp
<p>Gunicorn is used to serve WSGI(Web Server Gateway Interface) applications so it is a server and not just multiprocess orchestration tool. Kubernetes on the hand is an orchestration tool that helps manage the infrastucture. It does not speak HTTP nor does it know anything about WSGI specs. 
In other words, you can't run WSGI applications on bare kubernetes pods, you will still need a WSGI server liike Gunicorn, uWSGI, etc to serve the application. </p>
