启动失败的提示往往出现在最高一层：CLI、Pod condition 或 HTTP 超时。修复需要逆向定位首个出错环节。沿10 的 digest、17 的 bundle、24 的网络对象与28 的就绪状态逐层判断，先记录假设，再以明确证据排除。

四种会混成一个“起不来”的情况

第一，镜像无法解析或 layer blob 缺失：还没有完整根文件，查看拉取响应与 digest。第二，平台不匹配：索引没该平台或启动可执行文件时产生架构错误，核对节点架构与目标文件格式。第三，运行时配置或挂载权限被拒：先找 OCI bundle/config、宿主权限与 errno，不能怪应用网络。第四，进程已经运行但监听 127.0.0.1、readiness 返回 503 或 Service 后端未更新：先比较 PID、目标地址、探针与真实请求。每类都要设计一条可被反例推翻的排除证据，不能只列故障关键词。

在专用实验 VM 以相同 probe-app 分别制造四类受控故障：错误镜像摘要/缺 blob、错误架构、只读写入目录、错误监听地址或 readiness 延迟；同一时刻只改一个变量，并为每次保留镜像 digest、Pod UID（若有）、容器 ID、PID、错误日志、修复后成功请求及清理。故障注入边界和源码包不包含对共享资源的故障开关。云端没有运行时或集群，这四类注入与恢复目前 NOT_RUN，不把 10 的离线篡改检查混成容器启动错误。

现象 第一证据 误判风险
image pull 失败 远端 HTTP、manifest digest 不等于 PID 1 问题
exec format error ELF 平台与节点架构 不等于 CNI 错误
已 Running、访问超时 监听、路由与 endpoint 不代表镜像不完整

练习

  1. 先预测入口命令不存在与镜像平台不匹配的首个失败日志位置；在专用 VM 分别运行并保存原始错误及清理确认。
  2. 先预测 Pod Running 但 /ready=503 是否该重拉镜像；沿容器 PID、服务监听和 EndpointSlice 排除后再决定修复层。

上一篇：31：指标归属；下一篇：33：制品可信。

系列总目录：从进程隔离到运行时与编排。

参考资料