Pod 排障

Pod 是 Kubernetes 最基础的调度单元，Pod 启动失败是最常见的问题类型。

CrashLoopBackOff

现象: Pod 内容器反复重启，每次间隔增长（10s → 20s → 40s → 80s）。

⚠️ 核心认知： CrashLoopBackOff 从来都不是根因。它只是 K8s 告诉你「容器一直在崩，我已经重启很多次了」。真正的问题一定在容器内部——不要上来就 kubectl delete pod，会丢失日志现场导致问题更难定位。

正确排查顺序（线上优先）

① kubectl get pod -A     → 看 STATUS + RESTARTS
② kubectl describe pod   → 看 Events 段（已直接告诉你原因）
③ kubectl logs --previous → 看上一次崩溃时的日志
④ kubectl exec / debug-pod → 进入容器内部排查

常见原因

• 应用配置文件错误或缺失
• 启动命令或参数错误
• 依赖服务（DB/Redis/API）不可达
• 健康检查（livenessProbe）失败 → kubelet 杀死容器
• 权限不足（文件读取、端口绑定）
• 动态链接库缺失
• 容器内 OOM（退出码 137）

排障步骤

# 1. 查看 Pod 事件和终止原因
kubectl describe pod <pod-name> -n <namespace>
# 重点关注: Events 段 + Last State (Reason/Exit Code)

# 2. 查看上一个终止容器的日志
kubectl logs <pod-name> -n <namespace> --previous

# 3. 检查资源限制
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.containers[*].resources}'

# 4. 检查 Liveness Probe 配置
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.containers[*].livenessProbe}'

# 5. 进入容器内部排查
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh
ps aux
cat /etc/resolv.conf
curl -v http://localhost:<port>/health

关键判断

• Exit Code: 137 → OOMKilled（内存超限）
• Exit Code: 143 → SIGTERM（进程收到终止信号，通常因探针失败/滚动发布触发）
• Exit Code: 1 → 程序主动退出（配置错/启动命令错/依赖连接失败）
• Liveness probe failed with statuscode: 503 → 健康检查配置问题
• connection refused → 依赖服务不可达

修复方案

• OOMKilled: 增大 memory limits 或优化应用内存（Java 容器注意：-Xmx 设置 + 元空间/线程栈/直接内存等额外开销总和 < container limits）
• 健康检查: 增大 initialDelaySeconds（Java/Go 建议 ≥30s）；启动慢的服务务必加 startupProbe 避免 livenessProbe 误杀
• 依赖不可达: 检查依赖 Service 的 Endpoints 是否存在
• 配置错误: 检查 ConfigMap/Secret 挂载

排障补充技巧

容器无法进入（不断重启）： 临时覆盖启动命令为 sleep，保持容器运行以便排查：

kubectl run debug-pod --image=<same-image> --rm -it -- sh -c "sleep 3600"
# 或直接修改 Deployment 的 command 字段临时覆盖

调试依赖连通性： 用网络工具镜像启动临时 Pod：

kubectl run net-test --rm -it --image=nicolaka/netshoot -- bash
# 容器内有 curl/nc/dig/ss/tcpdump 等全套网络工具
# 或用 busybox（更轻量）
kubectl run net-test --rm -it --image=busybox -- sh

参见 k8s-probes-guide 获取探针配置完整指南。三探针（startupProbe / livenessProbe / readinessProbe）的区别与配合：

排查总纲：8 步顺序法

1. kubectl get pod     → 看 STATUS（CrashLoopBackOff? Running但未Ready?）
2. kubectl logs --previous → 看上轮崩溃日志
3. kubectl describe pod   → 看 Last State / Exit Code / Events
4. 检查探针               → liveness/readiness/startupProbe 是否太激进
5. 检查资源限制            → 是否 OOMKill / CPU Throttle
6. 检查 ConfigMap/Secret/环境变量/挂载路径
7. 检查依赖服务连通性       → netshoot Pod 测试
8. 检查镜像/启动命令/代码本身

核心原则： 不要看到 CrashLoopBackOff 就开始猜。按顺序走一遍，大部分根因在前 4 步就能定位。

ImagePullBackOff / ErrImagePull

现象: Pod 无法拉取容器镜像。

常见原因

• 镜像名称拼写错误或标签不存在
• 私有仓库未配置 imagePullSecrets
• 镜像仓库网络不通（防火墙、DNS 异常）
• 证书过期或不受信任

