NFS on Liangweidong's blog

NFS 存储实战：单节点 + Keepalived 双机热备 + nfs-subdir 动态供给

Tue, 15 Nov 2016 00:00:00 +0800

为什么 NFS 在 K8s 时代还有用

很多人觉得 K8s 时代应该用 Rook-Ceph / Longhorn 这类"云原生存储"，NFS 是"老古董"。但实际上：

NFS 在 RWX 场景（多个 Pod 同时读写同一份数据）依然是最稳的
NFS + nfs-subdir-external-provisioner 是 K8s 动态 PV 的"最短路径"——5 分钟搞定一个 StorageClass
NFS + Keepalived + rsync 组成"穷人版"高可用，不需要 3 副本，单机故障 30 秒恢复
在国产化、私有化场景，NFS 是"无 Ceph 也能跑"的兜底方案

适用版本：NFS 4.1 / nfs-subdir-external-provisioner 4.0.18 / Ubuntu 22.04

1. 单节点 NFS 服务

1.1 安装服务端

1
2
3
4
5
6
7


apt install -y nfs-kernel-server

# 验证
systemctl is-enabled nfs-server
systemctl status nfs-server
cat /proc/fs/nfsd/versions
# +3 +4 +4.1 +4.2

1.2 共享目录

1
2
3
4
5
6
7


mkdir -p /home/nfs
chown -R nobody:nogroup /home/nfs
chmod 777 /home/nfs

mkdir -p /nfs
chown -R nobody:nogroup /nfs
chmod 777 /nfs

1.3 配置 /etc/exports

1
2


echo "/home/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
echo "/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports

参数解释：

*：所有网段可访问（生产应换成具体子网）
rw：读写
sync：同步写入内存和硬盘
no_root_squash：root 用户保留权限
no_subtree_check：不检查父目录权限

应用：

1
2
3
4


exportfs -a
systemctl restart nfs-server
exportfs -v
showmount -e

1.4 所有节点安装客户端

1
2
3
4


apt install -y nfs-common
showmount -e <nfs-server-ip>
# Export list for <nfs-server-ip>:
# /home/nfs *

1.5 客户端挂载测试

1
2
3


mount -t nfs <nfs-server-ip>:/home/nfs /mnt
df -h
umount /mnt

1.6 客户端常见挂不上

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 一些机器 mount 失败：mount.nfs: Connection timed out
# 解决：
mount -t nfs -o vers=3,nolock,proto=tcp <nfs-server-ip>:/nfs /mnt/nfs

# K8s 上修改 StorageClass
kubectl edit storageclass nfs-client

mountOptions:
 - vers=3
 - nolock
 - proto=tcp

2. K8s 中使用 NFS 存储

2.1 直接在 Pod 中引用 NFS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


apiVersion: apps/v1
kind: Deployment
metadata:
 name: redis
spec:
 selector:
 matchLabels:
 app: redis
 template:
 metadata:
 labels:
 app: redis
 spec:
 containers:
 - image: redis
 name: redis
 env:
 - name: ALLOW_EMPTY_PASSWORD
 value: "yes"
 volumeMounts:
 - name: redis-persistent-storage
 mountPath: /data
 volumes:
 - name: redis-persistent-storage
 nfs:
 path: /home/nfs
 server: <nfs-server-ip>

2.2 静态 PV + PVC

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: v1
kind: PersistentVolume
metadata:
 name: nfs-pv
 namespace: go
spec:
 capacity:
 storage: 2Gi
 volumeMode: Filesystem
 accessModes:
 - ReadWriteMany
 persistentVolumeReclaimPolicy: Recycle
 storageClassName: nfs
 mountOptions:
 - hard
 - nfsvers=4.1
 nfs:
 path: /nfs
 server: <nfs-server-ip>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nfs-pvc
 namespace: go
spec:
 storageClassName: nfs
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 2Gi

PV 卡在 Terminating 时的强删：

1

