docker从aufs切换到overlay2是因为后者内核原生支持（≥4.0）、无需额外模块、性能更优且官方已停止维护aufs；overlay2采用lowerdir/upperdir/merged/workdir四目录模型，支持细粒度配额，而aufs依赖whiteout和opaque机制但需手动加载内核模块。
联合文件系统（UnionFS）是 Docker 镜像分层和容器运行时文件隔离的底层支撑，AUFS 和 Overlay2 是两种典型实现，但它们在设计目标、内核支持、性能表现和维护状态上差异明显。理解它们的关键不是比较“谁更好”，而是看“为什么 Docker 从 AUFS 切换到了 Overlay2”。
AUFS：Docker 早期的多层拼接方案
AUFS（Advanced Multi-Layered Unification Filesystem）是 Docker 1.0 时代默认的存储驱动，核心思想是把多个只读目录（镜像层）和一个可写目录（容器层）“叠加”成一个统一视图。它的关键机制包括：
- Whiteout 文件：当删除某一层中的文件时，AUFS 不真正删掉它，而是在上层创建一个特殊标记（如 .wh.filename），让该文件在合并视图中“消失”，保证下层只读性不受破坏；
- Opaque 目录：如果某层中新建了一个与下层同名的目录，AUFS 会自动标记该目录为 opaque，阻止下层同名目录内容被透出；
- 分支管理简单但内核不原生支持：AUFS 从未被主线 Linux 内核接纳，需手动编译加载模块，在 CentOS/RHEL 等发行版上长期受限或不可用。
Overlay2：内核原生、轻量高效的现代替代
Overlay2 是 Linux 内核 4.0+ 原生支持的联合文件系统，Docker 自 17.06 起将其设为默认驱动。它用更简洁的三元结构替代 AUFS 的多分支模型：
- lowerdir：多个只读层（对应镜像各 layer），按顺序堆叠，最底层通常是 rootfs；
- upperdir：单个可写层（对应容器运行时修改），所有写操作都落在此处；
- merged：对外暴露的统一挂载点，用户看到的是 lowerdir + upperdir 的合并结果；
- workdir：辅助目录，用于 overlayfs 内部原子操作（如重命名），不直接参与数据存储。
相比 AUFS，Overlay2 在 inode 复用、并发性能、内存占用和错误恢复上均有优化，且无需额外内核模块，兼容性更强。
实际运行中你能观察到的区别
执行 docker inspect ，你会看到 GraphDriver 字段明确标出使用的是 overlay2，并列出 lowerdir、upperdir、merged 和 workdir 的具体路径。而 AUFS 模式下对应字段是 aufs，目录结构则表现为 diff/mnt/ layers 等不同命名风格。更重要的是：
- 用
docker info | grep "Storage Driver"可即时确认当前驱动； - CentOS/RHEL 8+、Ubuntu 18.04+ 默认启用 overlay2；Debian 旧版可能仍 fallback 到 aufs（若内核不支持 overlay）；
- overlay2 支持更细粒度的磁盘配额（如
overlay2.size=10GB），AUFS 无此能力。
选型建议：别纠结 AUFS，优先确保 Overlay2 正常工作
Docker 官方已停止对 AUFS 的维护，新环境不应主动启用。如果你遇到 AUFS 相关报错（比如 “aufs: required kernel modules not loaded”），说明宿主机内核缺失支持，正确做法是升级内核或切换至 overlay2 —— 这不是妥协，而是回归主流支持路径。只要你的系统满足以下条件，overlay2 就能稳定运行：
- Linux 内核 ≥ 4.0（推荐 ≥ 5.4）；
- 宿主机文件系统为 ext4 或 xfs；
- Docker 版本 ≥ 17.06（当前最新稳定版远高于此）。
不复杂但容易忽略。
