overlay2是Docker的一种存储驱动（storage driver），用于在Linux主机上管理容器镜像层和容器可写层的磁盘结构。它基于Linux内核的OverlayFS联合文件系统实现，自Docker 1.12起提供，取代了早期只能使用单个下层、易耗尽inode的overlay驱动。overlay2被Docker列为所有当前支持的Linux发行版上的首选经典存储驱动，无需额外配置即可启用。
定义
overlay2是Docker引擎在Linux上提供的一种存储驱动（storage driver），属于经典存储驱动（classic storage driver，也称graph driver）体系，负责把镜像层与容器可写层组织为宿主机文件系统上的目录结构[1][2]。它是一个用户态的驱动实现，底层依赖Linux内核的OverlayFS联合文件系统[3]。在Docker的命名习惯里，内核模块称为OverlayFS，而Docker自己的存储驱动称为overlay或overlay2[3]。
从Docker官方的定位看，overlay2是所有当前受支持的Linux发行版上的首选存储驱动，使用它不需要额外配置[4]。按Docker的说明，在经典存储驱动范围内，overlay2在稳定性上表现最好，并在各发行版之间具有最广泛的兼容性[2]。
原理
OverlayFS的工作方式是在同一台Linux主机上把多个目录叠加起来，对外呈现为一个单一目录。这些目录称为层（layer），叠加过程称为联合挂载（union mount）。下层目录叫lowerdir，上层目录叫upperdir，统一后的视图通过名为merged的目录暴露出来，merged实际上就是容器的挂载点[1]。创建容器时，overlay2把代表镜像顶层的目录与为容器新建立的目录组合起来：镜像的各个层构成只读的lowerdir，容器的新目录构成可写的upperdir[1]。
读操作按层自下而上查找：文件不在容器层时从镜像层读取；只存在于容器层时直接从容器层读取；两层都存在同名文件时，容器层（upperdir）的版本优先，并遮蔽镜像层中的同名文件[5]。写操作则涉及copy-up机制：容器首次写入一个已存在于镜像层的文件时，驱动先把整个文件复制到容器层，再在副本上写入[3]。由于OverlayFS工作在文件级别而非块级别，即使只改动大文件的一小部分，复制up也会复制整个文件[5]。
与只能使用单个下层OverlayFS层的overlay驱动不同，overlay2原生支持最多128个下层OverlayFS层，因此在与层相关的Docker命令（例如docker build和docker commit）上性能更好，占用的inode也更少[6]。在磁盘上，镜像与容器层位于/var/lib/docker/overlay2目录下，每个层目录中包含diff子目录存放该层内容，以及lower、merged、work等结构；其中l目录保存指向各层diff目录的短符号链接，用于避免挂载参数触及页面大小限制[7]。Docker官方提示不要直接改动/var/lib/docker/下的任何文件或目录，这些内容由Docker管理[1]。
用mount命令查看时，可以看到类型为overlay的挂载项，其参数中给出lowerdir、upperdir和workdir的路径[1]。挂载中的rw标志说明该overlay挂载是可读写的[1]。
发展历程
OverlayFS自Linux内核3.18起进入主线内核，被视为AUFS的继任者[7]。Docker早期的overlay驱动只支持一个下层OverlayFS层，多层镜像需要借助硬链接实现，并存在inode耗尽与commit性能方面的已知限制[8]。
Docker自1.12版本起提供overlay2存储驱动，在inode利用效率上明显优于overlay，但该驱动只兼容Linux内核4.0及以后的版本[7]。其优势来自Linux内核4.0新增的特性，用于避免过度的inode消耗[8]。overlay与overlay2两种驱动的磁盘存储格式互不兼容，在两者之间切换需要重新创建全部镜像内容[8]。
2017年12月发布的Docker 17.12起，新安装环境不再支持在不具备d_type支持的后端文件系统上运行overlay2，已有安装在升级到该版本时会输出警告[9]。此后overlay2长期作为经典驱动中的推荐选项；到Docker Engine 29.0及以后版本，全新安装默认改用containerd镜像存储（containerd image store）与snapshotter，而由旧版本升级而来的守护进程在手动启用前仍继续使用overlay2这类经典graph驱动[10]。
从Linux内核5.11起，即使在无根（rootless）模式下overlay2也能正常工作，fuse-overlayfs驱动不再必需[4]。
应用
overlay2主要用于Linux主机上的Docker引擎，承担拉取镜像、构建镜像与运行容器时的层存储职责[1]。Docker官方针对Ubuntu、Debian、CentOS、Fedora、SLES 15与RHEL等发行版，都把overlay2列为默认或推荐的经典存储驱动[2]。在支持的后端文件系统方面，overlay2可用于xfs（需ftype=1）、ext4、btrfs等，其中xfs后端必须启用d_type支持，可用xfs_info确认ftype是否为1，格式化时使用-n ftype=1参数[6]。
部署前提是Linux内核4.0或更高版本，或使用内核3.10.0-514及以上的RHEL与CentOS[6]。启用方式是在Docker守护进程配置文件daemon.json中写入storage-driver字段为overlay2，随后重启Docker服务，并用docker info查看Storage Driver与Backing filesystem两项以确认生效[6]。需要注意，更改存储驱动会使本地已有的容器和镜像无法访问，因此在变更前应先用docker save保存镜像或将其推送到镜像仓库，而且Docker Desktop不支持通过编辑守护进程配置文件来更换存储驱动[6]。
局限
overlay2在文件级别而非块级别工作，这使其对内存的使用更有效率，但在写入密集型工作负载下，容器的可写层可能变得相当大，因此Docker建议对这类负载改用Docker卷，而不是依赖向容器可写层写入数据[4]。相比之下，btrfs、zfs等块级别的存储驱动在写入密集型场景中表现更好[11]。
copy-up操作带来的开销也具有文件级特征：对同一文件的后续写入作用于副本，但首次写入大文件时仍需整体复制，这可能对容器写性能造成可察觉的影响[5]。此外，OverlayFS的rename(2)仅在源路径与目标路径都位于顶层时才允许操作目录，否则返回EXDEV错误，应用程序需要自行处理并回退到复制后删除的策略[12]。
环境方面，overlay2需要内核4.0以上（或特定RHEL、CentOS内核版本），在低于该要求的内核上只能使用不被推荐的overlay驱动[6]。后端文件系统若为xfs而未启用d_type，overlay2无法按预期工作，Docker自17.12起对这类配置不再支持[9]。驱动切换的成本同样值得注意：overlay2与overlay的磁盘格式互不兼容，更换存储驱动后原有镜像与容器将无法被新驱动使用[6]。在Docker Engine 29.0及以后的版本中，新安装默认使用containerd镜像存储，原有的overlay2镜像与容器在启用新后端后仍留在磁盘上但会被隐藏，切回overlay2时重新出现[10]。
参见
参考资料
- docker.com 上的网页 [引用日期2026-10-14]
- title: Select a storage driver [引用日期2026-10-14]
- OverlayFS 儲存驅動程式 [引用日期2026-10-14]
- 选择存储驱动程序 [引用日期2026-10-14]
- overlayfs-driver [引用日期2026-10-14]
- OverlayFS 存储驱动程序 [引用日期2026-10-14]
- Docker and OverlayFS in practice [引用日期2026-10-14]
- github.com 上的网页 [引用日期2026-10-14]
- deprecated [引用日期2026-10-14]
- containerd image store with Docker Engine [引用日期2026-10-14]
- 選擇儲存驅動程式 [引用日期2026-10-14]
- tencent.cn 上的网页 [引用日期2026-10-14]