pod无法进入running状态需按六步排查：一查pod事件定位失败类型；二查日志确认启动异常；三验镜像拉取配置；四核资源请求与节点容量匹配；五调健康探针参数避免误杀；六查kubelet、cni等节点级组件状态。
如果您尝试在Kubernetes集群中部署Pod，但Pod始终无法进入Running状态，则可能是由于镜像拉取失败、资源配置冲突、探针配置不当或节点资源不可用等多种原因导致。以下是解决此问题的步骤：
一、检查Pod状态与事件信息
通过kubectl describe pod命令可获取Pod的调度详情、容器状态及最近发生的事件，这些事件往往直接指出失败根源，例如ImagePullBackOff、FailedScheduling或Unschedulable等关键提示。
1、执行kubectl get pods -o wide查看目标Pod当前状态及所在节点。
2、运行kubectl describe pod
3、若事件中出现FailedScheduling，需进一步检查节点资源容量与污点配置。
4、若事件显示ImagePullBackOff，应立即转向镜像验证环节。
二、查看容器实时与历史日志
容器日志是定位启动失败最直接的依据，尤其当Pod处于CrashLoopBackOff状态时，上一次崩溃的日志往往包含应用启动异常、依赖连接超时或配置加载失败等关键线索。
1、执行kubectl logs
2、若容器已重启多次，使用kubectl logs
3、若日志为空且容器未启动成功，说明失败发生在容器运行时之前，需检查镜像入口点或initContainer执行结果。
4、对多容器Pod，逐个指定-c参数检查各容器日志，避免遗漏主容器之外的辅助容器错误。
三、验证镜像可用性与拉取配置
镜像无法拉取是最常见启动阻断因素，可能源于镜像路径错误、私有仓库未授权、标签不存在或网络策略拦截拉取请求。
1、确认YAML中image字段值准确无误，包括仓库域名、命名空间、镜像名与tag，例如registry.example.com/app/backend:v2.3.1。
2、在集群任意节点手动执行docker pull或crictl pull命令验证镜像可拉取性。
3、若为私有仓库，检查Pod定义中是否正确定义了imagePullSecrets，并确认Secret对象存在于同一命名空间。
4、检查节点上容器运行时（如containerd）的日志，确认是否存在TLS证书错误、HTTP 401/403响应或DNS解析失败。
四、审查资源配置与节点容量匹配性
当Pod的resources.requests超出节点剩余资源，或节点因磁盘压力、内存不足被标记为NotReady，Pod将卡在Pending状态无法调度。
1、执行kubectl describe node
2、检查Events区域是否有OutOfcpu、OutOfmemory或NodeHasDiskPressure等警告。
3、在Pod YAML中核对resources.requests是否设置合理，避免requests大于节点最小分配单元（如CPU小于100m可能被拒绝）。
4、若节点存在Taint，确认Pod spec中已配置对应tolerations，否则调度器将跳过该节点。
五、分析健康探针与启动行为兼容性
存活探针（livenessProbe）或就绪探针（readinessProbe）配置过激，会导致应用尚未完成初始化即被强制终止，形成CrashLoopBackOff循环。
1、检查探针配置中initialDelaySeconds是否小于应用实际冷启动耗时，例如Java应用加载Spring上下文常需20–45秒。
2、确认timeoutSeconds未设为过短值（如1秒），避免网络延迟或I/O抖动触发误判。
3、对启动缓慢的服务，添加startupProbe替代livenessProbe初期检测，防止早期重启干扰初始化流程。
4、验证探针路径（如/healthz）在容器内真实可访问，且返回HTTP 200状态码，避免因路径不存在或权限拒绝导致失败。
六、排查节点级组件与底层依赖异常
即使Pod定义无误，若kubelet异常、CNI插件故障、内核模块缺失或挂载卷不可达，也会导致ContainerCreating长期不结束。
1、执行kubectl get nodes确认目标节点状态为Ready；若为NotReady，进一步运行kubectl describe node定位具体条件异常。
2、登录对应节点，运行journalctl -u kubelet -n 100 --no-pager查看kubelet最近日志，搜索failed to start container或failed to mount等关键词。
3、检查/var/lib/kubelet/pods/下对应Pod目录是否存在，确认volumeMounts声明的ConfigMap、Secret或PersistentVolume是否已成功投射。
4、验证CNI配置文件（如/etc/cni/net.d/）是否存在且语法正确，运行crictl ps -a确认pause容器是否正常运行。
