K8s Pod异常排查：从状态到日志的完整定位思路
Pod 出问题时，最有效的做法不是反复重启，而是先确认它停在哪个状态，再顺着事件、日志、资源和配置逐层往下查。
K8s Pod 异常排查的核心顺序是：看状态 → 看事件 → 看日志 → 查资源和配置 → 改完再验证。
下面按这个顺序展开，命令可以直接复制执行。
先确认 Pod 当前状态和所在节点
所有排查都从这条命令开始，建议加上 -o wide 看节点，加 -n 指定命名空间：
kubectl get pods -n <命名空间> -o wide
kubectl describe pod -n <命名空间> STATUS 列会直接告诉你问题类型：Pending 通常是调度或资源问题；ImagePullBackOff 是镜像拉取失败；CrashLoopBackOff 是容器启动后反复退出；Running 但服务不通，
则多半是探针、
端口或 Service 配置问题。describe 输出的 Events 段是排查重点，
最下面几行往往直接写出失败原因。
按状态定位：三类高频异常怎么查
Pending 一直不调度：先看 describe 里的事件是否提示资源不足或节点亲和性不满足。
检查节点可用资源：
kubectl describe nodes | grep -A 5 "Allocated resources"
kubectl get nodes如果提示 Insufficient cpu 或 Insufficient memory，说明 requests 设置过大或节点资源确实不够；
如果提示 node(s) had taint，说明节点有污点而 Pod 没有对应容忍。
ImagePullBackOff / ErrImagePull：先确认镜像名和 tag 是否写对，再确认节点能否访问镜像仓库。
私有仓库还要检查 imagePullSecrets 是否存在且命名空间正确：
kubectl get secret -n <命名空间>
kubectl describe pod -n <命名空间> | grep -i image 常见原因是 tag 写成了不存在的版本、仓库需要登录、或节点网络无法解析仓库域名。
CrashLoopBackOff：容器能拉起来但进程立刻退出。
优先看上一次崩溃的日志：
kubectl logs -n <命名空间> --previous
kubectl logs -n <命名空间> -c <容器名> 如果日志为空，通常是启动命令本身有问题，比如 command 写错、依赖的配置文件没挂载、或数据库连接地址不可达。
日志、探针和资源限制的核查点
日志没有明显报错时，重点查探针配置。livenessProbe 失败会导致容器被反复重启，readinessProbe 失败则会让 Pod 一直不进入 Ready，表现为 Service 没有可用后端。
用 describe 看 Liveness 和 Readiness 段，确认路径、端口和 initialDelaySeconds 是否合理。
资源限制方面，resources.limits 设得太低会导致容器被 OOMKilled。
查看退出原因：
kubectl get pod -n <命名空间> -o jsonpath='{.status.containerStatuses[*].lastState}' 如果 reason 是 OOMKilled，就要调高内存 limit，或排查应用是否存在内存泄漏。
避坑与修改后的验证
修改配置前先导出当前 YAML 备份：
kubectl get pod -n <命名空间> -o yaml > pod-backup.yaml 改镜像、资源或探针后，用 kubectl apply -f 或 kubectl edit 更新，再观察状态变化：
kubectl get pods -n <命名空间> -w验证通过的标准是：Pod 进入 Running 且 READY 为 1/1，RESTARTS 不再增长，Service 的 Endpoints 里有对应 IP：
kubectl get endpoints -n <命名空间> 几个容易踩的坑：不要在没看事件的情况下直接删 Pod，删除只能触发重建，根因还在；CrashLoopBackOff 下 kubectl logs 默认看的是当前实例，必须加 --previous 才能看到崩溃前输出；
改探针时不要为了“让它过”把阈值调得过大，否则真正的故障会被掩盖。
常见疑问
Pod 是 Running 但访问不了怎么办？ 先查 kubectl get endpoints 是否有后端 IP，
再看 Service 的 targetPort 是否和容器实际监听端口一致，
最后在集群内用 curl 或 wget 测容器 IP 加端口。
为什么 describe 里事件是空的？ 事件默认只保留一段时间，
可以加 --events 重新查看，
或直接用 kubectl get events -n <命名空间> --sort-by=.lastTimestamp。
改了 YAML 但 Pod 没变化？ 如果 Pod 由 Deployment 管理，要改 Deployment 而不是直接改 Pod；
直接改 Pod 的内容会在重建后丢失。
节点资源显示充足，Pod 还是 Pending？ 检查是否有节点选择器、亲和性或污点限制，命令是 kubectl describe pod 看事件里的调度失败原因。