kubectl patch pv nfs-pv -p '{"metadata":{"finalizers":null}}' -n go

2.3 动态 StorageClass（推荐）

nfs-subdir-external-provisioner 是 NFS 动态供给的标配——它会监听 PVC 自动在 NFS 上创建子目录。

1
2
3
4


cd /data/softs
tar -xvf nfs-subdir-external-provisioner-4.0.18.tgz
mv nfs-subdir-external-provisioner /data/k8scnf/nfs/
cd /data/k8scnf/nfs/nfs-subdir-external-provisioner/

修改 values.yaml：

1
2
3
4


repository: registry.cn-shenzhen.aliyuncs.com/atomic/nfs-subdir-external-provisioner
nfs:
 server: <nfs-server-ip>
 path: /home/nfs

安装：

1
2


kubectl create namespace nfs
helm install nfs-subdir-external-provisioner . -n nfs

设置默认 StorageClass：

1

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

卸载：

1
2
3
4
5
6
7


helm uninstall nfs-subdir-external-provisioner -n nfs
kubectl delete namespace nfs
kubectl delete serviceaccount nfs-client-provisioner -n nfs
kubectl delete clusterrolebinding run-nfs-subdir-external-provisioner
kubectl delete role/leader-locking-nfs-subdir-external-provisioner -n nfs
kubectl delete rolebinding/leader-locking-nfs-subdir-external-provisioner -n nfs
kubectl delete storageclass nfs-client

2.4 测试动态 PV

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


cat << "EOF" > test-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-claim
 namespace: nfs
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Mi
 storageClassName: nfs-client
EOF

cat << "EOF" > test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 namespace: nfs
spec:
 containers:
 - name: test-pod
 image: busybox
 command: ["/bin/sh", "-c", "echo SUCCESS > /data/SUCCESS; sleep 3600"]
 volumeMounts:
 - name: nfs-pvc
 mountPath: /data
 volumes:
 - name: nfs-pvc
 persistentVolumeClaim:
 claimName: test-claim
 restartPolicy: Never
EOF

kubectl apply -f test-claim.yaml
kubectl apply -f test-pod.yaml

# 等 1 分钟后
ls /nfs/nfs-test-claim-pvc-*/
# 看到 SUCCESS 文件

kubectl delete -f test-pod.yaml
kubectl delete -f test-claim.yaml
# NFS 上的 pvc 目录自动清理

3. 双机热备 + rsync/lsyncd

3.1 架构

1
2
3
4
5
6
7


┌──────────────┐ keepalived ┌──────────────┐
│ worker4 │ ←── VRRP VIP ────→ │ worker2 │
│ nfs-server │ <10.x.x.x> │ nfs-server │
│ rsync 主 │ │ rsync 备 │
└──────────────┘ └──────────────┘
 ↓ ↓
 /nfs <──── lsyncd + rsync 实时同步 ────/nfs

3.2 两台机器都装 NFS + keepalived

两台机器都跑 NFS 服务（同一份数据），keepalived 决定哪个 IP 在线。

1
2
3
4
5
6
7
8


# 两台都执行
apt install -y nfs-kernel-server
mkdir -p /nfs
chown -R nobody:nogroup /nfs
chmod 777 /nfs
echo "/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
exportfs -a
systemctl restart nfs-server

3.3 keepalived 配置（必须 nopreempt）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


vrrp_instance VI_1 {
 state BACKUP # 两台都是 BACKUP（vs master）
 interface enp3s0
 virtual_router_id 111
 priority 100 # worker4 设 100
 priority 80 # worker2 设 80
 advert_int 1
 nopreempt # **必须**：防止主备反复切换时数据丢失
 authentication { auth_type PASS; auth_pass 1111; }
 virtual_ipaddress { <nfs-vip>; }
}

健康检查脚本（nfs 挂了就把 keepalived 停掉，让 VIP 漂移）：

1
2
3
4
5
6
7
8
9


