Pod启动失败需按Events→日志→镜像→资源配置→Init容器与探针顺序排查：先用kubectl describe pod查Events定位失败类型，再依状态用kubectl logs --previous或指定-c查日志，接着在节点手动crictl pull验证镜像，核对resources.requests与节点Allocatable匹配性，最后检查initContainer执行结果及探针参数合理性。
Pod启动失败不是单一问题，而是几十种具体错误状态的统称。直接看STATUS列没用，必须根据kubectl describe pod输出的Events和Conditions定位到真实失败类型，再分路径处理。
查Events确认失败类型，别猜
所有后续动作都依赖这一步的准确判断。执行kubectl describe pod <pod-name>后，只盯Events部分最末几条——Kubernetes按时间倒序排列，最新事件才是关键线索：
-
ImagePullBackOff或ErrImagePull：镜像拉取失败，跳去「验证镜像可用性」环节 -
FailedScheduling：调度失败，检查节点资源、污点（Taint）、亲和性配置 -
CrashLoopBackOff：容器已启动但立即退出，重点查日志和启动命令 -
Init:Error或Init:CrashLoopBackOff：Init容器失败，需单独查其日志 -
ContainerCreating持续不退：大概率是存储卷挂载失败或CNI网络插件异常
查日志要分场景，--previous不是万能的
日志空≠没问题。不同状态对应不同日志获取方式：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 容器反复重启（
CrashLoopBackOff）：用kubectl logs <pod-name> --previous抓上一次崩溃输出；若仍为空，说明失败发生在容器进程启动前（如command执行失败、入口点脚本权限错误） - 多容器Pod：必须指定
-c <container-name>，否则默认只返回第一个容器日志，容易漏掉Init容器或sidecar错误 - 容器根本没起来（
Pending或ContainerCreating）：kubectl logs会报错container "xxx" in pod "yyy" is waiting to start，此时日志无意义，应回头看Events
验证镜像可用性，别只信YAML里的image字段
镜像名写对了≠集群能拉到。常见断点在私有仓库认证、网络策略、镜像层损坏：
- 在Pod所在节点手动执行
crictl pull <full-image-path>（非docker pull，因多数集群用containerd） - 私有仓库必须配
imagePullSecrets，且Secret需与Pod同命名空间；用kubectl get secret <secret-name> -o yaml确认.dockerconfigjson内容base64解码后含正确凭证 - 国内环境常因DNS或证书问题拉取失败：检查节点
/etc/containerd/config.toml中是否配置了镜像加速器（如https://registry.cn-hangzhou.aliyuncs.com）
注意Init容器和健康探针的隐性陷阱
这两类配置不会导致Pod卡在Pending，但会让它永远进不了Running状态：
- Init容器卡在
Running：用kubectl logs <pod-name> -c <init-container-name>查日志；若无输出，检查是否在等待外部服务（如DB），但未设超时或重试逻辑 - Liveness探针过早触发：
initialDelaySeconds必须大于应用冷启动耗时；若应用启动需45秒，而该值设为10，容器会被反复kill - Readiness探针失败：虽不影响Pod状态为
Running，但会导致Service不转发流量，表现为“Pod起来了但服务不可用”
真正难排查的，往往是多个条件叠加：比如Init容器因镜像拉取失败卡住，同时主容器又配置了过短的livenessProbe，导致describe里事件混杂，必须一层层剥开看Conditions里哪个type是False、对应reason是什么——Initialized=False和ContainersReady=False的根因完全不同。
