Kubernetes集群故障排查实战：从节点NotReady到Pod CrashLoopBackOff的系统性诊断

Kubernetes故障排查为何需要系统性方法论

Kubernetes集群的故障排查能力是SRE和DevOps工程师的核心技能。与单机故障不同，K8s的故障通常跨多个组件传播：一个节点网络抖动可能导致Pod驱逐，Pod驱逐触发Deployment重新调度，调度失败又引发HPA扩容，最终演变为集群级别的资源争抢。系统性诊断方法论的核心是”自上而下，逐层收敛”——先定位故障作用域，再逐层缩小排查范围。

本文覆盖生产环境中最常见的四类K8s故障：节点NotReady、Pod CrashLoopBackOff、Service端点丢失、调度失败，每类故障给出从现象到根因的完整排查路径。

节点NotReady故障的分层诊断流程

节点NotReady是K8s最常见的基础设施层故障。触发原因可能是kubelet服务异常、容器运行时崩溃、网络插件故障或磁盘压力。排查流程按优先级依次检查：

Step 1：确认节点状态和条件

# 查看节点详细状态
kubectl describe node worker-03 | grep -A 10 "Conditions"

# 关注四个核心条件：
# Ready: False / Unknown
# MemoryPressure: True
# DiskPressure: True
# NetworkUnavailable: True

Step 2：SSH到目标节点检查kubelet

# 检查kubelet服务状态
systemctl status kubelet

# 查看kubelet日志中的关键错误
journalctl -u kubelet --since "30 min ago" | grep -i "error|fatal|failed"

# 常见错误模式：
# "Failed to check Node status" → PLEG问题
# "container runtime is down" → containerd异常
# "failed to update node status" → API Server通信异常

Step 3：检查容器运行时

# 检查containerd状态
crictl info

# 如果crictl命令超时，说明运行时卡死
kubectl drain worker-03 --ignore-daemonsets --delete-emptydir-data
systemctl restart containerd
systemctl restart kubelet
kubectl uncordon worker-03

Step 4：检查磁盘压力

# 检查磁盘使用率
df -h / /var/lib/containerd /var/lib/kubelet

# 检查inode使用率（容易被忽略）
df -i /var/lib/containerd

# K8s默认阈值：磁盘使用率85%触发DiskPressure
# 95%触发驱逐

Pod CrashLoopBackOff的诊断与修复路径

CrashLoopBackOff表示容器启动后反复崩溃。排查的第一步是看上一次容器退出的原因和日志：

# 查看Pod事件
kubectl describe pod api-server-7d4f8b-x2k1 | grep -A 20 "Events"

# 查看上一次退出的容器日志（关键：--previous）
kubectl logs api-server-7d4f8b-x2k1 --previous

# 查看容器退出码
kubectl get pod api-server-7d4f8b-x2k1 \
    -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

# 退出码含义：
# 0: 正常退出  1: 应用通用错误
# 137: OOMKilled  139: Segfault  143: SIGTERM

OOMKilled场景：Java/Python应用最常见的CrashLoop原因。排查和修复：

# 确认OOM事件
kubectl describe pod api-server-7d4f8b-x2k1 | grep -i "oom|killed"

# 临时修复：增加内存限制
kubectl set resources deployment/api-server \
    -c=api-server --limits=memory=2Gi

# 根本修复：分析应用实际内存使用
# 部署Pyroscope或async-profiler做持续内存剖析

应用启动失败场景：配置错误、数据库连接失败、端口冲突等。这类问题的特征是容器退出码为1，日志中有明确的异常栈：

# 进入调试模式
kubectl debug api-server-7d4f8b-x2k1 -it --image=busybox --share-processes

# 或创建一个同配置但命令不同的调试Pod
kubectl run debug --image=your-app-image --command -- sleep 3600

Service端点丢失的排查方法

Service能正常创建但端点列表为空，导致流量无法到达后端Pod。根本原因通常是标签选择器不匹配或Pod未通过健康检查：

# 检查Service端点
kubectl get endpoints api-service

# 对比标签选择器
kubectl get svc api-service -o yaml | grep -A 5 selector

# 对比Pod标签
kubectl get pods -l app=api --show-labels

# 常见陷阱：
# 1. selector用app=api但Pod标签是app=api-server
# 2. Pod Running但Readiness探针失败
# 3. Service targetPort与容器暴露端口不一致

Pod调度失败的资源与约束分析

Pending状态的Pod通常是因为无法找到满足调度条件的节点。需要从资源、亲和性、污点容忍三个维度分析：

# 查看调度失败原因
kubectl describe pod high-mem-job | grep -A 20 "Events"

# 常见失败原因：
# "Insufficient cpu/memory" → 集群资源不足
# "node(s) had taints" → 污点问题
# "node(s) didn't match affinity" → 亲和性约束

# 资源分析：查看集群可用资源
kubectl top nodes
kubectl describe nodes | grep -A 5 "Allocated resources"

故障排查自动化工具链

手动排查效率低且容易遗漏环节。以下工具可以加速日常诊断：

• kubectl plugins：krew插件管理器中的doctor、resource-capacity插件可快速检查集群健康和资源瓶颈
• sonobuoy：CNCF官方诊断工具，运行一致性测试和插件化自定义检查，适合定期巡检
• Robusta：开源K8s故障诊断平台，自动推送故障根因分析和修复建议
• Prometheus + Alertmanager：监控告警体系是故障发现的前哨，关键指标包括kube_node_status_condition、kube_pod_container_status_restarts_total、kube_pod_status_scheduled

建立一套标准化的排查流程文档，配合自动化工具链，能将平均故障恢复时间（MTTR）从小时级缩短到分钟级。排查文档需要持续更新，每次故障复盘后补充新的排查路径和修复方案。