在 docker swarm 中，节点下线后持久化卷无法挂载的核心原因是存储驱动（如 local）默认不支持多节点并发访问。要解决这个问题，必须使用支持网络共享或分布式一致性的外部存储插件，例如 nfs、ceph rbd 或 glusterfs，并在创建服务时指定对应的 volume driver。
为什么本地卷会导致挂载失败
当使用默认的 local 驱动时，Docker 守护进程会将卷直接绑定到宿主机文件系统上。如果承载该卷的节点意外离线或重启，Swarm 调度器会将任务迁移到其他节点，但新节点上没有对应的物理路径，导致挂载失败并进入 FAILED 状态。
docker service create \ --name db \ --mount type=volume,source=mydata,target=/var/lib/mysql,volume-driver=local \ mysql:latest
上述命令创建的 db 服务依赖本地卷。若运行该服务的节点断开连接，Swarm 尝试在其他节点重新调度时，由于其他节点不存在 mydata 的物理存储，任务将无法启动。这种设计适用于单节点开发环境，但在生产集群的多节点高可用场景下是致命的缺陷。
如何配置网络共享卷
通过指定支持网络协议的 volume driver，可以将卷映射为网络路径。以 NFS 为例，需要在所有 Swarm 节点上安装 NFS 客户端，并确保网络可达。创建服务时，使用 nfs 驱动并指定 o 参数来传递挂载选项。
docker service create \ --name web \ --mount type=volume,source=nfsvol,target=/data,volume-driver=nfs,volume-opt=type=nfs,volume-opt=device=:/,volume-opt=o=addr=192.168.1.100,rw \ nginx:latest
此配置将 web 服务的容器数据目录指向 NFS 服务器。无论任务被调度到哪个节点，只要该节点能访问 NFS 服务器，卷就能成功挂载。这种方式解决了节点下线后的数据持久化和跨节点访问问题，确保服务在故障转移后能立即恢复读写能力。
基于 NFS 配置的具体验证
在使用 NFS 驱动时，必须确认所有工作节点都能解析 NFS 服务器的地址并拥有读取权限。如果 NFS 服务器不可用，或者节点间的防火墙阻断了端口，卷挂载依然会失败。可以通过在节点上手动执行 mount 命令来预验证连通性，确保在生产环境中部署前排除网络障碍。
