In Kubernetes, do we still need multiprocess/gunicorn?
It really depends on your use-cases. There is no right on wrong here if one solution suits you better than the other.
We have a similar use-case.
We are running about 30 replica's of the same service. Each pod runs 1 container, which again runs 50 duplicate services.
We could have ended up with 1500 pods running one service, but we've tested that the performance vs. required resources was much better when running only 30 replicas, which runs 50 services per replica.
The only thing we are doing extra is monitoring those 50 services per pod, so if one of them stops, it's being restarted. If all of them have some error, we run a healthcheck on the pod, and the pod is recreated.
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?
Edited
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).