2. 节点异常分类：硬件故障、软件故障与网络故障
在 Kubernetes 集群中，节点异常是导致 Pod 重调度、服务中断和 MTTR 延长的首要原因。要制定有效的自动恢复策略，首先必须对节点异常进行精确分类。本章将节点异常划分为三大类：硬件故障、软件故障和网络故障，并深入分析每类故障的典型表现、根因定位方法和恢复路径。
2.1 硬件故障（CPU / 内存 / 磁盘）
硬件故障通常表现为物理资源不可用或性能严重下降，是节点异常中最直接、最严重的一类。Kubernetes 通过 Node Problem Detector（NPD）和 kubelet 的监控机制来检测硬件异常。
| 故障类型 | 典型表现 | Kubernetes 检测机制 | 自动恢复策略 |
|---|---|---|---|
| CPU 故障 | 节点负载异常高、进程卡死、CPU 时间片分配不均 | NPD 检测 CPU 错误（MCE）、kubelet 上报 NodeHasInsufficientCPU | Pod 驱逐 → 节点 cordon → 自动替换节点（Cluster Autoscaler） |
| 内存故障 | ECC 错误、内存泄漏、OOM Killer 频繁触发 | NPD 检测内存错误、kubelet 上报 NodeHasInsufficientMemory | Pod 驱逐 → 节点 cordon → 内存诊断 → 节点替换 |
| 磁盘故障 | I/O 延迟飙升、磁盘空间不足、文件系统只读 | NPD 检测磁盘错误、kubelet 上报 NodeHasDiskPressure / NodeHasNoDiskSpace | Pod 驱逐 → 节点 cordon → 磁盘修复或替换 |
SRE 实战提示： 硬件故障的 MTTR 优化关键在于 检测速度。建议将 NPD 的检测间隔缩短至 10 秒以内，并配置 Prometheus Alertmanager 在检测到硬件错误时立即触发节点 cordon 和 Pod 驱逐流程，避免故障扩散。
2.2 软件故障（kubelet / CRI / Docker）
软件故障是 Kubernetes 节点异常中最常见的类型，通常由组件崩溃、配置错误或版本兼容性问题引起。这类故障的恢复路径比硬件故障更灵活，但排查难度也更高。
- kubelet 故障： kubelet 是节点与集群控制平面通信的核心组件。kubelet 崩溃或挂起会导致节点状态变为
NotReady，Pod 无法正常调度和运行。常见原因包括证书过期、API Server 连接超时、资源泄漏等。 - CRI（Container Runtime Interface）故障： CRI 是 kubelet 与容器运行时之间的接口。containerd、CRI-O 等运行时崩溃会导致容器无法创建、启动或停止。典型表现为 Pod 处于
ContainerCreating或CrashLoopBackOff状态。 - Docker 故障（已弃用但仍有存量）： 虽然 Kubernetes 1.24+ 已弃用 Docker 作为容器运行时，但大量存量集群仍在使用。Docker daemon 崩溃、Docker socket 权限问题、镜像拉取失败等都会导致节点异常。
软件故障恢复优先级：
- 自动重启： 配置 systemd 自动重启 kubelet、containerd 等关键服务。
- 健康检查： 使用 kubelet 的
--healthz-bind-address和--healthz-port参数暴露健康检查端点，配合外部监控系统进行探测。 - 版本回滚： 当软件升级导致故障时，自动触发版本回滚机制。
2.3 网络故障（CNI / DNS / 带宽）
网络故障是 Kubernetes 集群中最隐蔽、最难排查的异常类型。网络问题可能影响 Pod 间通信、DNS 解析、外部访问等多个层面，且故障现象往往与硬件或软件故障相似。
| 故障类型 | 典型表现 | 影响范围 | 自动恢复策略 |
|---|---|---|---|
| CNI 故障 | Pod 无法获取 IP、网络策略失效、跨节点通信中断 | 节点上所有 Pod | 重启 CNI 插件 Pod → 重建网络接口 → 节点 cordon |
| DNS 故障 | Pod 内域名解析失败、CoreDNS Pod 崩溃、DNS 缓存污染 | 集群内所有服务发现 | 自动扩容 CoreDNS 副本 → 清除 DNS 缓存 → 切换 DNS 后端 |
| 带宽故障 | 网络延迟高、丢包率上升、带宽耗尽 | 节点上部分或全部 Pod | 流量整形 → 限流 → 节点隔离 → 带宽扩容 |
网络故障排查避坑： 不要仅依赖
kubectl get nodes 判断节点网络状态。节点状态为 Ready 不代表网络正常。建议部署 网络连通性探针（如 ping、curl、DNS 解析测试）作为独立监控指标，避免误判。
2.4 故障分类与自动恢复策略映射
不同的故障类型需要匹配不同的自动恢复策略。以下表格总结了三大类故障的恢复策略选择原则和典型 MTTR 目标。
| 故障大类 | 恢复策略 | 典型 MTTR 目标 | 关键依赖 |
|---|---|---|---|
| 硬件故障 | 节点 cordon → Pod 驱逐 → 节点替换（Cluster Autoscaler / 裸机管理） | < 5 分钟 | NPD、Prometheus、Cluster Autoscaler |
| 软件故障 | 组件重启 → 健康检查 → 版本回滚 → 节点 cordon（最后手段） | < 3 分钟 | systemd、kubelet healthz、版本管理工具 |
| 网络故障 | 流量整形 → 限流 → 节点隔离 → 带宽扩容 → CNI 重建 | < 8 分钟 | 网络探针、CNI 插件、DNS 监控、带宽管理工具 |
MTTR 复盘关键指标：
- MTTD（Mean Time to Detect）： 从故障发生到被监控系统检测到的时间。硬件故障 MTTD 应 < 30 秒，软件故障 < 10 秒，网络故障 < 20 秒。
- MTTR（Mean Time to Resolve）： 从故障检测到完全恢复的时间。硬件故障 MTTR 应 < 5 分钟，软件故障 < 3 分钟，网络故障 < 8 分钟。
- 恢复成功率： 自动恢复策略成功恢复节点的比例。目标 > 95%。