#!/bin/bash
A=`ps -C nfsd --no-header | wc -l`
if [ $A -eq 0 ]; then
 systemctl restart nfs-server.service
 sleep 2
 if [ `ps -C nfsd --no-header | wc -l` -eq 0 ]; then
 pkill keepalived
 fi
fi

NFS 双机热备的 nfs_check.sh 比 keepalived 自身的 chk_*.sh 更重要——必须让 NFS 挂了之后主动让出 VIP，否则客户端挂载会卡死。

3.4 rsync + lsyncd 实时同步

lsyncd 监听 inotify 事件触发 rsync 同步，是 Linux 文件实时同步的"标配"。

1
2


apt install -y rsync lsyncd
systemctl enable --now rsync lsyncd

内核参数优化（必做，否则 inotify 句柄不够）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


sysctl -w fs.inotify.max_queued_events="99999999"
sysctl -w fs.inotify.max_user_watches="99999999"
sysctl -w fs.inotify.max_user_instances="65535"

cat >> /etc/sysctl.conf << "EOF"
fs.inotify.max_queued_events=99999999
fs.inotify.max_user_watches=99999999
fs.inotify.max_user_instances=65535
EOF
sysctl -p

rsync 配置文件（/etc/rsyncd.conf）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsyncd.lock
[backup]
path = /nfs
comment = sync nfs from client
uid = root
gid = root
port = 873
ignore errors
use chroot = no
read only = no
list = no
max connections = 200
timeout = 600
auth users = root
secrets file = /etc/rsync.password
hosts allow = 10.0.0.0/8

密码文件：

1
2
3
4
5


echo 'root:{{NFS_RSYNC_PASSWORD}}' > /etc/rsync.password
chmod 600 /etc/rsync.password

echo "{{NFS_RSYNC_PASSWORD}}" > /etc/rsyncd.password
chmod 600 /etc/rsyncd.password

实际密码用占位符 {{NFS_RSYNC_PASSWORD}} 替代，原密码登记在 _drafts/私人笔记.md。

lsyncd 配置（worker4 把 /nfs 推到 worker2）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


settings {
 logfile = "/var/log/lsyncd/lsyncd.log",
 statusFile = "/var/log/lsyncd/lsyncd.status",
 inotifyMode = "CloseWrite",
 maxProcesses = 8,
}
sync {
 default.rsync,
 source = "/nfs",
 target = "root@<worker2-ip>::backup",
 delete = true,
 delay = 1,
 exclude = {".*"},
 rsync = {
 binary = "/usr/bin/rsync",
 archive = true,
 compress = false,
 verbose = true,
 password_file = "/etc/rsyncd.password",
 _extra = {"--bwlimit=20000"}
 }
}

worker2 的配置对称——把 target 指向 worker4。

3.5 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 在 worker4 上
mount -t nfs <nfs-vip>:/nfs /mnt
cd /mnt
echo "test" > test.txt
cd ../
umount /mnt

# 在 worker2 上
ls /nfs
# 应该能看到 test.txt

3.6 模拟故障

停 worker4 keepalived → VIP 飘到 worker2
启 worker4 keepalived（nopreempt 不会让 VIP 回来）
停 worker2 keepalived → VIP 飘回 worker4
内网其他机器 ping VIP 一直是通的

4. Ingress 持久化日志

Ingress-nginx 容器本身是无状态的，access log 默认写到 stdout（容器内）。生产场景希望 log 落盘到 NFS，方便 ELK / Loki 采集。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


cat << "EOF" > /data/k8scnf/ingress-nginx/ingress-nfs.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: ingress-nfs
 namespace: ingress-nginx
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 10Gi
 storageClassName: nfs-client
EOF

kubectl apply -f /data/k8scnf/ingress-nginx/ingress-nfs.yaml

修改 ingress-nginx-controller：

1

kubectl edit -n ingress-nginx DaemonSet/ingress-nginx-controller

