场景

你的团队收到警报：一个生产 Kubernetes 节点已经报告了 15 分钟的高负载平均值，磁盘使用率已超过 90%。面向用户的服务变得缓慢，一些 Pod 正在重启。你需要立即进行调查，同时避免情况恶化。

症状

典型信号包括： - 节点负载平均值超过 CPU 核心数 2 倍或更多。 - df -h 显示 /var/lib/docker 或 /var/lib/containerd 超过 90%。 - Pod 处于 CrashLoopBackOff 或 ImagePullBackOff 状态。 - kubectl get nodes 在几分钟后显示 NotReady。

诊断

先从全局视角开始：

uptime
kubectl get nodes -o wide
kubectl describe node NODE_NAME

检查整体负载和 CPU：

top -bn1 | head -20
vmstat 1 5

如果看到较高的 wa（I/O 等待），检查磁盘：

iostat -x 1 5
df -h

查找导致磁盘压力的大文件或目录：

du -x -h --max-depth=2 /var/lib | sort -h | tail -20

查找孤立日志或容器文件：

find /var/log -type f -size +100M -exec ls -lh {} \;

检查系统消息和 Kubelet 服务：

dmesg -T | tail -50
journalctl -u kubelet --since "15 minutes ago"

如果容器启动失败，使用 CRI 检查它们：

crictl ps -a
crictl logs CONTAINER_ID --tail 100

风险控制

除非你绝对确定文件是可以丢弃的，否则永远不要删除文件。首先运行只读命令。保留输出以供后续分析。除非你已经尝试找到根因，否则不要重启节点。如果磁盘已满，不要盲目删除应用程序数据 – 使用 du 和 find 定位日志和临时文件。仅在服务没有写入关键数据时，使用 touch 和 truncate 在轮转日志，生产环境中的服务不会写入关键数据。

回滚

如果问题由最近一次部署导致，执行回滚：

kubectl rollout undo deployment/YOUR_DEPLOYMENT -n YOUR_NAMESPACE

如果日志文件意外增大，将其移开：

mv /var/log/example.log /var/log/example.log.old
systemctl restart rsyslog   # 仅在 rsyslog 作为日志程序时使用

如果容器运行时存储已满，安全清理孤立镜像和卷：

crictl rmi --prune
crictl rm --prune   # 谨慎使用

只有在仔细验证之后，才重启 Kubelet：

sudo systemctl restart kubelet

验证

每次操作后，检查负载和磁盘水平：

uptime
df -h
kubectl get nodes -o wide
kubectl get pods -o wide | grep YOUR_APP

同时查看事件通道：

kubectl get events --sort-by=.metadata.creationTimestamp

如果节点稳定，在关闭事件前至少持续监控 30 分钟。

何时上报 OpsGlobal 工单

在以下情况下提交工单： - 你无法在 30 分钟内找到根因。 - 清理明显原因后负载仍然很高。 - 你需要从失败的挂载或损坏的文件系统中恢复数据。 - 你的值班工程师不堪重负，需要第二双眼睛。 - 你需要对你的 Kubernetes 节点进行主动性能审查。

OpsGlobal 为 Linux 和 Kubernetes 提供生产级支持。当你的 runbook 不再足够时，我们随时介入。