docker volume 本身不支持内置大小限额，需结合宿主机能力实现：①绑定挂载xfs配额目录；②zfs驱动下为命名卷设子卷配额；③tmpfs限制临时数据；④应用层只读挂载与日志限流。
docker 的 volume 本身不提供内置的“大小限额”参数，-v 或 --volume 挂载方式完全不支持直接设配额，也不能靠 --storage-opt size= 控制（该参数对 overlay2 驱动无效，且只作用于容器根文件系统，不影响挂载的 volume）。所谓“通过 volume 存储限额参数防流氓容器”，本质是误解——真正可行的是把 volume 落到有配额能力的宿主机路径上，再由系统层拦截写入。
用绑定挂载（bind mount）+ XFS 配额控制 Volume 写入上限
这是最稳定、通用、无需改驱动的方案。核心逻辑：让容器写 Volume 的行为，等价于写一个受操作系统级配额约束的目录。
- 宿主机需使用 XFS 文件系统（推荐），并启用项目配额（project quota）
# 挂载时开启配额支持（如 /dev/sdb1 挂载到 /mnt/voldata） sudo mount -o uquota,gquota,pquota /dev/sdb1 /mnt/voldata
- 为某个 Volume 目录单独设硬限制（比如限 5GB）
# 创建 project ID 并关联目录 sudo xfs_quota -x -c 'project -s myapp' /mnt/voldata sudo xfs_quota -x -c 'limit -p bhard=5g myapp' /mnt/voldata
- 启动容器时，将该目录以 bind mount 方式挂进容器
docker run -v /mnt/voldata/myapp:/var/lib/mysql:rw mysql:8.0
- 效果：容器内任何向
/var/lib/mysql的写操作，一旦累计超 5GB，立即报错Disk quota exceeded，进程阻塞，不会影响其他容器或宿主机磁盘。
用命名卷（named volume）+ ZFS 子卷配额（高阶但自动）
若宿主机已部署 ZFS 池，可让 Docker 自动为每个命名卷创建带配额的 ZFS 子卷。
- 启动 dockerd 时指定 ZFS 驱动和池名
dockerd --storage-driver=zfs --storage-opt zfs.poolname=myzpool
- 创建命名卷后，Docker 会自动生成子卷（如
myzpool/docker/abc123） - 手动设置该子卷配额即可生效
zfs set quota=8G myzpool/docker/abc123
- 后续所有对该 volume 的读写，都受 ZFS 配额实时管控，包括 rootfs + volume 数据总和。
临时数据走 tmpfs，避开磁盘写入风险
对日志、缓存、session 等非持久化数据，用内存文件系统天然限流：
- 启动时挂载 tmpfs 并指定大小
docker run --tmpfs /app/logs:rw,size=256m nginx
- 写满 256MB 后，继续写会触发
No space left on device（实际是内存/swap 耗尽） - 优势：零配置、即时生效、不依赖文件系统类型
- 注意：数据随容器退出消失；不可用于数据库或需要落盘的场景。
应用层兜底：监控 + 只读挂载 + 日志截断
技术手段总有盲区，加一层防御更稳妥：
- 对静态资源、证书、配置类 volume，强制只读挂载
docker run -v config-vol:/etc/app:ro app-image
- 全局限制容器日志大小（防日志撑爆）
在/etc/docker/daemon.json中配置：{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } } - 宿主机侧定期检查 volume 占用
du -sh /var/lib/docker/volumes/*/ | sort -hr | head -10
不复杂但容易忽略：Volume 的“限额”不在 Docker 命令里，而在你把它放在哪儿、怎么管它。
