Scrapy爬虫在Kubernetes Pod中运行至第1000项时自动停止求排查

核心现象定位 #

从提供的日志可以首先确认：爬虫是Scrapy主动正常退出的，finish_reason为finished，不存在K8s主动kill进程、程序崩溃的情况，且退出时刚好爬满1000条item，和描述的1000次请求后关闭的现象完全匹配。

优先排查方向（90%概率匹配问题） #

• 检查是否开启了Scrapy的CLOSESPIDER_ITEMCOUNT配置：该配置的作用就是指定爬虫爬满多少个Item后自动正常关闭，刚好和日志中item_scraped_count: 1000的数值吻合。
  可以在K8s Pod的启动命令中临时加入scrapy settings --get CLOSESPIDER_ITEMCOUNT验证输出，如果返回值为1000就可以确认是该配置导致的问题。
  本地运行没有触发是因为K8s环境的配置和本地不一致：大概率是K8s部署时通过ConfigMap挂载的配置文件、环境变量、启动命令行参数误加了-s CLOSESPIDER_ITEMCOUNT=1000的配置，而本地的settings.py没有设置该值。

其他次要排查方向 #

如果确认CLOSESPIDER_ITEMCOUNT没有被设置，可以继续排查以下点：

• 检查其他Scrapy自动关闭配置：确认CLOSESPIDER_PAGECOUNT、CLOSESPIDER_TIMEOUT等自动停止相关的配置是否在K8s环境被误设
• 检查爬虫代码逻辑：排查是否有自定义中间件、扩展中写了爬满1000条主动调用close_spider的逻辑，或者代码中存在根据环境变量判断（比如判定为生产环境就只爬1000条测试）的分支
• 验证K8s资源限制：执行kubectl describe pod <对应Pod名>查看Pod事件，确认是否存在OOMKilled、资源不足被驱逐的情况（该可能性极低，因为资源不足导致的进程退出不会打印完整的Scrapy统计日志）

内容的提问来源于stack exchange，提问作者Tín Trung