1
2
3
4
5
6
7


volumeMounts:
 - mountPath: /var/log/nginx/
 name: ingress-nfs
volumes:
 - name: ingress-nfs
 persistentVolumeClaim:
 claimName: ingress-nfs

修改 ConfigMap 改变日志格式：

1

kubectl edit -n ingress-nginx configmaps/ingress-nginx-controller

NFS 上自动创建 default-ingress-nfs-pvc-xxx/ 目录，所有 ingress-controller Pod 的 access log 都会落在这里。

单点故障注意：NFS 本身是单点，NFS 挂了 ingress 日志会卡。生产建议加 keepalived VIP（本文方案）。

5. 排错

现象	原因	解决
`mount.nfs: Connection timed out`	防火墙	放通 2049/111/20048
`mount.nfs: Operation not permitted`	NFS 版本不匹配	加 `-o vers=3,nolock,proto=tcp`
PVC 一直 Pending	节点没装 nfs-common	所有节点 `apt install nfs-common`
nfs-subdir 装不上	helm chart 镜像拉不到	改国内源 + push 私有 harbor
双机热备 VIP 频繁漂移	没设 nopreempt	keepalived.conf 加 `nopreempt`
lsyncd 同步延迟大	inotify 句柄不够	调 `fs.inotify.*` 参数

6. 2024 NFS 现状

本文 2016 年写时 NFS 还是 K8s 动态存储的"穷人首选"。8 年后（2024）回望，NFS 协议本身有了 NFS 4.2、pNFS 等增强，但更重要的是生态位发生了变化——长虹、Ceph/Longhorn/OpenEBS 等云原生存储在 K8s 场景蚕食了 NFS 的份额。下面是当前状态。

6.1 NFS 协议本身：4.2 与 pNFS

NFS 版本	发布时间	关键特性	2024 现状
NFSv3	1995	异步写、TCP 支持	老系统兼容仍用
NFSv4.0	2003	状态化、复合操作、Kerberos	Linux 默认
NFSv4.1	2010	pNFS（并行 NFS）、会话	主流
NFSv4.2	2016	服务器端复制、稀疏文件、空间预留、应用数据块（ADBs）	2024 标配

pNFS 的核心思想：把元数据和数据通道分离——元数据服务器只管 layout，客户端直接和多个存储节点传输数据，理论上能做到并行带宽聚合（类似 CephFS 的 striping）。

1
2
3


# 挂载 pNFS（需要服务端支持）
mount -t nfs -o nfsvers=4.1,minorversion=1 <server>:/export /mnt
# 或 nfsvers=4.2 启用 4.2 特性

实际部署率：pNFS 在企业存储（NetApp / Dell EMC Isilon / IBM Spectrum Scale）早就支持，但Linux 内核的 pNFS client 直到 5.x 才稳定，很多 K8s 节点跑的还是 NFSv3/4.1 而不是 pNFS。

6.2 nfs-subdir-external-provisioner 现状

版本	时间	状态
v3.x	2019-2021	旧 API，CSI 转换中
v4.0.x	2022-2023	当时主流
v4.0.18+	2023-2024	当前推荐
v4.0.20+	2024	k8s 1.28+ 兼容

v4.x 关键变化：

完全重写为 CSI（Container Storage Interface） 驱动
支持 Kubernetes 1.25+（旧的 in-tree NFS provisioner 已废弃）
Helm chart 改为标准 oci:// 仓库：

1
2
3
4
5
6


# 2024 推荐装法（Helm 3.8+）
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
 --set nfs.server=<nfs-server-ip> \
 --set nfs.path=/home/nfs \
 -n nfs-client --create-namespace

6.3 2024 替代方案对比

