3、节点故障类型与影响分析：硬件故障、内核崩溃、网络分区、kubelet停止响应、资源耗尽对Pod运行的影响
Kubernetes 集群的稳定性建立在每个工作节点的健康基础之上。节点故障并非单一场景，而是涵盖硬件、操作系统、网络、组件及资源等多个层面。不同故障类型对 Pod 运行状态、调度决策及集群自愈机制的影响存在显著差异。本节将系统分析五种核心故障模式及其传导路径。
3.1 故障类型全景与影响矩阵
下表从故障层面、典型表现、检测机制、Pod 行为及恢复方式五个维度，对五种节点故障进行横向对比：
| 故障类型 | 故障层面 | 典型表现 | K8s 检测机制 | Pod 行为 | 恢复方式 |
|---|---|---|---|---|---|
| 硬件故障 | 物理/虚拟化层 | 磁盘 I/O 超时、内存 ECC 错误、网卡 down | Node Problem Detector + 心跳超时 | Pod 直接终止，无法重新调度 | 节点修复后自动恢复 |
| 内核崩溃 | 操作系统层 | Kernel Panic、系统完全无响应 | 心跳丢失 → NodeReady=False | Pod 被强制终止，状态变为 Unknown | 节点重启后 kubelet 重新注册 |
| 网络分区 | 网络层 | 节点间连通性中断、CNI 插件异常 | 节点控制器通过 NodeLifecycleController 检测 | Pod 仍在运行但无法对外服务 | 网络恢复后自动修复 |
| kubelet 停止响应 | 组件层 | kubelet 进程挂起或 OOM | API Server 心跳超时 → NodeReady=Unknown | 已有 Pod 继续运行，但无法新建/更新 | kubelet 重启后恢复 |
| 资源耗尽 | 资源调度层 | 磁盘压力、内存压力、PID 耗尽 | kubelet 定期上报 Condition | 触发 Pod Eviction，驱逐低优先级 Pod | 资源释放后自动恢复 |
3.2 故障传导路径与 Pod 生命周期影响
下图展示了五种故障从发生到影响 Pod 的完整传导路径，以及 Kubernetes 控制平面的响应机制：
3.3 各故障类型深度分析
3.3.1 硬件故障
硬件故障是最底层的节点失效模式，通常由物理设备老化、环境异常或虚拟化层缺陷引发。Kubernetes 本身不具备硬件感知能力，需要借助 Node Problem Detector (NPD) 等外部组件将硬件告警转换为 NodeCondition。
- 磁盘故障：导致 Pod 读写持久卷时出现 I/O 错误，容器可能进入 CrashLoopBackOff 状态。
- 内存故障：触发 ECC 纠错或系统 MCE，严重时导致节点完全宕机。
- 网卡故障：节点心跳丢失，控制面在 pod-eviction-timeout（默认 5 分钟）后标记节点为 NotReady。
--node-problem-detector 的自定义规则，将硬件故障事件上报到 API Server，触发自动化修复流程（如节点排水 + 重启）。
3.3.2 内核崩溃
内核崩溃（Kernel Panic）是操作系统级别的致命错误，节点完全丧失响应能力。kubelet 无法上报心跳，API Server 在 node-monitor-grace-period（默认 40 秒）后标记节点为 NodeReady=False。
# 查看节点状态变化
kubectl get nodes -o wide
kubectl describe node <node-name> | grep -A 5 Conditions
# 典型输出
Conditions:
Type Status LastHeartbeatTime LastTransitionTime
---- ------ ----------------- ------------------
Ready Unknown 2024-01-15T10:30:00Z 2024-01-15T10:30:00Z
Pod 在 pod-eviction-timeout（默认 5 分钟）后进入 Terminating 状态，调度器在其他可用节点上重建 Pod。但需注意：StatefulSet 的 Pod 不会自动重建，需要人工介入处理 PVC 绑定问题。
3.3.3 网络分区
网络分区是最隐蔽的故障类型之一。节点上的 Pod 进程仍在运行，但无法与 API Server 或其他节点通信。Kubernetes 通过 NodeLifecycleController 检测心跳超时来识别网络分区。
网络分区对 Pod 的影响分为两个层面：
- 控制面影响：节点被标记为 NotReady，调度器停止向该节点调度新 Pod。
- 数据面影响：已有 Pod 的 Service 访问可能中断，特别是使用 Headless Service 或 EndpointSlice 的场景。
terminationGracePeriodSeconds 机制。
3.3.4 kubelet 停止响应
kubelet 是节点上最核心的 K8s 组件。当 kubelet 因进程挂起、OOM 或配置错误而停止响应时，API Server 无法获取节点状态更新，但 已有 Pod 的容器进程不受影响。
kubelet 停止响应的典型影响链：
- 节点状态变为
NodeReady=Unknown - 无法执行 Pod 创建、更新、删除操作
- 资源统计（kubectl top node）不可用
- 节点上的 Volume 挂载/卸载操作失败
# 检查 kubelet 日志
journalctl -u kubelet -n 100 --no-pager
# 重启 kubelet
systemctl restart kubelet
# 验证恢复
kubectl get nodes <node-name> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
3.3.5 资源耗尽
资源耗尽是一种“软故障”，节点仍在运行但资源严重不足。kubelet 通过内置的 Eviction Manager 监控资源压力指标，当超过阈值时触发 Pod 驱逐。
Kubernetes 定义了四种资源压力条件：
| 资源类型 | NodeCondition | 默认驱逐阈值 | Pod 影响 |
|---|---|---|---|
| 磁盘空间 | DiskPressure | nodefs.available < 10% | 驱逐使用 EmptyDir 的 Pod |
| 内存 | MemoryPressure | memory.available < 100Mi | 驱逐 BestEffort 和 Burstable Pod |
| PID | PIDPressure | pid.available < 5% | 驱逐低优先级 Pod |
| 磁盘 inode | DiskPressure | nodefs.inodesFree < 5% | 驱逐使用本地存储的 Pod |
--eviction-hard 和 --eviction-soft 参数自定义驱逐阈值，并设置 --eviction-soft-grace-period 为资源回收争取时间。对于关键业务 Pod，设置 priorityClassName 为高优先级以避免被优先驱逐。
3.4 故障影响对比总结
下表从 Pod 恢复时间、数据安全性和运维干预需求三个维度，对五种故障进行综合评估：
| 故障类型 | Pod 恢复时间 | 数据安全性 | 运维干预需求 | 自动恢复能力 |
|---|---|---|---|---|
| 硬件故障 | 5-15 分钟（含节点修复） | 低（可能丢失未持久化数据） | 高（需修复或替换硬件） | 部分（依赖 NPD + 自动化） |
| 内核崩溃 | 5-10 分钟（含节点重启） | 中（容器文件系统可能损坏） | 中（需确认根因） | 部分（节点重启后自动恢复） |
| 网络分区 | 5 分钟（pod-eviction-timeout） | 高（Pod 进程仍在运行） | 低（网络恢复后自动修复） | 高 |
| kubelet 停止 | 5 分钟（pod-eviction-timeout） | 高（已有 Pod 继续运行） | 低（重启 kubelet 即可） | 高 |
| 资源耗尽 | 立即（触发驱逐后） | 中（被驱逐 Pod 可能未完成清理） | 低（资源释放后自动恢复） | 高（自动驱逐机制） |