K8s 排错圣经：10 种最常见的 Pod 异常状态深度解析与实战修复指南

在 Kubernetes 的日常运维中，Pod 作为工作负载的最小单元，其健康状态直接关系到服务的稳定性。然而，Pod 常常会陷入各种异常状态，让开发者与运维人员头疼不已。本文将化身你的“排错圣经”，系统性地梳理 10 种最常见的 Pod 异常状态，从现象、根因到修复方案，提供一套完整的实战指南。

1. Pending（挂起）

现象：Pod 被成功创建，但无法被调度到任何节点上运行。使用 kubectl get pods 查看时，状态持续为 Pending。

根本原因：

资源不足：集群中没有节点拥有足够的 CPU 或内存来满足 Pod 的请求（requests）。
节点选择器/亲和性不匹配：Pod 的 nodeSelector 或 nodeAffinity 规则，没有找到符合条件的节点。
污点与容忍度：目标节点上存在 Taint，而 Pod 没有配置相应的 Toleration。
持久卷声明（PVC）未绑定：Pod 使用了 PVC，但对应的 PV 无法绑定（如存储类不存在、容量不足等）。

修复方案与排查命令：

查看详细事件：这是排查 Pending 状态的第一步，通常会给出明确提示。
```
kubectl describe pod <pod-name> -n <namespace>
```
关注 Events: 部分的输出，例如 Insufficient cpu/memory, didn‘t match node selector, 0/3 nodes are available 等。
检查集群资源：
```
kubectl describe nodes
# 或使用更直观的工具
kubectl top nodes
```
查看节点的可分配资源（Allocatable）和已分配资源。

检查 PVC/PV 状态：

kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name> -n <namespace>

确认 PVC 状态是否为 Bound。

调整资源配置：根据排查结果，可能需要进行以下操作：
- 增加集群节点或调整 Pod 的 resources.requests。
- 修改 Pod 的 nodeSelector 或 nodeAffinity 配置。
- 为 Pod 添加合适的 tolerations。
- 修复 PVC 配置（如使用正确的 storageClassName）。

2. ImagePullBackOff / ErrImagePull

现象：Pod 无法拉取容器镜像。ImagePullBackOff 表示 Kubelet 在多次重试拉取失败后进入退避等待状态；ErrImagePull 是拉取错误的直接报告。

根本原因：

镜像名称或标签错误：拼写错误或标签不存在。
私有镜像仓库认证失败：没有为 Pod 配置正确的 imagePullSecrets。
网络问题：无法访问镜像仓库（如 Docker Hub, Google GCR, 私有仓库）。
镜像仓库证书问题：自签名证书未在节点上被信任。

修复方案与排查命令：

确认镜像信息：

kubectl describe pod <pod-name> | grep -A5 -B5 “Image”

仔细核对镜像名称和标签。

手动测试拉取：在某个节点上使用 Docker 或 Containerd 命令行工具手动拉取镜像，可以验证网络和认证。
```
# 如果节点使用 Docker
docker pull <image-name:tag>
```

配置 imagePullSecrets：如果使用私有仓库，需要在 Pod 所在的命名空间创建 Secret，并在 Pod spec 中引用。

# 创建 docker-registry 类型的 Secret
kubectl create secret docker-registry my-registry-key \
  --docker-server=<你的仓库地址> \
  --docker-username=<用户名> \
  --docker-password=<密码> \
  --docker-email=<邮箱> -n <namespace>

# 在 Pod 或 Deployment 的 spec 中引用
# spec:
#   imagePullSecrets:
#     - name: my-registry-key
#   containers:
#   - ...

检查节点 Docker 配置：对于自签名证书，可能需要将 CA 证书放置到节点的 /etc/docker/certs.d/<registry-host>/ 目录下。

3. CrashLoopBackOff

现象：Pod 内的容器反复启动，但很快失败退出，Kubernetes 不断重启它，重启间隔（BackOff）时间逐渐变长。这是最常见的异常之一。

根本原因：

应用程序错误：容器启动后，应用进程因代码 bug、配置错误、依赖服务不可用等原因崩溃。
启动探针（Startup Probe）失败：如果配置了启动探针且未通过，容器会被杀死。
存活探针（Liveness Probe）失败：存活探针连续失败，导致容器被重启。
资源限制（Limit）：容器进程因内存超出限制（OOMKilled）而被系统终止。
权限问题：容器以非 root 用户运行，但需要写入某些受保护的目录。

