Ubuntu Overlay配置中有哪些常见误区

Ubuntu Overlay配置的常见误区与规避

一 概念混淆导致的配置走偏

• 将容器运行时的 OverlayFS 存储驱动（如 overlay2） 与容器网络 Overlay 网络混为一谈，前者是镜像/容器层的联合文件系统，后者是跨主机通信的网络方案，配置项与排错路径完全不同。
• 将 OverlayFS 与 Overlayroot混用：前者用于目录/容器的联合挂载，后者用于把根文件系统做成只读+可写的覆盖层，启用后直接在运行的系统上修改“根”往往无效。
• 以为 OverlayFS 是通用万能层，忽略其不支持的特性（如跨不同文件系统的某些操作、对已有挂载命名空间的随意嵌套等），导致“能挂但行为异常”。

二 挂载参数与目录准备的常见错误

• 未正确设置或顺序错误的挂载选项：OverlayFS 需要明确 lowerdir、upperdir、workdir，且 workdir 必须是空目录，三者任一缺失或路径错误都会导致挂载失败。
• 将 upperdir 或 workdir 放在 lowerdir 之下，造成自引用和循环依赖，挂载报错或行为不可预期。
• 忘记创建挂载点目录或权限不足，导致“目录不存在/权限被拒绝”。
• 使用不支持的文件系统作为 lowerdir（如部分网络文件系统/特殊挂载选项），引发挂载或运行时异常。
• 排查建议：核对挂载命令与目录结构，查看系统日志（如 /var/log/syslog、dmesg）中关于 overlay 的错误信息。

三 存储驱动与 Docker 配置的坑

• 在 /etc/docker/daemon.json 中写入不兼容选项（如 overlay2.override_kernel_check）导致 Docker 启动失败，应删除或注释后再启动。
• 内核或环境不满足 overlay2 要求时强行启用，常见表现是容器启动失败或镜像层无法创建；此时应检查内核支持、存储驱动与日志，必要时临时改用 vfs（仅用于排障，性能很差）。
• 修改 Docker 存储驱动后未重启服务或未校验生效状态，导致“改了等于没改”。
• 排查建议：用 docker info | grep Storage 确认当前存储驱动，变更后重启 Docker 并复核日志。

四 只读根与 Overlayroot 的易错点

• 启用 Overlayroot 后直接在运行系统上“改 /etc、装包”等，这些修改只会落在临时覆盖层，重启即丢失；需要改底层只读根时应在引导时通过内核参数 overlayroot=disabled 进入可写模式。
• 忽略 swap 与 recurse 等关键选项：如 overlayroot=“tmpfs:swap=1” 才能在 tmpfs 覆盖下启用交换；recurse=0 可避免把某些挂载点也纳入覆盖（例如独立的 /data 分区）。
• 期望“部分目录可写、其余只读”却未正确配置，导致关键路径被覆盖或未覆盖，影响日志、数据持久化等。
• 排查建议：用 mount 查看挂载关系，确认 /media/root-ro（只读下层）与 /media/root-rw（可写上层）是否符合预期。

五 权限、磁盘与日志的忽视

• 目录或镜像层的 权限/属主 配置不当，导致容器或进程访问被拒；应统一规划 UID/GID 与目录权限。
• 磁盘空间不足（尤其是 upperdir 所在分区）引发写入失败或容器层创建失败，却常被误判为“配置错误”。
• 底层文件系统存在错误未修复就上 Overlay，易出现不稳定或挂载异常；应先做 fsck 校验。
• 只看表面报错不查日志，错过关键线索；应结合 /var/log/syslog、dmesg、journalctl 精确定位。
• 排查建议：用 df -h 检查空间，用 fsck 修复文件系统，用日志命令检索 “overlay” 关键字。