Ubuntu Overlay有哪些限制条件

Ubuntu 中 Overlay 的限制条件

一 内核与 Docker 版本要求

• 内核版本：OverlayFS 在 Linux 内核 3.18 引入，生产推荐使用 4.0+ 的改进版（即 overlay2）。早期驱动 overlay 存在稳定性问题（如 “too many links” 等），不建议上生产。对于 RHEL/CentOS 要求 3.10.0-514+，而 Ubuntu/Debian 建议使用 4.0+ 内核。
• Docker 版本：使用 overlay2 需 Docker ≥ 17.06.02。
• 结论：在 Ubuntu 上，若内核低于 4.0 或 Docker 低于 17.06.02，不建议使用 overlay2。

二 底层文件系统与 d_type 要求

• 推荐底层文件系统：ext4、xfs、btrfs 均可；其中 xfs 更常用且性能与特性支持更好。
• d_type 必须开启：当底层为 XFS 时，需确认 ftype=1。检查命令：xfs_info /var/lib/docker | grep ftype；若为 ftype=0，需重新格式化：sudo mkfs.xfs -f -n ftype=1 /path/to/disk。
• 生产建议：将 /var/lib/docker 单独挂载到独立磁盘/分区，并在 /etc/fstab 中启用 pquota（如：UUID /var/lib/docker xfs defaults,pquota 0 0），以防单容器写爆影响主机与其他容器。

三 挂载与目录约束

• 只读挂载：不指定 upperdir 与 workdir 时，需至少 2 个 lowerdir，此时为只读挂载。
• 读写挂载：指定 upperdir 时必须同时指定 workdir，且 workdir 不能与 upperdir 为父子目录；workdir 在挂载后内容会被清空且对用户不可见。
• 多 lower 层：支持多 lower，最多约 500 层；但 mount 选项总长度受限于 单个内存页（约 4KB），层数过多或路径过长可能导致挂载失败。
• 文件系统兼容性：
  • upperdir 所在文件系统不能是 NFS、CIFS、GFS2、VFAT、OCFS2、FUSE、ISOFS、JFS 以及 另一个 overlayfs；
  • lowerdir 可位于 NFS/CIFS 等远程文件系统，也可为 overlayfs。
• 必要特性支持：upperdir/workdir 所在文件系统需支持 readdir 返回 dtype 与 xattr 扩展属性；否则可能出现 whiteout 暴露、无法创建 opaque 目录、以及 redirect_dir/index 特性不可用等问题。

四 功能特性与行为边界

• rename 限制：默认 redirect_dir=off、index=off 时，对 merged 目录或纯 lower 层目录的 rename/renameat 可能受限；开启相应特性可改善，但需内核支持与权衡。
• 删除语义：删除 upper 层对象直接生效；删除 lower 层对象通过 whiteout 隐藏；删除合并目录需按层规则处理。
• 设备与 inode 可见性：若 upper 与各 lower 来自同一底层文件系统，在触发 copyup 前后，通过 ls/stat 看到的 Device 与 inode 值保持不变；跨文件系统则可能发生变更。

五 资源限制与安全注意

• 资源限制边界：OverlayFS 本身不提供磁盘/内存/CPU 等配额，需借助 cgroups 或容器运行时参数实现（如 Docker 的 –cpus、–memory；或 cgroups 对进程/容器做内存/CPU/io 限制）。
• 权限与安全：挂载与操作通常需要 root 权限；若启用 AppArmor/SELinux，策略不当可能阻止挂载或访问，需按需调整策略。
• 日志与排障：关注 /var/log/syslog 中与 OverlayFS 相关的错误；变更 /etc/fstab 后需验证并重新挂载；重要变更前做好 数据备份。