掌握 Linux SRE Runbook：生产故障排查实战指南

作为 SRE，您知道生产事故是不可避免的。小问题和大故障之间的区别往往取决于您能否快速、系统地诊断和解决问题。一个结构良好的 Runbook 是您的第一道防线。在这篇文章中，我们将通过一个真实的场景——Kubernetes 节点因 kubelet 挂起而无响应，来展示基于 Runbook 的排查方法。您将学到实用的命令、风险控制、回滚策略，以及何时应向 OpsGlobal 升级。

场景

想象一个典型的周二早晨。您的监控系统（Prometheus）发送了一个 NodeNotReady 警报，涉及 node-prod-03。这个节点运行着关键工作负载，包括一个支付 API 和一个数据库副本。API 错误率正在攀升，一些 Pod 卡在 Terminating 状态。您需要快速行动，但同时也要有条不紊。

症状

• kubectl get nodes 显示 node-prod-03 为 NotReady。
• 该节点上的 Pod 处于 Pending 或 Terminating 状态。
• kubectl describe node node-prod-03 显示 KubeletNotReady 条件，原因可能是 PLEG is not healthy 或 Docker Daemon not running。
• 节点负载极高（例如，平均负载 > 100）。
• 节点可能对 SSH 无响应。

诊断

首先使用只读命令收集数据，在不改变状态的情况下了解情况。请勿在未了解根本原因之前盲目重启。

1. 检查节点状态和条件

kubectl get nodes -o wide
kubectl describe node node-prod-03

查看 Conditions 部分。NotReady 的常见原因： - KubeletNotReady 并显示 PLEG is not healthy（通常由容器运行时挂起导致）。 - MemoryPressure、DiskPressure、PIDPressure 或 NetworkUnavailable。

2. 访问节点

如果 SSH 可用，请登录。如果不可用，请依靠带外管理（如 iDRAC、IPMI）或云控制台。

ssh sre@node-prod-03

3. 检查 Kubelet 日志

Kubelet 日志通常包含关键线索。

journalctl -u kubelet -n 200 --no-pager

查找类似 PLEG is not healthy、Failed to connect to containerd 或 Unhealthy 探针的重复错误。

4. 检查系统资源

运行 top、vmstat、free -h、df -h 来评估 CPU、内存、交换空间和磁盘。

top -bn1 | head -20
vmstat 1 5
free -m
df -h

高 CPU 负载可能是由于失控进程、OOM 内核 panic 或基础设施问题（例如共享虚拟机上的邻居干扰）。

5. 内核消息

dmesg 可以揭示 OOM 杀死、磁盘 I/O 错误或硬件问题。

dmesg --time-format iso | tail -100

6. 容器运行时健康

自 Kubernetes 1.24+ 以来，默认运行时是 containerd。检查其状态。

systemctl status containerd
journalctl -u containerd -n 100 --no-pager

7. 检查僵尸进程

僵尸进程风暴可能导致 kubelet 崩溃。检查：

ps aux | awk '$8=="Z" {print}'

风险控制

在做出任何更改之前，评估影响范围：

• 封锁节点 以防止新工作负载调度：kubectl cordon node-prod-03。
• 如果工作负载至关重要，考虑排空节点，但前提是您已了解问题。排空可能会导致服务中断（如果服务未正确重新调度）。
• 除非有明确原因，否则避免重启 kubelet。重启 kubelet 可能无法修复底层系统问题，并可能导致 Pod 重启的惊群效应。
• 使用 systemctl 重启服务仅在必要时，并始终检查依赖组件。
• 切勿在不验证 PID 和父进程的情况下杀死进程。使用 ps -ef 确认。

回滚

如果您进行了更改并导致情况恶化，您需要计划恢复。

• 如果您重启了 kubelet 并且节点恢复后立即变得不稳定，您可能需要回滚到以前的内核或系统包。这超出了 Runbook 的范围，但您应该记录确切的步骤。
• 如果您排空了节点，使用 kubectl uncordon node-prod-03 允许再次调度。
• 如果您更改了 sysctl 或配置文件，请备份原始文件（例如 cp /etc/sysctl.conf /etc/sysctl.conf.bak）并恢复。

在可能的情况下，始终在预演环境中测试回滚。在紧急情况下，您可以依靠配置管理系统（例如 Ansible、Terraform）重新应用已知良好状态。

验证

修复后，验证节点是否健康，工作负载是否恢复正常。

1. 检查节点状态： bash kubectl get nodes
2. 检查节点条件： bash kubectl describe node node-prod-03 | grep Conditions -A5
3. 验证 Pod 是否正在运行： bash kubectl get pods --field-selector spec.nodeName=node-prod-03 -o wide
4. 监控系统负载和 kubelet 日志几分钟： bash uptime journalctl -u kubelet -f
5. 通过监控仪表板确认 API 错误率恢复基线。

何时向 OpsGlobal 提交工单

您可以使用 Runbook 处理许多事故，但有些情况需要更深入的分析。如果出现以下情况，请向 OpsGlobal 提交工单：

• 尽管遵循了本指南，您仍无法确定根本原因。
• 多次重启后节点仍然反复出现 NotReady。
• 您看到硬件故障的迹象（例如 smartctl 错误、内存 ECC 错误）。
• 您需要协助处理内核级问题或供应商特定支持。
• 事故具有业务影响，您需要第二双眼睛在您继续工作时提供帮助。

OpsGlobal 提供 24/7 远程 DevOps 和 SRE 支持。我们的工程师在 Linux 和 Kubernetes 故障排查方面经验丰富。我们可以帮助您构建更健壮的 Runbook、诊断复杂事故，并更快地让您的服务恢复在线。

---

这份 Runbook 是一份活文档。根据每次事故中学到的经验进行更新。目标是缩短 MTTR，并在寻呼机响起时增强信心。