kubernetes节点故障自愈是通过npd实时捕获硬件/内核异常、结合探针分层健康检查、控制器自动驱逐与重调度、基础设施联动实现节点替换，并经混沌测试验证的闭环自动化过程。
节点故障自愈不是等出问题再手动救火，而是让集群在检测到异常后自动完成隔离、迁移、恢复全过程。核心在于把“可观测性”和“可执行动作”打通，形成闭环。
健康检查必须覆盖三层：节点、Pod、应用
只依赖K8s默认的NodeReady状态远远不够。一个节点可能网络通、kubelet活，但磁盘满、CPU锁死或容器运行时崩溃，此时Pod已无法正常服务，但K8s仍认为它“可用”。
-
节点层：用
kubectl describe node查看Conditions（如DiskPressure、MemoryPressure、PIDPressure），配合node-problem-detector捕获内核OOM、硬件错误等底层事件 -
Pod层：为每个Deployment配置
livenessProbe（探测应用进程是否存活）和readinessProbe（探测服务是否可接收流量），避免将请求路由到“假活”容器 -
应用层：在Probe中调用真实业务接口（如
/healthz?full=1），检查数据库连接、缓存连通性、下游依赖状态，而非仅返回HTTP 200
故障识别后自动触发调度策略
一旦确认节点不可用，K8s会自动驱逐其上的Pod，但默认行为只是“重调度”，不保证新Pod能真正跑起来。需叠加策略确保落地可靠：
- 设置
podTopologySpreadConstraints，强制新Pod分散到不同可用区，避免所有副本挤在同一AZ - 使用
nodeAffinity+taints/tolerations预留专用节点池，确保关键服务（如ETL网关、指标采集器）有资源兜底 - 对StatefulSet类有状态应用，配合
volumeBindingMode: WaitForFirstConsumer防止PVC绑定失败导致Pod卡在Pending
节点级自动恢复需与基础设施联动
K8s本身不管理物理节点，自愈能力必须延伸到IaaS层才能闭环：
- 在云环境（如AWS/Aliyun）启用自动伸缩组（ASG/ESS），配置“节点失联3分钟自动替换”，新节点加入后自动打标签、加污点、注册为Ready
- 在IDC环境中，结合IPMI或Redfish API实现硬件级看门狗：当节点连续无响应，自动硬重启；若重启失败，标记为“永久故障”并通知运维
- 通过Operator（如
machine-config-operator或自研NodeReconciler）监听Node对象变更，自动修复kubelet配置、清理残留容器、重装CNI插件
验证自愈是否真正生效
很多团队配置了探针和策略，却从不验证效果。建议每月做一次“混沌测试”：
- 用
chaos-mesh随机kill kubelet、模拟网络分区、注入磁盘IO hang - 观察Prometheus中
kube_node_status_phase{phase="NotReady"}持续时间是否≤2分钟 - 检查关键服务Pod的
restarts次数和scheduler_duration_seconds_bucketP95是否稳定 - 确认业务监控（如API成功率、端到端延迟）在故障窗口内波动幅度＜5%，且10分钟内完全回归基线
