rootfs只读挂载与overlayfs协同使用：前者保障镜像安全与不可变性，后者提供轻量可写层；生产中普遍采用overlay2+只读lowerdir+readonlyrootfilesystem强制策略。
在容器化生产环境中，rootfs 只读挂载和overlayfs不是互斥方案，而是常协同使用：overlayfs 提供可写层能力，而只读挂载是保障基础镜像安全与一致性的关键约束。真正需要对比的，是“是否启用 overlayfs”以及“如何管理只读语义”，而非二者选一。
只读 rootfs 的核心价值：隔离性与不可变性
容器运行时（如 containerd、Docker）默认将镜像层（lowerdir）以只读方式挂载到容器 rootfs，这是强制行为，不依赖 overlayfs——即使使用 aufs、btrfs 或 native 挂载，镜像层也必须只读。这一设计确保：
- 多个容器共享同一镜像层时，不会因误写导致数据污染或校验失效
- 镜像内容与构建时完全一致，满足合规审计（如 SOC2、等保）对系统不可变性的要求
- 配合签名验证（cosign、notary），可确认运行时 rootfs 未被篡改
实践中，可通过 mount | grep ' / ' | grep ro 验证容器 init 进程根路径是否为 ro；若发现 rw，通常是应用层显式 remount 或特权容器绕过限制，属于配置风险。
overlayfs 的角色：提供安全、轻量的可写抽象
overlayfs 本身不改变只读语义，它通过 upperdir（可写层）+ lowerdir（只读层）+ workdir（内部元数据） 构建出一个逻辑可写的文件系统视图。在生产落地中，它的优势体现在：
- 分层写入隔离：每个容器独占 upperdir，进程写 /tmp 或 /var/log 不影响其他容器，也不污染镜像
- 无拷贝启动：无需像 copy-on-write 全量复制镜像，秒级启动，内存与磁盘开销可控
- 与 OCI 标准深度集成：runc、containerd 原生支持 overlay2，无需额外适配存储驱动
注意：overlayfs 的 upperdir 若落在宿主机非持久卷（如 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs），需确保其所在文件系统支持 d_type（如 xfs、ext4 with dir_index），否则会退化为性能较差的 fallback 模式。
生产环境常见组合与避坑点
真实部署中，90% 以上 Kubernetes 集群采用 overlay2 + 只读 lowerdir + 容器内 rootfs 默认 ro 组合。但需主动管控以下细节：
-
容器内 rootfs 显式设为 ro：在 Pod spec 中设置
securityContext.readOnlyRootFilesystem: true，强制挂载为只读，防止应用层意外写入 /etc、/usr 等目录 - 临时写入走 emptyDir 或 tmpfs：/tmp、/run 应通过 volumeMount 挂载 tmpfs，避免写入 upperdir 导致层膨胀或 inode 耗尽
- 禁止 privileged + mount namespace 滥用：特权容器可能 remount rootfs 为 rw，应通过 PSP（v1.25-）或 PodSecurityPolicy 替代方案（如 Pod Security Admission）限制
-
镜像构建阶段就剔除运行时写入需求：例如用
RUN adduser --disabled-password --gecos '' appuser替代启动时创建用户，减少容器初始化期对 /etc/passwd 的修改
替代方案适用场景（非 overlayfs）
某些受限环境会选用其他机制，但通常有明确 trade-off：
- chroot + bind mount：轻量级容器（如 systemd-nspawn）可用，但缺乏镜像分层、资源隔离弱，不适合多租户 K8s
- initramfs-style rootfs：嵌入式或 Serverless 场景（如 AWS Firecracker）用只读 initramfs 加 overlay 上层，启动极快但调试困难
- 全盘只读 + 写入重定向（FUSE）：如 gocryptfs 或 overlayfs 自定义封装，用于加密或审计日志，增加运维复杂度，一般不作为默认选择
除非有强定制需求（如硬件级只读介质、合规强制 FIPS 模式），否则 overlay2 是当前 Linux 容器生态最成熟、最易落地的方案。
