排查定位
Init 容器必须按声明顺序逐个成功退出，全部完成之后主容器才会启动；任何一个卡住或反复失败，整个 Pod 就停在 Init 阶段。适用平台是 Kubernetes。排查的入口非常明确：先看 Pod 状态里的 Init:x/y 判断卡在哪个容器，再用 kubectl logs -c <容器名> 看它的输出，最后用 describe 里的退出码判断是命令写错、依赖不可达还是权限不足。
基本信息
| 适用平台 | Kubernetes，Pod 级 spec.initContainers |
|---|---|
| 状态信息 | Pod STATUS 形如 Init:0/2、Init:1/2、Init:Error、Init:CrashLoopBackOff |
| 日志读取 | kubectl logs <pod> -c <init容器名>，--previous 看上一次尝试 |
| 重试方式 | 按 Pod 的 restartPolicy 重试，always 与 onfailure 都会重启 init 容器 |
典型使用场景
- Pod 长时间停在 Init 状态：确认是哪一个 init 容器卡住
- 新上线服务起不来：检查依赖等待逻辑里的地址、端口、命名空间是否写对
- 权限类报错：init 容器以非 root 运行却要写挂载目录，报 permission denied
- 日志为空但状态异常：init 容器未执行过或立即崩溃，需要看 describe 而非 logs
- 排查完顺手核对超时设置：无限等待会让故障 Pod 永远占位
查看进度与日志
查看进度与日志
kubectl get pod web-x -o wide # STATUS 形如 Init:1/2
kubectl logs web-x -c init-data # 指定 init 容器看日志
kubectl logs web-x -c init-data --previous # 上一次尝试的输出
kubectl describe pod web-x | sed -n '/Init Containers/,/Containers/p' # 退出码与原因
kubectl get pod web-x -o jsonpath='{.status.initContainerStatuses[*].state}'状态与原因对照
| 状态 | 含义 | 首要动作 |
|---|---|---|
| Init:1/2 | 第一个成功、第二个未完成 | 看第二个容器的日志 |
| Init:Error | 某 init 容器非 0 退出 | describe 看退出码与 Reason |
| Init:CrashLoopBackOff | 反复启动即失败 | 命令、依赖或权限问题 |
| Init:0/2 长时间不变 | 第一个容器还在等待 | 确认它探测的地址与超时 |
init 容器失败会按 Pod 的 restartPolicy 重试；等待外部依赖时先确认它探测的地址、端口与超时设置，而不是先怀疑网络。
init 容器与主容器不共享文件系统，只共享网络与卷；跨容器传递数据必须通过挂载卷，这是「init 写了文件主容器看不到」的常见原因。
定位顺序建议
- 先读 Pod STATUS 的 Init:x/y 确定卡点，避免在多个容器之间来回翻日志
- 再用 kubectl logs -c 看卡住那个容器的输出，失败信息通常就在最后几行
- 接着 describe 看退出码与 Reason：非 0 退出与权限错误指向不同方向
- 最后回到清单核对命令、探测地址、挂载方式与安全上下文，改完让 kubelet 自动重试