In Kubernetes, do we still need multiprocess/gunicorn?

Question

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).

Answer 1

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.

Answer 2

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).

Answer 3

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.