Kubernetes存活探针致部分容器停止失败的原因及解决办法

一、让所有容器成功停止的方法 #

1. 改用共享PID Namespace直接发送终止信号（推荐） #

存活探针失败触发终止的方式依赖镜像对Kubernetes终止信号的处理逻辑，部分镜像可能存在兼容问题。改用Pod共享PID命名空间，让定时任务容器直接向长期运行容器的主进程发送终止信号，可彻底绕过探针依赖：

• 在Pod配置中添加shareProcessNamespace: true，使同一Pod内的容器共享进程空间；
• 定时任务容器的执行命令调整为：

  # 保留原stop文件逻辑（可选，兼容原有检测逻辑）
  touch /cache/stop
  # 定位长期运行容器的主进程PID（替换为目标容器的主进程名，如httpd、python等）
  TARGET_PID=$(pgrep -f "nginx: master process")
  # 先发送SIGTERM尝试优雅终止，等待10秒后发送SIGKILL强制终止（可根据镜像调整等待时长）
  kill -TERM $TARGET_PID
  sleep 10
  kill -KILL $TARGET_PID 2>/dev/null
  

  若不确定目标进程名，可通过ps aux在容器内排查，或基于镜像的ENTRYPOINT命令定位。

2. 调整存活探针逻辑适配镜像 #

若必须保留探针触发方式，修改探针逻辑避免直接触发容器异常终止：

• 调高存活探针的failureThreshold参数，给容器足够的优雅停止缓冲时间；
• 将探针的exec命令改为主动执行容器停止逻辑，而非仅检测文件：

  if [ -f /cache/stop ]; then
    # 替换为目标容器的官方停止命令，如nginx的`nginx -s stop`
    /usr/sbin/nginx -s stop
    exit 0
  else
    exit 0
  fi
  

  这种方式让容器主动执行停止流程，而非被动等待Kubernetes因探针失败强制终止。

二、强制Job/Pod处于成功状态的方法 #

1. 确保容器退出码为0 #

Job的成功判定依赖所有容器的退出码为0，需做到：

• 定时任务容器执行完成后必须以exit 0退出，避免因命令执行失败导致非0退出码；
• 若长期运行容器无法优雅退出返回0，可通过共享PID的定时容器直接终止其进程，让定时容器的退出状态主导Job的成功判定。

2. 调整Job的重启策略与完成条件 #

• 将Job的restartPolicy设置为Never，避免容器失败后反复重启触发回退限制；
• 若仅需定时任务完成即可标记Job成功，可设置activeDeadlineSeconds限制Job运行时长，确保定时任务在截止时间前完成，Job自动终止并标记成功。

3. 手动强制修改Job状态（临时应急） #

若需临时将失败Job标记为成功，可通过kubectl patch直接修改状态：

kubectl patch job <job-name> -p '{"status":{"succeeded":1,"failed":0}}'

注意：此操作仅修改状态，不改变容器实际运行情况，仅适用于应急场景。

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