如何实现Kubernetes单副本长计算作业从节点故障中恢复？

你提到的单副本长计算作业在节点故障时的恢复问题，核心痛点在于emptyDir是节点本地存储，节点失效后数据就丢失了。下面是几个针对性的解决思路：

1. 用持久化存储替换emptyDir #

这是最直接的方案，把检查点存储从节点本地的emptyDir换成集群级的持久化存储，确保Pod调度到新节点后能继续访问检查点：

• 创建PersistentVolumeClaim（PVC），绑定到支持跨节点访问的存储后端（比如NFS、Ceph RBD、云厂商的块存储或文件存储）。
• 修改Pod模板，将PVC挂载到容器内的指定路径（比如/persistent/checkpoint.txt），替换原来的emptyDir路径。
• 调整作业的检查点写入逻辑，将中间数据写到持久化存储路径下。

这样当节点故障，Kubernetes将Pod重新调度到其他节点时，新Pod会挂载同一个PVC，直接读取之前的检查点恢复计算。

2. 定时同步检查点到远程存储 #

如果不想依赖集群级持久化存储，也可以在作业进程内或通过辅助脚本，定时将本地检查点同步到远程对象存储（比如MinIO、S3兼容存储）：

• 在作业容器内集成对象存储的SDK，或者编写简单的Shell脚本，每隔固定时间（比如1小时）将/emptydir/checkpoint.txt上传到远程存储。
• 在Pod启动脚本中添加逻辑：启动作业前先从远程存储拉取最新的检查点到本地目录，再启动作业并从检查点恢复。

示例启动脚本：

#!/bin/bash
# 从远程存储拉取最新检查点
mc cp myminio/checkpoints/checkpoint.txt /emptydir/checkpoint.txt || echo "No existing checkpoint found"
# 启动作业并指定检查点路径
./long-running-job --resume-from /emptydir/checkpoint.txt

这种方案的优势是存储成本较低，且不受集群存储架构限制，适合分布式环境。

3. 结合StatefulSet优化恢复流程 #

如果你的作业需要稳定的标识或存储绑定，可以用StatefulSet替代普通的Job或Deployment：

• StatefulSet的Pod会有稳定的网络标识，且每个Pod绑定的PVC是固定的，避免调度后存储挂载混乱。
• 配合volumeClaimTemplates可以自动为Pod创建专属的持久化存储，进一步简化配置。

注意事项 #

• 检查点频率：平衡性能与数据丢失风险，比如CPU密集型作业可以每1-2小时写一次检查点，IO密集型作业适当降低频率。
• 存储性能：选择性能匹配的存储后端，比如频繁写检查点的场景优先用块存储，避免文件存储的延迟影响作业效率。
• 检查点完整性：写入检查点时确保原子性（比如先写临时文件，再重命名为目标文件），避免节点故障时生成损坏的检查点文件。

内容的提问来源于stack exchange，提问作者Pro.Hessam