Gunicorn worker terminated with signal 9故障排查：K8s部署Flask应用如何定位worker被杀原因

Signal 9即SIGKILL，属于强制终止信号，结合你提到的Pod无重启、整体资源使用率未超限制的前提，可以按以下顺序排查：

1. 确认是否为OOM killer触发的进程查杀 #

• 先查看Pod OOM记录：执行kubectl describe pod <目标Pod名称>，检查Last State字段，如果无OOM标记，说明Pod整体未触及内存限制，属于cgroup或节点级OOM killer单独查杀worker进程，未触发Pod重启
• 登录Pod调度的节点，执行dmesg -T | grep -i oom查看内核日志，如果能找到对应PID（比如告警中的26）的kill记录，即可确认是内存超限触发查杀。注意你观测到的80%内存使用率是监控采样平均值，大内存请求引发的瞬时峰值大概率不会被低频率的采样监控捕获
• 排查节点是否存在内存压力：执行kubectl describe node <节点名称>查看Conditions字段，若存在MemoryPressure状态，kubelet会主动释放资源，优先杀掉内存占用高的单进程，哪怕Pod总用量未达limits

2. 排查Gunicorn配置问题 #

• 检查--timeout超时配置：如果单个请求处理时长超过阈值，Gunicorn主进程会先发送SIGABRT尝试终止worker，若worker卡住无响应，后续会发送SIGKILL强制查杀
• 检查max_requests/max_requests_jitter配置：这两个参数用于控制worker处理指定请求数后主动重启，避免内存泄漏，若worker退出时卡住无法正常终止，也会触发SIGKILL
• 检查worker数量配置：若worker数开得过多，叠加单worker的内存峰值后总用量接近Pod limits，也容易触发OOM

3. 排查业务代码异常 #

• 开启Gunicorn debug日志：启动参数添加--log-level debug，记录worker被杀前正在处理的请求，缩小问题范围
• 排查内存泄漏：确认是否有请求处理后大对象未释放，长期运行后worker内存持续升高最终触发OOM
• 排查长耗时任务：确认是否存在CPU密集型/IO阻塞的长任务，导致worker无法响应主进程的终止信号，被强制查杀

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