解决AWS EKS中Celery Pod未完成任务被K8s强制终止问题

方案一：结合Celery优雅关闭与K8s滚动更新策略 #

• 启动Celery Worker时开启优雅关闭参数，让Worker停止接收新任务并等待现有任务完成：

  celery -A your_django_project worker --loglevel=info --soft-timeout=3600 --time-limit=3700 --autoscale=5,2
  

  其中--soft-timeout设为你的最长任务运行时间（示例为1小时），--time-limit比软超时多留缓冲时间，避免任务无限制运行。
• 在K8s Deployment中配置滚动更新策略，保证更新期间不减少可用副本数，同时设置足够长的终止宽限期：

  spec:
    replicas: 3
    strategy:
      rollingUpdate:
        maxSurge: 1
        maxUnavailable: 0
      type: RollingUpdate
    template:
      spec:
        terminationGracePeriodSeconds: 3700
        containers:
        - name: celery-worker
          image: your-image:tag
          command: ["celery", "-A", "your_django_project", "worker", "--loglevel=info", "--soft-timeout=3600", "--time-limit=3700", "--autoscale=5,2"]
          lifecycle:
            preStop:
              exec:
                command: ["celery", "-A", "your_django_project", "control", "shutdown"]
  

  preStop钩子发送shutdown命令触发Celery优雅停止，宽限期要覆盖--time-limit的时间，确保K8s不会提前强制杀死Pod。

方案二：分离长/短任务队列，针对性处理更新 #

• 将运行时间超过1小时的长任务单独路由到专用队列（比如long_tasks），部署独立的Worker Deployment消费该队列：

  celery -A your_django_project worker --loglevel=info --queue=long_tasks --soft-timeout=7200 --time-limit=7300
  

• 针对长任务Worker，在CI/CD更新流程中先暂停任务消费，等待队列清空后再触发Deployment更新：

  # 暂停长任务队列的消费
  celery -A your_django_project control cancel_consumer long_tasks
  # 等待队列任务完成（循环查询队列长度，直到为0）
  while [ $(celery -A your_django_project inspect active_queues | grep -oP 'long_tasks.*?messages:\s*\K\d+') -gt 0 ]; do sleep 60; done
  # 触发K8s Deployment更新
  kubectl rollout restart deployment/celery-worker-long
  

• 短任务Worker可使用常规滚动更新，因为任务执行时间短，默认宽限期即可覆盖。

方案三：自定义就绪探针，延迟Pod终止 #

• 编写就绪探针脚本，检测Worker是否有活跃任务，只有当无活跃任务时，K8s才会将Pod纳入滚动更新的终止列表：

  spec:
    template:
      spec:
        containers:
        - name: celery-worker
          readinessProbe:
            exec:
              command:
              - sh
              - -c
              - "celery -A your_django_project inspect active | grep -q '\\[\\]' || exit 1"
            initialDelaySeconds: 30
            periodSeconds: 60
            failureThreshold: 1
  

  探针逻辑：如果celery inspect active返回空列表（无活跃任务），探针成功；否则失败，K8s不会终止该Pod，直到任务完成探针返回成功。

注意事项 #

• 确保Redis代理连接稳定，Worker能及时接收shutdown信号和任务状态变更；
• 长任务的soft-timeout和K8s终止宽限期需根据实际任务最长运行时间调整，避免设置过长导致资源浪费，或过短导致任务被强制终止。

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