优先使用overlay2驱动，需满足Linux内核≥4.0、文件系统支持d_type（如xfs或启用ftype=1的ext4）、Docker≥18.06；它性能优、内存占用低、开箱即用，是当前生产环境默认推荐方案。
选对存储驱动，核心就一条：优先用 overlay2，只要你的系统满足条件——Linux 内核 4.0 及以上、文件系统支持 d_type（如 xfs、ext4）、Docker 版本较新（18.06+）。它性能好、内存占用低、开箱即用，是当前绝大多数生产环境的默认和推荐选择。
看系统基础是否匹配
不是所有驱动都能在任意系统上跑。得先确认底层支持：
-
overlay2：要求内核 ≥4.0，且挂载点文件系统开启 d_type（xfs 默认支持，ext4 需挂载时加
ftype=1）；CentOS/RHEL 7.4+、Ubuntu 16.04+、Debian 9+ 均原生支持 -
aufs：仅限旧版 Ubuntu/Debian，需额外安装
linux-image-extra包；新内核已逐步移除，不建议新部署 -
devicemapper：CentOS/RHEL 7 早期默认，但必须配置为
direct-lvm模式才可用于生产；loop-lvm 性能极差，仅限测试 -
btrfs/zfs：需手动准备对应文件系统（如
mkfs.btrfs），并加载内核模块；适合需要快照、压缩、配额等高级功能的场景，但内存开销大、调试复杂
看工作负载特点
驱动不是越“高级”越好，要贴合实际读写模式：
- 容器以大量只读操作为主（如 Web 服务、API 网关）→ overlay2 共享页缓存，效率最高
- 容器频繁修改小文件、高并发写入可写层（如构建缓存、日志暂存）→ overlay2 仍适用，但要注意避免在容器层写入大量数据；更稳妥的做法是用 volume 显式挂载，把写操作引到外部存储
- 需要秒级快照、克隆、压缩或跨主机一致性→ 可评估 zfs 或 btrfs，但务必在同构环境中充分压测
- 运行在老旧物理机或嵌入式设备（内核老、资源紧）→ 若 overlay2 不可用，aufs 或 vfs 是退而求其次的选择，但性能与稳定性需实测验证
看运维与兼容性要求
生产环境还要考虑长期维护成本：
- 默认配置最省心：overlay2 无需额外格式化或 LVM 配置，改完
/etc/docker/daemon.json重启即可生效 - 切换驱动会清空原有镜像和容器（因数据路径不同），必须提前
docker save导出关键镜像，再docker load恢复 - Docker EE 商业支持仅覆盖特定驱动组合，若用 btrfs/zfs，需查对应版本的产品兼容性矩阵
- SELinux 启用时，overlay2 在 RHEL/CentOS 上默认兼容；若强行用 aufs 或 devicemapper，可能触发安全策略拦截
快速确认与验证方法
别猜，用命令直接看：
- 查当前驱动：
docker info | grep -i "storage driver" - 查底层文件系统：
docker info | grep -i "backing filesystem" - 确认 d_type 支持：
findmnt -o fstype,source,target,OPTIONS -T /var/lib/docker，输出中含dtype即支持 - 改配置示例（
/etc/docker/daemon.json）：
注意：override_kernel_check 仅在明确知道风险时临时启用，不建议长期开启。
