Kubernetes Init:Error / Init:CrashLoopBackOff — init 容器失败

症状

遇到“Kubernetes Init:Error / Init:CrashLoopBackOff — init 容器失败”时靠猜测只会浪费时间。请按证据排查：先复现症状，再执行针对性诊断，定位根因后修复，并用明确检查验证结果。

可观察到的症状包括：

• Pod 状态显示 Init:Error 或 Init:CrashLoopBackOff
• 主容器从未启动
• 迁移或初始化 init 容器以非零退出

诊断

先在隔离环境中复现故障，再按顺序执行以下检查，逐步缩小范围。

步骤 1

kubectl logs <pod> -c <init-container>

init 容器日志会显示其失败输出，而主容器日志不会。

步骤 2

kubectl get pod <pod> -o jsonpath="{.status.initContainerStatuses[*].state}"

非零退出与终止原因可精确指出需修复命令还是依赖。

常见诱因（按出现频率排序）：

• init 容器命令失败（路径错误、缺少二进制、参数错误）
• 依赖（如数据库）尚不可达
• 迁移报错或容器以错误用户运行

根因

init 容器按顺序运行，每个都必须以 0 退出后主容器才启动。失败会使 Pod 处于 Init:Error 或 Init:CrashLoopBackOff，因此主应用日志不会出现。

修复

修正 init 命令，为可能未就绪的依赖添加重试，以正确用户与错误处理运行迁移，并保持 init 容器幂等且快速。

注意：过长或阻塞的 init 容器会拖慢每次重启；应保持短小，避免无超时的无限等待。

spec:
  initContainers:
    - name: wait-for-db
      image: postgres:16
      command:
        - sh
        - -c
        - |
          until pg_isready -h db -p 5432; do echo waiting; sleep 2; done
      # bounded retry instead of infinite wait
      # timeout: use a loop counter or a short backoff budget
  containers:
    - name: app
      image: myrepo/app:1.0.0

验证

重跑 Pod 并确认 init 容器以 0 退出、主容器启动；验证日志显示修复生效。

修复后补充一条回归测试，复现原始症状，防止问题再次出现。

这类故障通常是环境问题而非纯逻辑错误，因此在缺陷记录中应写明完整命令、环境变量与工作目录。请用最小的脚本复现，待最小用例清楚后再扩大范围。为这类故障准备一份简短的排查清单，能显著减少下次排障时间。