1. 为什么需要关注Overlay2存储驱动
Docker容器默认使用Overlay2作为存储驱动，这个设计虽然高效，但有个潜在问题：每个容器默认会占用宿主机全部的磁盘空间。想象一下，如果你在100G硬盘的服务器上跑10个容器，理论上它们可以共同吃掉1000G的空间——这显然会引发灾难性后果。
我第一次遇到这个问题是在生产环境。凌晨三点收到磁盘告警，某台服务器空间爆满导致服务崩溃。排查后发现是个Java容器疯狂写日志，不到24小时就吃光了50G空间。从那以后，我养成了给容器设置磁盘配额的习惯。
Overlay2的工作原理类似"洋葱模型"：最底层是只读的镜像层（image layer），上面叠加可写的容器层（container layer）。所有修改都发生在容器层，但默认情况下这个层的大小不受限制。这就是为什么我们需要主动设置配额。
2. 配置XFS文件系统支持配额
2.1 准备支持配额的存储设备
要让Overlay2的size限制生效，必须使用XFS文件系统并开启pquota特性。这里有个坑：很多云主机的根分区默认不支持配额，需要单独挂载数据盘。
# 查看可用磁盘设备 fdisk -l | grep sd # 创建XFS文件系统（注意这会清空磁盘数据！） mkfs.xfs -f /dev/sdb # 创建挂载点并启用配额 mkdir -p /data mount -o uquota,prjquota /dev/sdb /data实测中发现，有些Linux发行版需要额外安装xfsprogs工具包。如果遇到mkfs.xfs命令不存在，用yum install xfsprogs或apt-get install xfsprogs解决。
2.2 永久挂载配置
临时挂载重启会失效，需要写入/etc/fstab。先获取磁盘UUID：
blkid /dev/sdb然后在/etc/fstab添加（注意pquota是关键）：
UUID=你的磁盘UUID /data xfs rw,pquota 0 0执行mount -a测试配置是否正确。可以通过cat /proc/mounts | grep sdb确认pquota是否生效。我遇到过因为漏写pquota参数导致docker配额无效的情况，排查了半天才发现问题。
3. Docker存储配置实战
3.1 迁移Docker数据目录
默认/var/lib/docker通常位于根分区，我们需要将其迁移到支持配额的/data分区：
mkdir -p /data/docker systemctl stop docker mv /var/lib/docker /data/ ln -s /data/docker /var/lib/docker systemctl start docker注意顺序不能错：先停服务→迁移数据→创建软链接→重启服务。有次我在服务运行状态下直接mv操作，导致容器全部崩溃，不得不手动恢复数据。
3.2 配置容器大小限制
有两种配置方式，根据Docker版本选择：
方法一：systemd服务配置（推荐）
vim /usr/lib/systemd/system/docker.service在ExecStart行追加：
--storage-opt overlay2.size=40G方法二：daemon.json配置
{ "storage-driver": "overlay2", "storage-opts": ["overlay2.size=40G"] }配置后需要完全重启Docker：
systemctl daemon-reload systemctl restart docker验证配置是否生效：
ps -ef | grep dockerd # 应该能看到--storage-opt overlay2.size=40G参数4. 空间监控与回收策略
4.1 实时监控容器磁盘使用
虽然设置了配额，但还需要监控实际使用量。推荐组合使用这些命令：
# 查看容器磁盘限额 docker inspect -f '{{ .HostConfig.StorageOpt }}' 容器ID # 查看实际使用情况（需要在容器内执行） df -h /我习惯用Prometheus+Grafana搭建监控看板，通过cAdvisor采集容器磁盘指标。当使用量超过80%时触发告警，比被动发现磁盘爆满要靠谱得多。
4.2 空间回收四步法
当发现空间不足时，按这个顺序清理：
- 清理停止的容器
docker container prune- 删除悬空镜像
docker image prune- 清理构建缓存
docker builder prune- 日志文件清理
# 清空单个容器日志 truncate -s 0 $(docker inspect 容器ID --format='{{.LogPath}}') # 批量清理所有容器日志 find /var/lib/docker/containers -name "*-json.log" -exec truncate -s 0 {} \;曾经有次清理为公司节省了200G空间——某个测试环境的Nginx容器日志居然积累了三个月，单个日志文件就80多G。
5. 高级配置与优化技巧
5.1 预防日志爆仓
在daemon.json中限制日志大小是治本之策：
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }这样每个容器最多保留30MB日志（3个10MB文件）。配置后需要重建容器才能生效。
5.2 分层存储优化
Overlay2的性能与镜像层数密切相关。建议通过多阶段构建减少镜像层：
FROM golang:1.18 as builder WORKDIR /app COPY . . RUN go build -o myapp FROM alpine:latest COPY --from=builder /app/myapp / CMD ["/myapp"]这个例子将构建环境和运行环境分离，最终镜像只包含必要的运行文件，体积能缩小90%以上。
5.3 定时维护任务
设置cronjob定期执行清理：
# 每天凌晨3点清理 0 3 * * * docker system prune -af --filter "until=72h"--filter "until=72h"参数保留最近3天的资源，避免误删正在使用的镜像。
复杂度降到O(n log n))