方案	类型	适用场景	复杂度	性能	HA
NFS + nfs-subdir	文件（RWX）	中小规模、传统业务	低	中	需 keepalived 自建
Longhorn	块（RWX via NFS）	K8s 云原生首选	中	中	内置
Rook-Ceph	块/文件/对象	大规模、混合负载	高	高	内置（多副本）
OpenEBS	块/文件	国产化、CSI 友好	中	中	可选
CubeFS	文件/对象/块	国产云原生	中	高	内置
Vitess / TiDB	数据库专用	持久化数据库	高	高	内置
Local Path / HostPath	本地盘	单节点 / StatefulSet	低	最高	无
AWS EBS / GCP PD	云盘	云上	低	高	内置
NFS CSI driver for K8s	NFS 官方版	NFS 4.1+	低	中	自建

6.4 2024 选型建议

业务场景	推荐
CI/CD 临时构建、多 Pod 共享配置	NFS + nfs-subdir 仍最优（RWX 简单）
生产数据库（MySQL / PG / Redis）	云盘 / Rook-Ceph RBD / 本地盘（RWO 性能）
AI / 大数据	CephFS / Lustre / JuiceFS（高带宽）
国产化	CubeFS / 浪潮 AS13000
小团队 + 简单	Longhorn（一键装、UI 友好）
私有化 + 信创	NFS + nfs-subdir（Linux 原生 + 国产 OS 兼容）

6.5 实战：Longhorn 一键装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


# Longhorn 是 Rancher 出品的云原生块存储
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.4/deploy/longhorn.yaml

# 默认 StorageClass
kubectl get sc longhorn

# 创建一个 StatefulSet 用 Longhorn
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: pg
spec:
 serviceName: pg
 replicas: 1
 selector:
 matchLabels: { app: pg }
 template:
 metadata:
 labels: { app: pg }
 spec:
 containers:
 - name: pg
 image: postgres:16
 volumeMounts:
 - name: data
 mountPath: /var/lib/postgresql/data
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 storageClassName: longhorn
 resources:
 requests:
 storage: 10Gi
EOF

Longhorn 自动做 3 副本 + 跨节点同步 + 在线扩容 + 备份——NFS 的 keepalived + rsync 全套都不用做。

6.6 NFS 2024 仍然"有用"的场景

虽然新项目优先选 Longhorn/Ceph，但以下场景 NFS 仍是最佳选择：

跨 namespace / 跨集群共享数据（Longhorn 默认单集群）
Windows + Linux 混合客户端（NFS 协议通用性强）
AI 训练把数据集放在 NFS，多个训练 Pod 同时读（RWX）
传统业务——银行 ERP、政府办公系统（必须 NFS、SMB 协议）
国产化 / 信创项目（NFS 是 Linux 内核自带，不依赖任何商业软件）

6.7 一句话总结

2016 年的 NFS 4.1 + nfs-subdir + keepalived 方案在 2024 仍然能跑——但新项目建议直接用 Longhorn（块 + 简单）或 Ceph（大规模 + 混合）。

NFS 不是"过时"了，而是从默认选择退到备选——看场景用。

7. 小结

NFS 在 K8s 存储选型中仍然有一席之地：

动态 StorageClass（nfs-subdir）让 NFS 用法跟云盘一样简单
keepalived + rsync + lsyncd 组成"穷人版"高可用
NFS 单点风险依然存在，关键业务建议 Ceph / Longhorn
2024 新选择：Longhorn（首选）/ Rook-Ceph（大规模）/ 国产 CubeFS（信创）

下一步：Rook-Ceph 1.17 分布式存储：块存储 RBD + CephFS + OSD/MON。 2024 推荐：先看 Longhorn 官方文档（一键装，3 副本 + 备份），再做 Ceph。

Docker Volume 深度实践：命名卷、bind mount 与跨主机挂载

Tue, 15 Dec 2015 00:00:00 +0800

容器的文件系统是临时的——docker rm 时容器层全部销毁。任何需要持久化的数据，都必须挂载到 Volume 或 bind mount。这一篇把 Volume 的生命周期、Copy-on-Write 机制、跨主机挂载、共享卷在容器间传文件、清理策略一次性收齐。

