Kubernetes中dramatiq进程遭SIGKILL(-9)终止，如何排查并获取更多日志？

日志里的code -9对应SIGKILL信号，这是系统强制终止进程的标记，除了常规内存超限，还有多种潜在原因，以下是具体排查步骤：

一、获取Pod的核心状态与事件 #

• 查看Pod的完整事件日志，Kubernetes会记录调度、资源相关的关键操作：

  kubectl describe pod <你的Pod名称> -n <命名空间>
  

  重点关注Events区块，排查是否存在OOMKilled（即便你认为内存没超，也可能是容器cgroup限制或节点瞬时内存压力触发）、NodePressure这类异常提示。
• 查看Pod的实时资源占用，确认是否有瞬间内存尖峰：

  kubectl top pod <你的Pod名称> -n <命名空间> --containers
  

  如果集群部署了metrics-server，这个命令能展示容器级别的资源使用；若有Prometheus，可查看历史资源曲线，排查短时间内存突增触发OOM的可能性。

二、检查节点层面的资源压力 #

Pod被强制终止可能源于节点整体资源不足，kubelet触发了驱逐机制：

• 先通过kubectl get pod <Pod名称> -o wide找到Pod所在节点的IP，登录节点后查看kubelet日志：

  journalctl -u kubelet -f
  

  搜索SIGKILL、OOM、evict关键词，确认是否有节点层面的资源回收操作。
• 查看节点的内存与磁盘使用情况：

  free -h
  df -h
  

  节点内存耗尽或磁盘空间满（比如容器镜像存储目录），都会触发kubelet杀死Pod。

三、增强Dramatiq的日志输出 #

默认日志粒度不足，可修改Pod配置开启更详细的日志：

• 在Pod的环境变量或启动命令中添加调试参数：

  env:
    - name: DRAMATIQ_LOG_LEVEL
      value: "DEBUG"
  command: ["dramatiq", "你的任务模块", "--verbose"]
  

  这样能捕获Worker进程退出前的更多细节，比如是否在执行某任务时出现异常。

四、验证容器的资源配置 #

确认Pod的资源限制与请求设置是否合理：

• 查看Pod的资源配置详情：

  kubectl get pod <Pod名称> -o yaml | grep -A 10 resources
  

  检查limits.memory和requests.memory的数值，若requests设置过低，Pod可能被调度到资源紧张的节点，后续触发OOM；另外部分容器运行时（如containerd）存在默认内存限制，需确认是否被触发。

五、跟踪进程级别的系统调用 #

若以上排查无结果，可通过工具跟踪进程的系统调用，定位潜在问题：

• 进入Pod并安装strace工具（以Debian/Ubuntu镜像为例）：

  kubectl exec -it <Pod名称> -n <命名空间> -- /bin/bash
  apt update && apt install -y strace
  

• 跟踪目标Worker进程的系统调用：

  strace -p <Worker进程PID>
  

  这样能看到进程终止前的所有系统操作，定位是否因依赖库崩溃、系统调用异常导致被杀死。

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