修复方案与排查命令：

查看容器日志：这是定位应用层错误的最直接方法。

kubectl logs <pod-name> -n <namespace>
# 查看前一次崩溃的日志
kubectl logs <pod-name> --previous -n <namespace>

描述 Pod 查看事件：
```
kubectl describe pod <pod-name>
```
关注 Last State、Exit Code 以及 Events。Exit Code 137 通常代表 OOMKilled，其他非 0 代码代表应用错误。
进入容器调试：如果容器能短暂运行，可以尝试 exec 进入进行调试。
```
kubectl exec -it <pod-name> -- /bin/sh
```
检查配置文件、环境变量、依赖端口等。
检查探针配置：确保 startupProbe、livenessProbe 的 initialDelaySeconds、periodSeconds、failureThreshold 设置合理，不会因应用启动慢而误杀。
调整资源限制：如果是因为 OOM，需要适当增加 resources.limits.memory 或优化应用内存使用。

4. RunContainerError

现象：在创建容器运行时环境时发生错误，通常发生在 ImagePull 之后，容器启动之前。

根本原因：

挂载卷失败：例如，ConfigMap 或 Secret 不存在，或者挂载路径有问题。
容器运行时问题：节点上的容器运行时（Docker, Containerd）状态异常或版本不兼容。
安全上下文（SecurityContext）配置冲突：如设置了只读根文件系统（readOnlyRootFilesystem: true）但应用需要写临时文件。

修复方案与排查命令：

查看详细错误信息：
```
kubectl describe pod <pod-name>
```
在 Events 中寻找 RunContainerError 的具体描述，例如 “failed to create subPath directory...” 或 “mount failed”。
检查挂载的卷：
```
kubectl get configmap,secret -n <namespace>
```
确认 Pod 中引用的 ConfigMap 或 Secret 确实存在。

检查节点容器运行时：

# 登录到问题节点
systemctl status docker  # 或 containerd
journalctl -u docker -f  # 查看运行时日志

调整 SecurityContext：根据应用需求，适当放宽安全限制。

5. Error

现象：一个非常笼统的状态，通常表示在 Pod 生命周期的前期（如调度、拉取镜像、创建容器）遇到了无法归类的错误。它可能是一个短暂状态，随后会变为更具体的状态（如 CrashLoopBackOff）。

排查方法：与 RunContainerError 类似，主要依赖 kubectl describe pod 和 kubectl logs（如果容器有启动的话）来获取更详细的错误上下文。

6. Terminating

现象：Pod 正在被删除，但迟迟没有消失，一直卡在这个状态。

根本原因：

Finalizers 阻塞：Pod 的 metadata.finalizers 字段包含自定义的终结器，需要外部控制器执行完清理逻辑后才能被删除。
API 通信问题：节点与 Kubernetes API Server 失联，导致 Kubelet 无法上报删除完成的状态。
容器优雅终止超时：Pod 中的容器收到了 SIGTERM 信号，但进程没有在规定时间（默认为 30 秒，可由 terminationGracePeriodSeconds 设置）内优雅退出。

修复方案与排查命令：

强制删除：这是最直接的解决方法，但需谨慎，因为它可能绕过应用的优雅关闭逻辑。
```
kubectl delete pod <pod-name> --force --grace-period=0 -n <namespace>
```

检查 Finalizers：

kubectl get pod <pod-name> -o yaml | grep finalizers -A5

如果发现无关或卡住的 Finalizer，可以编辑 Pod 将其移除（风险操作）：

kubectl edit pod <pod-name>
# 删除 finalizers 字段下的内容

检查节点状态：
```
kubectl get nodes
```
确认 Pod 所在节点状态是否为 NotReady。

7. ContainerCreating

现象：Pod 已被调度到节点，但容器尚未创建完毕。这是一个正常的中间状态，但如果持续时间过长，则意味着有问题。

根本原因：

镜像拉取缓慢：镜像过大或网络速度慢。
挂载卷缓慢/失败：特别是挂载网络存储（如 NFS, Ceph）时，可能出现超时。
容器运行时繁忙：节点负载过高，容器运行时处理请求慢。

排查方法：使用 kubectl describe pod 查看 Events，通常会显示 Pulling image 或 Mounting volume 等信息。可以结合节点监控，查看磁盘 I/O、网络带宽等指标。

8. Completed