阅读对象：需要把数据库 / 上传文件 / 配置中心等状态放到容器里的开发者、运维同学 覆盖范围：volumes vs bind mounts vs tmpfs + 命名卷操作 + Copy-on-Write + docker-compose 卷写法 + NFS / SSHFS / vieux 跨主机 + 共享卷传文件 + 清理策略

一、为什么需要 Volume

容器分层结构：

镜像层（Image Layer）：只读、共享，多个容器可共用
容器层（Container Layer）：读写、临时，容器销毁就消失

如果数据写在容器层，docker rm 那一刻数据就没了。Volume 就是把数据"挂"到宿主机文件系统上，绕开容器层，让数据活过容器生命周期。

二、三种挂载方式

Docker 1.9+（2015-11 GA）正式引入了 named volume（命名卷），与 bind mount、tmpfs 并列为三种挂载类型：

类型	路径	持久化	性能	适用
Volume	Docker 管理（默认 `/var/lib/docker/volumes/`）	是	优	数据库、上传文件、共享数据
bind mount	任意宿主机路径	是	优	配置文件、特殊路径、debug
tmpfs	宿主机内存	否（重启丢）	极优	敏感数据、临时缓存

When to use：

Volume（推荐）：数据库、长期存储——Docker 帮你管理路径、迁移、备份

bind mount：配置文件、日志、需要直接编辑宿主机文件的场景

tmpfs：密码、token、不想落盘的临时缓存

三、Volume 操作

3.1 命名卷的生命周期

1
2
3
4
5
6
7
8


# 创建（指定名字）
docker volume create data_volume

# 列出
docker volume ls

# 看详情
docker volume inspect data_volume

inspect 输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[
 {
 "CreatedAt": "2022-07-28T11:02:14+08:00",
 "Driver": "local",
 "Labels": null,
 "Mountpoint": "/var/lib/docker/volumes/data_volume/_data",
 "Name": "data_volume",
 "Scope": "local"
 }
]

关键字段：

Driver: local：默认驱动，只能用于当前 Docker 主机上的容器

Scope: local：本地范围（要跨主机挂载需要用其他 driver）

Mountpoint：数据在宿主机上的实际位置

3.2 隐式创建（run 时指定卷名）

如果不显式 docker volume create，docker run -v name:/path 会自动创建：

1

docker run -it --rm --name nginx -p 8080:80 -v demo-earthly:/usr/share/nginx/html nginx

3.3 Dockerfile 中声明

1
2
3
4


FROM nginx:latest

RUN echo "<h1>Hello from Volume</h1>" > /usr/share/nginx/html/index.html
VOLUME /usr/share/nginx/html

构建并运行：

1
2
3
4


docker build -t demo-earthly .
docker run -p 8080:80 demo-earthly
docker volume ls
# 输出随机卷名：20879e3f0bfaf0eed63cb7f37c4b9545084a703f888a230b8aedc2082c836281

每次启动新容器都会创建新卷（匿名卷），内容是 /usr/share/nginx/html。

3.4 删除

1
2
3
4
5
6
7
8


# 删指定卷
docker volume rm data_volume

# 删所有未挂载的卷
docker volume prune

# 删 dangling 镜像 + 未挂载卷（危险）
docker system prune -af --volumes

重要约束：docker volume rm 不能删正在被容器或服务使用的卷。docker volume prune 默认不会删正在使用的卷，但加 -f 也不会绕过这个保护——保护在 daemon 层。

四、Copy-on-Write 机制

docker build 时每条指令构建一层，只读。docker run 时构建一个读写容器层。

修改容器内某个文件时：

如果该文件在镜像层（只读），Docker 会从镜像层"复制"一份到容器层
容器层是读写层，修改只在容器层生效
容器销毁，容器层消失，修改也没了——这就是为什么需要 Volume

典型场景：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 容器内
echo "new content" > /etc/nginx/nginx.conf

