K8s中Pod同时显示Running与CrashLoopBackOff的原因排查

一、两种kubectl get pods输出不一致的原因 #

这是Pod状态动态变化导致的：

• kubectl get pods和kubectl get pods -o wide是两次独立的API请求，两次查询的间隙中Pod状态发生了切换：比如第一次查询时，Pod刚完成第5次重启，短暂进入Running（READY 1/1）状态，但进程很快异常退出，K8s随即把状态更新为CrashLoopBackOff（READY 0/1）。
• 重启次数的差异可能是因为K8s状态同步延迟，或者Pod在间隙中被重建（比如Deployment触发滚动更新），导致重启计数被重置。

二、Pod收到TERM信号退出的常见原因 #

1. 健康检查失败触发终止 #

如果Pod的**存活探针（livenessProbe）或就绪探针（readinessProbe）**配置不合理，K8s会判定Pod不健康，发送TERM信号终止容器并重启：

• 探针端口/路径错误：比如pgAdmin默认监听80端口，探针却配置了其他端口；PostgreSQL探针未用psql命令验证连接。
• 探针超时设置过短：进程刚启动还未完成初始化，就被探针判定为失败。

2. 容器进程未正确处理信号 #

部分镜像的启动脚本用shell执行（比如command: ["sh", "-c", "pgadmin4"]），shell进程默认不会将TERM信号转发给子进程。当K8s发送TERM时，shell直接退出，子进程（pgAdmin/PostgreSQL）也被强制终止。

3. 资源不足 #

节点CPU、内存资源耗尽时，kubelet会触发OOMKiller杀死进程，或因CPU throttling导致进程无法正常运行，最终触发退出。

4. 应用配置错误 #

• PostgreSQL：环境变量（如POSTGRES_PASSWORD、POSTGRES_USER）配置错误，或数据目录权限异常，导致初始化失败后主动退出。
• pgAdmin：配置文件错误、依赖缺失，导致启动后无法正常运行，主动退出。

三、排查步骤 #

1. 查看Pod事件详情
   执行以下命令查看Pod的事件日志，定位异常触发点：

   kubectl describe pod <pgadmin-pod-name>
   kubectl describe pod <postgres-pod-name>
   

   重点关注Events字段，是否有健康检查失败、资源不足、配置错误的提示。

2. 查看完整容器日志
   查看上一次退出前的完整日志，捕捉TERM信号出现前的错误信息：

   kubectl logs <pgadmin-pod-name> --previous
   kubectl logs <postgres-pod-name> --previous
   

3. 验证探针配置
   检查Deployment/Pod的探针配置，确保：

   • pgAdmin的探针使用80端口，路径为/（或对应健康检查路径）
   • PostgreSQL的探针使用psql -U <user> -c "SELECT 1"验证连接
   • 探针的initialDelaySeconds设置足够长，给应用留足初始化时间

4. 检查资源限制
   确认Pod的resources字段配置了合理的requests和limits，避免因资源不足被终止：

   resources:
     requests:
       cpu: "100m"
       memory: "256Mi"
     limits:
       cpu: "500m"
       memory: "512Mi"
   

5. 修复信号传递问题
   如果使用自定义启动命令，改用exec形式（避免shell包裹），确保信号能传递给应用进程：

   command: ["/usr/local/bin/pgadmin4"]  # 正确写法
   # 避免：command: ["sh", "-c", "/usr/local/bin/pgadmin4"]
   

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