现象：Pod 中的所有容器均已成功执行完毕并退出（退出码为 0）。这对于 Job 类型的 Pod 是正常状态，但对于 Deployment 或 StatefulSet 下的长期运行服务，则意味着异常。

根本原因（对于服务类 Pod）：

命令错误：在 spec.containers.command 中错误地指定了一个执行完即退出的命令，而不是一个常驻进程命令（如 sleep, nginx -g ‘daemon off;‘）。

修复方案：检查并修正 Pod 或 Deployment 的配置，确保容器的启动命令是前台运行、不会退出的。

9. Evicted

现象：Pod 被从节点上驱逐。这通常是由于节点资源压力所致。

根本原因：

节点磁盘压力（DiskPressure）：节点可用磁盘空间（特别是 /var 分区）不足。
节点内存压力（MemoryPressure）：节点可用内存不足，Kubelet 会优先驱逐消耗内存多的 Pod 以保护节点。

修复方案与排查命令：

查看驱逐原因：

kubectl get pod <pod-name> -o wide
kubectl describe pod <pod-name> | grep -i “evicted” -A5 -B5

清理节点磁盘：登录被驱逐 Pod 所在节点，清理无用镜像、日志或临时文件。

# 查看磁盘使用
df -h
# 清理未使用的 Docker 镜像和容器
docker system prune -a -f

调整资源请求与限制：为 Pod 设置合理的 resources.requests 和 limits，避免单个 Pod 过度消耗资源。
配置 Pod 优先级（PriorityClass）：为关键 Pod 设置更高的优先级，降低其被驱逐的风险。

10. Unknown

现象：Kubernetes API Server 无法获取 Pod 的状态。这是一个危险信号，通常意味着 Pod 所在节点失联。

根本原因：

节点与 API Server 通信中断：节点可能宕机、重启或网络分区。
Kubelet 进程崩溃：节点上的 Kubelet 服务停止运行。

修复方案与排查命令：

检查节点状态：
```
kubectl get nodes
```
如果节点状态为 NotReady 或 Unknown，则问题在节点层面。
登录节点排查：如果可能，通过 SSH 或控制台登录该节点，检查：
- 网络连通性：ping <api-server-ip>
- Kubelet 服务状态：systemctl status kubelet
- 系统日志：journalctl -u kubelet -f
临时恢复：如果节点确认无法恢复，可以驱逐（Drain）该节点，其上的 Pod 将在其他健康节点上重新调度。
```
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

总结：Pod 排错通用流程

面对一个异常 Pod，遵循以下流程可以高效定位问题：

kubectl get pods：快速查看 Pod 当前状态。
kubectl describe pod <pod-name>：获取详细配置、事件和状态变更历史，这是最关键的一步。
kubectl logs <pod-name>：查看应用日志，定位容器内部错误。
kubectl exec -it <pod-name> -- /bin/sh：进入容器内部进行交互式调试（如果容器正在运行）。
检查相关资源：根据描述信息中的线索，检查对应的 Node、PVC、ConfigMap、Secret、Service 等关联资源。
检查集群组件：必要时，检查 kube-system 命名空间下的核心组件（如网络插件 CNI）日志。

熟练掌握这 10 种异常状态及其应对策略，你将能从容应对 Kubernetes 中绝大多数 Pod 级别的故障，保障你的应用稳定运行。记住，清晰的日志、合理的监控和系统性的排查思路，是运维 Kubernetes 集群的三大法宝。

文档信息

本文作者：JiliangLee
本文链接：https://leejiliang.cn/2026/01/28/K8s-%E6%8E%92%E9%94%99%E5%9C%A3%E7%BB%8F%E6%80%BB%E7%BB%93-10-%E7%A7%8D%E6%9C%80%E5%B8%B8%E8%A7%81%E7%9A%84-Pod-%E5%BC%82%E5%B8%B8%E7%8A%B6%E6%80%81%E4%B8%8E%E4%BF%AE%E5%A4%8D%E6%96%B9%E6%A1%88/
版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）

CODE

K8s 排错圣经：10 种最常见的 Pod 异常状态深度解析与实战修复指南

K8s 排错圣经：10 种最常见的 Pod 异常状态深度解析与实战修复指南

1. Pending（挂起）

2. ImagePullBackOff / ErrImagePull

3. CrashLoopBackOff

4. RunContainerError

5. Error

6. Terminating

7. ContainerCreating

8. Completed

9. Evicted

10. Unknown

总结：Pod 排错通用流程

文档信息

Search

Table of Contents