In a machine-oriented deployment, usually, people would use gunicorn to spin up a number of workers to serve incoming requests. (yes, the worker_class would further define the behavior within the worker process)
When deploying in a Kubernetes cluster, do we still gunicorn (or to be exact, do we still need multiprocess deployment)?
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 gunicorn has to offer. In other words, rely on Kubernetes service instead of gunicorn
Is gunicorn still needed?
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 gunicorn?
Clarification: yes, still need gunicorn or other wsgi http server to run the python app. My question is really about the multiprocess aspect (as the multiprocess/gunicor in the title).
Is gunicorn still needed?
It's not needed really. Kubernetes can handle scaling up and down (pods/containers) the same way that gunicorn does using for example an HPA or a VPA, combined with other things like the cluster autoscaler.
The fact that you don't need it, it doesn't need you can't use gunicorn. You can perfectly have multiple processes in a pod/container controlled by resource limits. Keep in mind that the Kubernetes resource manager will ultimately dictate what the requested and the upper bound for a resource will be for your containers (running in a pod).
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.