I've always been a bit confused by this deployment model.
gunicorn bills itself as "Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model."
uvicorn's one-liner "Uvicorn is a lightning-fast ASGI server implementation, using uvloop and httptools."
So it seems redundant at first to be running both, but what the gunicorn+uvicorn-worker-process pattern really does is throw away the "WSGI HTTP Server" part of gunicorn and just use the "pre-fork worker" process management part, with the underlying processes actually being ASGI.
If you run in a different kind of process-management environment like k8s, does running gunicorn+uvicorn give you anything else?
Gunicorn fundamentally runs everything as a worker process.
You have sync, gthread, gevent, evenlet, tornado (tornado was also a popular server). UvicornWorker is another type of gunicorn worker... incidentally authored by the same guys who built uvicorn.
Nothing strange at all.
But ur question is genuine - but it is orthogonal to the uvicorn part of this answer. Fundamentally, in a k8s model...why bother with gunicorn?
The answer: I don't know. I do love the control that gunicorn gives me...so I'd probably use it even if I was using a single worker.
However there is a complex answer with Threads vs cores vs pods that I'm unqualified to give.
gunicorn bills itself as "Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model."
uvicorn's one-liner "Uvicorn is a lightning-fast ASGI server implementation, using uvloop and httptools."
So it seems redundant at first to be running both, but what the gunicorn+uvicorn-worker-process pattern really does is throw away the "WSGI HTTP Server" part of gunicorn and just use the "pre-fork worker" process management part, with the underlying processes actually being ASGI.
If you run in a different kind of process-management environment like k8s, does running gunicorn+uvicorn give you anything else?