Pod启动失败需按事件→日志→配置→节点状态顺序排查：先用kubectl describe pod查Events定位方向，再用kubectl logs --previous看崩溃日志，接着核验resources.requests与节点资源匹配性，最后检查探针参数和initContainer执行结果。
Pod 启动失败不是单一问题，而是调度链路中某一个环节卡住的结果。定位关键不在“猜”，而在按顺序观察真实信号：事件、日志、配置、节点状态。
先看 Events 定方向
执行 kubectl describe pod <pod-name>，直接滚动到底部看 Events 部分——这是 Kubernetes 给你的第一手诊断报告。
- 出现 FailedScheduling：说明调度器没找到合适节点，重点查资源请求、污点/容忍度、节点选择器或亲和性是否匹配
- 出现 ImagePullBackOff 或 ErrImagePull：镜像拉取失败，立刻验证镜像地址、标签、私有仓库凭证（
imagePullSecrets）和节点网络连通性 - 出现 ContainerCreating 卡住超 1 分钟：大概率是存储卷挂载失败（PVC Pending）、CNI 网络插件异常或 initContainer 未退出
- 出现 CrashLoopBackOff：容器启动后立即退出，需转向日志排查
再查日志找线索
日志是容器内部行为的唯一出口，尤其注意“上一次崩溃”的输出：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 运行
kubectl logs <pod-name> --previous获取前一个容器实例的日志——CrashLoopBackOff 场景下，这往往就是失败原因 - 多容器 Pod 要逐个指定
-c <container-name>，initContainer 和主容器都要看 - 如果日志为空，说明失败发生在容器 runtime 启动之前，比如入口命令（
command）语法错误、挂载路径不可写、或缺少必需的 configmap/secret
核对资源配置与节点实际能力
Pod 的 resources.requests 不是声明，而是调度硬门槛；它必须小于等于节点的 allocatable 资源。
- 用
kubectl describe node <node-name>查看该节点的 Capacity 和 Allocatable，对比已分配资源 - 用
kubectl top node观察实时 CPU/内存压力，磁盘空间不足也会导致ContainerCreating卡住 - 检查 Pod 是否带了
nodeSelector、tolerations或affinity，确认目标节点确实满足所有条件（包括标签、污点等）
别忽略探针和初始化容器
健康探针不是锦上添花，而是“杀手机制”；initContainer 不成功，主容器根本不会启动。
-
StartupProbe 超时太短？应用冷启动要 45 秒，而你只设了
initialDelaySeconds: 10→ 容器还没起来就被杀掉 -
LivenessProbe 过早触发？把
initialDelaySeconds设成应用完全就绪所需时间，避免误重启 - initContainer 失败时，
kubectl describe pod里会明确写出哪个 init 容器 ExitCode 非 0，用kubectl logs -c <init-container-name>直接查错
