Kubernetes环境下Supervisord启动Celery偶发失败问题咨询

可能的故障原因 #

• 启动时序与依赖未就绪问题
  Celery 退出状态码2通常代表启动阶段连接Broker失败、配置加载失败类错误。你当前的容器启动逻辑中，Supervisord启动后会立刻拉起Celery，而Kubernetes Pod刚启动时，集群内部DNS解析、RabbitMQ Service的网络连通性可能还未完全就绪，Celery首次连接RabbitMQ超时就会直接退出。你当前的Supervisord配置中没有给Celery配置自动重启策略，且默认配置将状态码2判定为预期退出，不会触发重启，最终就会出现Celery进程消失的情况。你手动执行命令时Pod已经运行了一段时间，网络、DNS均已就绪，因此可以正常启动。
• 进程运行模式冲突问题
  你当前Supervisord配置中nodaemon = false，会以守护进程模式后台运行，而容器生命周期绑定的是前台运行的Gunicorn进程，Supervisord作为后台进程没有保活机制，偶发会出现容器运行时对后台子进程的误清理，或者Supervisord自身异常退出的情况，导致Celery进程被连带终止。
• 启动阶段资源竞争问题
  Pod启动时Supervisord拉起Celery和Gunicorn启动几乎是同时进行的，二者会抢占CPU、内存、文件句柄资源，如果Pod的resources配额配置较低，Celery启动时资源不足就会异常退出。你手动执行命令时Gunicorn已经启动完成，资源占用稳定，因此Celery可以正常获取资源启动。

修复建议 #

1. 调整Supervisord的Celery配置，添加自动重启策略，修改/etc/supervisor/conf.d/celery.conf中的[program:celery]段，新增以下配置：

autorestart = true
startretries = 10
startsecs = 5
exitcodes = 0

指定Celery异常退出时自动重启，最多重试10次，启动后稳定运行5秒才算启动成功，仅将退出码0判定为预期退出。
2. 统一容器进程管理，将Gunicorn也纳入Supervisord管理，修改Supervisord配置中的nodaemon = true，让Supervisord作为容器前台主进程运行，删除原有启动脚本中的Gunicorn启动命令，新增[program:gunicorn]配置段管理Gunicorn进程，避免多主进程带来的管理混乱。
3. 增加启动前置检查，在Celery启动前先执行脚本检查RabbitMQ端口连通性，确认Broker就绪后再启动Celery，避免启动时连接失败。

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