# 容器外看
docker exec -it <container> cat /etc/nginx/nginx.conf
# 输出 "new content"

# 删容器
docker rm -f <container>

# 启动新容器
docker run -d nginx

# 新容器内的 /etc/nginx/nginx.conf 是默认的
# 原因：刚才的"new content"在容器层里，随容器销毁而消失

重要结论：容器层的修改不能跨容器共享。要让数据持久 + 跨容器共享，必须 Volume / bind mount。

五、bind mount vs Volume

5.1 语法对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Volume（短语法）
docker run -d -v mydata:/var/lib/mysql mysql:5.7

# bind mount（短语法）
docker run -d -v /host/path:/container/path nginx

# 长语法（--mount）— 更显式
docker run -d \
 --mount type=volume,source=mydata,target=/var/lib/mysql \
 mysql:5.7

docker run -d \
 --mount type=bind,source=/host/path,target=/container/path \
 nginx

5.2 长语法参数说明

参数	含义
`type`	`volume` / `bind` / `tmpfs`
`source` / `src`	卷名 / 宿主机路径
`destination` / `dst` / `target`	容器内路径
`readonly` / `ro`	是否只读挂载
`volume-opt`	额外 mount 选项（可多次）

5.3 实战：初始化数据到 Volume

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 创建两个卷
docker volume create test_nginx_html
docker volume create test_nginx_conf