排障步骤

# 查看 Pod 事件中的错误信息
kubectl describe pod <pod-name> -n <namespace>

# 在节点上直接拉取测试
docker pull <image-name>
# 或 (containerd)
crictl pull <image-name>

# 检查 imagePullSecrets
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.imagePullSecrets}'

# 测试镜像仓库连通性
nslookup registry.example.com
nc -zv registry.example.com 443
curl -v https://registry.example.com/v2/

修复方案

• 镜像不存在: 更正镜像名/标签
• 认证失败: 创建/更新 Secret → 关联到 Deployment 或 ServiceAccount
• 网络不通: 检查 CNI 插件、节点安全组
• 证书问题: 配置自签名证书信任

Pending 状态

现象: Pod 被 API 接受但无法被调度。

常见原因

• 节点资源不足（CPU/内存）
• 污点（Taints）不匹配（Pod 无对应 Tolerations）
• 亲和性配置过于严格
• PVC Pending（等待存储绑定）

排障步骤

# 查看事件中的调度失败原因
kubectl describe pod <pod-name> -n <namespace>
# Message: "0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taints..."

# 查看集群资源
kubectl top nodes
kubectl describe nodes | grep -A5 "Allocated resources"

# 检查污点
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.taints[*].key}{"\n"}{end}'

# 检查 PVC 状态
kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name> -n <namespace>

修复方案

• 资源不足: 扩容节点 / 调整 Pod requests
• 污点: 添加 Tolerations / 移除节点污点
• PVC Pending: 检查 StorageClass 是否存在、CSI 是否正常

Terminating 状态卡死

现象: Pod 长时间处于 Terminating，删除不掉。

常见原因

• Finalizers 引用不存在的资源
• 存储卷挂载未清理
• kubelet 与 API Server 通信异常

排障步骤

# 查看 Pod YAML（检查 finalizers 和 deletionTimestamp）
kubectl get pod <pod-name> -n <namespace> -o yaml

# 检查存储挂载
mount | grep <pvc-name>

# 检查 CSI 插件
kubectl get pods -n kube-system | grep -E "csi|storage"

强制删除（谨慎！数据备份后执行）

# 跳过 finalizers
kubectl patch pod <pod-name> -n <namespace> \
  -p '{"metadata":{"finalizers":null}}' --type=merge

# 强制终止
kubectl delete pod <pod-name> -n <namespace> --grace-period=5 --force

ConfigMap 挂载异常排查

现象： Pod Running 但应用报错 read-only file system 或 No such file or directory。

# 查看 Pod Events 中的 CreateContainerConfigError
kubectl describe pod <pod-name> -n <namespace> | grep -A5 ConfigMap

# 进入容器检查文件是否为符号链接
kubectl exec -it <pod-name> -- ls -l /app/config/
# lrwxrwxrwx ... -> ..data/xxx  表示是符号链接

# 查看完整挂载信息
kubectl exec <pod-name> -- mount | grep config

已知坑点：

• ConfigMap 挂载目录默认只读 — 需要写入的场景必须用 emptyDir + initContainer
• ConfigMap 里的文件本质是符号链接 — cp 必须加 -L 参数复制真实内容
• 详细排查指南 → configmap-mount-pitfalls

从服务访问角度排查 Pod

当遇到「服务访问不通」问题时，Pod 是排查的第一站。除了 Pod 自身的状态，还需要关注：

# 1. 确认 Pod 是否 Ready（readinessProbe 失败会导致 Endpoints 不包含该 Pod）
kubectl get pods -n <namespace> -o wide
# 关注 Ready 列：1/1、2/2 等

# 2. 进入 Pod 内部测试本地端口是否监听
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh
ss -tlnp   # 或 netstat -tlnp

# 3. 测试 localhost 端口是否能正常响应
wget -qO- http://127.0.0.1:<container-port>/healthz
# localhost 能通但通过 Service 不通 → 问题在 Service 层

# 4. 检查资源限制（OOMKill 或 CPU Throttle 导致请求超时）
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.containers[*].resources}'
kubectl top pod <pod-name> -n <namespace>

命令行速查：

• Pod 状态为 Running 但业务访问异常 → 检查 readinessProbe 和容器内端口
• Pod 被 OOMKill → 退出码 137，调大 memory limits 或优化内存
• Pod 反复重启 → 查看 kubectl logs --previous

关联页面

关联页面