AKS中CPU满载时请求丢失，WSGI或手动队列方案是否可行？

关于WSGI（如Waitress）请求排队的有效性 #

Waitress这类WSGI服务器的请求队列是在Flask应用处理之前工作的——它会先接收请求并存入队列，再逐个交给Flask实例处理。但核心局限在于：

• 若容器CPU被500m上限完全占死（比如Flask处理逻辑耗尽所有CPU），Waitress的主线程可能无法及时处理新请求连接，请求仍会被Kubernetes节点或负载均衡器丢弃；
• 仅当容器还有少量剩余CPU时，Waitress的轻量入队逻辑才能正常运行，此时能避免请求直接丢失，转为队列等待。

本地Docker与AKS的差异在于：本地默认无严格CPU限制，即使使用率高，系统仍有剩余资源给WSGI处理入队；而AKS的500m是硬限制，CPU耗尽后进程调度会极度缓慢，甚至无法响应新连接。

手动实现请求队列的困境 #

手动队列（如写入Redis/数据库）确实会遇到同样问题：如果Flask连接收请求并写入队列的CPU资源都没有，方案直接失效。写入队列的操作本身需要消耗少量CPU，容器CPU满负荷时，Flask进程根本无法响应新请求，更别说完成入队操作。

可行优化方向 #

• 调整HPA参数：将CPU使用率触发阈值调低（比如从80%降至60%），让自动扩缩容更早启动；同时调大maxSurge和maxUnavailable参数，加快Pod扩容速度，缩短等待窗口。
• 提升单Pod CPU配额：若业务允许，适当提高单个Pod的CPU请求和限制（比如从500m升至1核），增强单Pod的并发处理能力，降低扩缩容压力。
• 负载均衡层排队：用AKS的Ingress Controller（如NGINX Ingress）配置请求队列，将超出Pod处理能力的请求暂存在Ingress层而非直接丢弃。例如NGINX可通过proxy-buffering和queue指令实现排队，让请求在Ingress层等待至有空闲Pod可用。
• 异步处理非实时请求：对不需要即时响应的请求，改用消息队列（如Azure Service Bus、Redis Queue），让Flask仅负责接收请求并放入队列，由独立Worker Pod异步处理。这种模式下Flask的接收操作极轻量，即使CPU满负荷也能快速完成入队，避免请求丢失。

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