# 准备数据到宿主机
sudo cp -r /home/nginx/html/* /var/lib/docker/volumes/test_nginx_html/_data
sudo cp /home/nginx/conf/my_custom.conf /var/lib/docker/volumes/test_nginx_conf/_data

# 启动容器，volume 自动挂载
docker run -d \
 --restart=always \
 -p 8080:8080 \
 --name test_nginx \
 --mount src=test_nginx_html,dst=/app \
 --mount src=test_nginx_conf,dst=/opt/bitnami/nginx/conf/server_blocks \
 bitnami/nginx:latest

Why 直接 cp 到 _data：volume 在宿主机上的真实路径是 /var/lib/docker/volumes/<name>/_data，容器启动前预先填数据是常见模式。也可以用 docker cp 复制到运行中的容器目录，但已挂载的 volume 路径会变。

六、docker-compose 里的卷

6.1 bind mount 写法

1
2
3
4
5
6
7
8


version: "3.2"
services:
 web:
 image: nginx:latest
 ports:
 - "8080:80"
 volumes:
 - ./target:/usr/share/nginx/html

6.2 命名卷 + 多容器共享

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


version: "3.2"
services:
 web:
 image: nginx:latest
 ports:
 - "8080:80"
 volumes:
 - html_files:/usr/share/nginx/html
 web1:
 image: nginx:latest
 ports:
 - "8081:80"
 volumes:
 - html_files:/usr/share/nginx/html

volumes:
 html_files:

docker compose up 时自动创建 <project_name>_html_files 命名卷，html_files 在 web 和 web1 之间共享。

6.3 引用已存在的卷

1
2
3


volumes:
 html_files:
 external: true

要先用 docker volume create html_files 创建，compose 才不会报错说找不到。

七、跨主机挂载：NFS

默认的 local driver 只能在当前主机用。Docker 1.9+ 内置支持 NFS 挂载（用 local driver 即可），不需要装额外插件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 安装 NFS 客户端
apt install nfs-common # Debian/Ubuntu
yum install -y nfs-utils # CentOS/RHEL

# 创建 NFS 卷
docker volume create --driver local \
 --opt type=nfs \
 --opt o=addr=10.0.0.10,rw \
 --opt device=:/path/to/dir \
 nfs_volume

挂载到容器：

1
2
3
4


docker run -d -it \
 --name myapp \
 --mount source=nfs_volume,target=/data \
 myapp:latest

docker-compose 写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


version: "3.2"
services:
 myapp:
 image: myapp:latest
 ports:
 - "8080:8080"
 volumes:
 - type: volume
 source: nfs_volume
 target: /data
 volume:
 nocopy: true

volumes:
 nfs_volume:
 driver_opts:
 type: "nfs"
 o: "addr=10.0.0.10,nolock,soft,rw"
 device: ":/path/to/dir"

Why 推荐 nolock,soft：网络抖动时 hard 会卡住进程、nolock 减少锁竞争、soft 失败会返回错误而不是 hang。

八、用 volume driver 把数据存到其他主机

Docker Volume Plugins 生态丰富：vieux/sshfs（已停更）、Azure File Storage、AWS EFS、S3 driver、GlusterFS、Ceph、IPFS…

重要：vieux/sshfs plugin 已经停更，生产不要用——新的容器场景推荐自建 NFS 或云厂商文件存储。

历史 demo（演示用）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 安装 sshfs 插件
docker plugin install --grant-all-permissions vieux/sshfs

# 用 sshfs 创建卷
docker volume create --driver vieux/sshfs \
 -o sshcmd=user@10.32.2.134:/home/user/sshvolume \
 -o password=yourpassword \
 mysshvolume

# 挂载到容器
docker run -id \
 --name testcon \
 --mount type=volume,volume-driver=vieux/sshfs,source=mysshvolume,target=/world \
 ubuntu /bin/bash

九、共享卷在容器间复制文件

Volume 的天然优势：多容器可同时挂载。可以用这个特性在容器间传文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 创建共享卷
docker volume create shared_data

# 2. 容器 A 写文件到卷
docker run -it --name=writer \
 --mount source=shared_data,destination=/data \
 ubuntu bash
# 在容器内
root@ded392c589ea:/# touch /data/demo.txt

# 3. 容器 B 读同一卷
docker run -it --name=reader \
 --mount source=shared_data,destination=/data \
 ubuntu bash
# 在容器内
root@feef37293ea5:/# ls /data
# 输出：demo.txt

典型场景：CI 流水线里"build 容器产出 artifacts → 测试容器拿同一份 artifacts 跑测试"，共享卷是干净的解法。

十、清理无用的卷

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 只删 dangling 卷
docker volume ls -f "dangling=true" -q | xargs --no-run-if-empty docker volume rm

# 一键清（删所有未挂载的卷 + dangling 镜像 + 停止的容器）
docker system prune -af --volumes

# 找出最大的卷 / 目录，定位"占空间元凶"
du -sh * | sort -hr | head

# 清理 2 天前的文件
find ./ -mtime +1 | xargs rm -rf

十一、要点回顾

Volume / bind mount / tmpfs 三选一，数据库用 Volume、配置用 bind mount、敏感数据用 tmpfs
容器层是临时的——任何持久化数据必须挂到卷或宿主机目录
Copy-on-Write决定了"修改容器内文件 ≠ 改镜像"——重启后默认文件
docker volume rm 不能删正在使用的卷——保护在 daemon 层
NFS 跨主机用内置 local driver 即可，不需要装额外插件
共享卷传文件是多容器协作的"原始"模式
vieux/sshfs 已停更——生产场景用云厂商文件存储或自建 NFS

十二、小结

Volume 是 Docker 持久化的"地基"。理解了：

三种挂载类型——volume / bind mount / tmpfs 的取舍
Copy-on-Write——容器层为什么不能持久化
NFS 跨主机——单机 → 多机的进阶
共享卷传文件——容器间协作的底层模式

剩下的就是"挑对的存储后端"：本地 SSD 给数据库、NFS / EFS / Ceph 给共享文件、S3 兼容给对象存储。

下一步：理解了单机 Volume，下一步是 Kubernetes 的 PV / PVC / StorageClass——把"申请存储"变成声明式 API，配合 CSI 驱动对接各种后端（NFS / Ceph / 云盘）。K8s 的存储抽象在 1.21+ 进入 GA，是云原生存储的事实标准。