节点失联后的 Pod 重建与卷恢复：先判定门槛
源笔记讨论缩短节点宕机后的恢复时间，但把“节点被判失联”“旧 Pod 被移除”“新 Pod 可调度”“卷可安全使用”合并为一个倒计时。实际恢复应逐段取证；节点 NotReady 本身不证明旧节点已经停机。
| 阶段 | 应记录的只读证据 | 决策边界 |
|---|---|---|
| 节点状态 | Node condition、Lease 更新时间、kubelet 与网络证据、故障起始时间 | 区分主机断电、kubelet 故障和控制面网络分区；不能仅凭 NotReady 判定旧实例已停止。 |
| Pod 替换 | 工作负载副本、旧 Pod 删除状态、相关 NoExecute taint 与 toleration、事件 | tolerationSeconds 影响 taint 出现后的容忍时间，不能消除前面的节点失联检测时间。 |
| 新 Pod 调度 | 调度事件、资源、污点与亲和条件、候选节点容量 | 多副本和反亲和有助于分散故障域；硬性反亲和也可能使副本保持 Pending。 |
| 卷与应用 | PVC/PV、Pod 挂载事件、适用时的 VolumeAttachment、CSI/存储端状态、应用一致性 | 卷可挂载与应用可安全恢复是两个验收条件；有状态服务尤其要防旧节点重新写入。 |
对 StatefulSet 或独占写卷，任何强制删除旧 Pod、将节点标为 out-of-service、手工处理 VolumeAttachment 等动作，都要先有旧节点已隔离或停机、存储侧不会双写的独立证据，并确认目标版本和驱动支持该恢复路径。错误判定会造成两个同身份实例并行或数据损坏。自动监控一看到 NotReady 就施加 out-of-service taint 的做法缺少这个门槛，不宜照搬。
源笔记把 NFS 与 VolumeAttachment 绑定为普遍关系，但传统 NFS 挂载路径未必有 CSI attach/VolumeAttachment；应以实际 provisioner 和 CSI 能力判断。原文还建议普遍把 NFS hard 改为 soft、修改 PV claimRef、删除 VolumeAttachment，并给出固定恢复秒数。这些都不是通用恢复步骤：soft 可能把瞬时故障转为应用 I/O 错误；改绑定关系或删附件对象可能破坏卷状态；恢复时间受故障检测、控制器、调度、存储和应用启动共同影响。原文的版本门槛、默认参数与预计耗时均待在目标环境核验。
演练时分别记录失联→状态变化→旧 Pod 退出 API→新 Pod 调度→卷可用→业务读写恢复的时间；以实际请求和数据一致性作为终点。诊断入口见 节点 NotReady、Pod Pending 和 PVC/挂载失败。
来源：有道导出中的节点失联与工作负载恢复收藏笔记。本页为脱敏后的编辑提炼，不是可直接执行的恢复手册。