面向Kubernetes的Django应用WSGI服务器选型推荐

1. Gunicorn（优先保留，调整配置即可） #

你当前在用的Gunicorn完全适配K8s场景，核心是要改掉默认的worker数计算逻辑——它默认按物理CPU核数计算，在K8s的资源限制下会偏差很大。

• 解决方法：写个简单的启动脚本，从K8s的资源限制（通过cgroup文件或环境变量）获取实际可用CPU配额，再动态设置--workers参数。比如从/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us计算出可用核心数，再按workers = 可用核心数 * 2 + 1的规则设置（或根据你的应用负载调整比例）。
• 优势：生态成熟，和Django兼容性拉满，排查问题的文档和社区资源最多，轻量易配置。

2. Uvicorn + Gunicorn（适合异步需求） #

如果你的Django应用用到了异步视图（Django 3.0+支持），或者未来打算扩展异步能力，这套组合是更好的选择：

• Uvicorn作为异步ASGI服务器处理请求，Gunicorn负责管理进程池。在K8s资源受限的环境下，Uvicorn单worker的并发能力比传统WSGI服务器更强，能更高效利用有限的CPU和内存。
• 同样需要调整worker数的计算逻辑，适配K8s的资源限制，避免进程过多导致资源耗尽。

3. Hypercorn（纯异步备选） #

Hypercorn是纯Python实现的ASGI服务器，和Uvicorn功能类似，支持异步和WSGI兼容模式：

• 配置灵活，资源占用可控，适合资源紧张的K8s节点。如果你偏向全异步技术栈，或者想尝试替代Uvicorn，可以考虑它。
• 同样需要根据K8s的资源限制动态调整进程数，避免默认逻辑的偏差。

核心注意事项 #

不管选哪种服务器，核心都是不要依赖物理CPU核数计算worker数，必须基于K8s给Pod分配的实际资源配额来调整。通过读取cgroup的CPU限制文件，或者利用K8s注入的环境变量（部分集群支持），编写启动脚本动态设置进程数，才能在资源受限的环境下保证应用稳定高效运行。

内容的提问来源于stack exchange，提问作者guettli