In Kubernetes, do we still need multiprocess/gunicorn?
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.
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).