本文总结了排障中经常使用到的几种方法，解决你的痛点，让你不再走弯路。

一、问题现场：CrashLoopBackOff 的真实困境
典型现象：

复制
kubectl get pod
1.
复制
NAME                  READY   STATUS             RESTARTS
nignx-xxx      0/1     CrashLoopBackOff   17
1.
2.
常见痛点包括：

容器启动即退出，看不到日志
kubectl exec 进不去
kubectl logs 日志不完整
不清楚镜像里到底有什么配置
二、核心思路：让容器“别死”
一句话总结：只要能让容器先活着，就一定能进去排障。

下面是我在生产中最常用、也最稳的 3 种方式。

1. 方式一：直接用 docker run 查看镜像内容（最快）
使用场景：

只想确认镜像内文件是否存在
不依赖 Kubernetes
本地或节点上能拉到镜像
示例：查看镜像内目录

复制
# 查看容器内某个目录文件或者权限
docker run --rm -ti  --entrypoint ls -l /opt reg.nginx.test:5000/dev/nginx:master_amd64 
# 通过entrypoint替换镜像启动命令进去镜像中
docker run -ti --rm --entrypoint=/bin/sh reg.nginx.test:5000/dev/nginx:master_amd64
1.
2.
3.
4.
这个命令做了什么？

参数

说明

--rm

退出即删除容器

-ti

交互式终端

--entrypoint ls

覆盖镜像原有启动命令

-l /var/cache

查看指定目录

2. 方式二：其它方式让容器不退出
复制
#方式一
docker run -d --name \
nginx-test reg.nginx.test:5000/dev/nginx:master_amd64 \
tail -f /dev/null
#方式二
docker run -d \
  --name init-job-test \
  --entrypoint sh \
  nginx-test reg.nginx.test:5000/dev/nginx:master_amd64 \
  -c "while true; do sleep 3600; done"
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
非常适合快速验证：

配置文件是否存在
路径是否写错
镜像构建是否完整
三、K8s 场景下，让 Pod 先“活着”
1. 场景说明
容器一启动就退出，导致：

Pod 一直 CrashLoopBackOff
无法 exec
日志刷不出来
2. 方法一：临时修改 Deployment 中开启 TTY
复制
spec:
  containers:
  - name: app
    image: xxx
    tty: true
1.
2.
3.
4.
5.
作用说明：

保持标准输入
防止容器因无前台进程立即退出
适用于启动脚本是 shell、程序较轻的场景
2. 方法 二（更稳）：让容器 sleep infinity
复制
containers:
- name: app
  image: xxx
  command: ["sleep", "infinity"]
1.
2.
3.
4.
这是我个人最推荐的方式。

为什么？

容器不会退出
Pod 状态直接变为 Running
可以随意 kubectl exec 进去查看
四、方式三：docker-compose / 镜像启动脚本排障
使用场景：

本地 docker-compose 启动即退出
怀疑镜像 ENTRYPOINT / CMD 有问题 启动脚本写在镜像里
解决方法：覆盖启动命令

复制
services:
  app:
    image: xxx
    command: sleep infinity
1.
2.
3.
4.
然后：

复制
docker-compose up -d
docker exec -it app bash
1.
2.
适合分析：

ENTRYPOINT 执行顺序
启动脚本错误
环境变量是否缺失
五、关于 restartPolicy 的重要说明（K8s 必看）
复制
restartPolicy: Never
1.
为什么要加？

防止容器不断重启
适合 一次性排障
否则 Pod 会被 kubelet 一直拉起、杀死
尤其适用于临时调试 Po