overlayfs构建只读业务容器镜像的核心是将lowerdir设为只读、禁用upperdir意外写入，并通过运行时策略固化只读语义；需确保镜像层物理只读、启用readonlyrootfilesystem、显式挂载临时存储、构建阶段精简镜像并签名校验。
直接用 OverlayFS 构建只读业务容器镜像，核心不是“让 OverlayFS 变只读”，而是**把 lowerdir 设为只读、禁用 upperdir 的意外写入、并通过运行时策略固化只读语义**。OverlayFS 本身是联合挂载机制，它的“只读性”由各层权限和容器配置共同决定，不是文件系统开关。
确保镜像层（lowerdir）物理只读
容器镜像的每一层在宿主机上实际对应一个目录（如 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/xxx/fs）。这些目录必须挂载为只读：
- 验证方式：
findmnt -t overlay | grep 'ro,'或进入容器后执行mount | grep ' / ' | grep ro - 若发现
rw，说明镜像层被意外 remount，常见于特权容器、错误的 init 脚本或未设readOnlyRootFilesystem - 生产中应配合
containerd的snapshotter配置，禁止对 snapshot 目录的写权限（如chown root:root -R /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs并chmod 755）
禁用容器可写层的非必要写入
OverlayFS 的 upperdir 天然可写，但业务容器不该依赖它存持久数据。需主动约束：
宝塔Linux面板11.8.1
下载
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
- 在 Kubernetes Pod spec 中强制设置：
securityContext.readOnlyRootFilesystem: true，这会让容器 runtime 将整个merged视图挂为只读（即使 upperdir 存在，也无法写入/etc、/usr等路径） - 临时写入需求（如
/tmp、/run）必须显式挂载emptyDir或tmpfs，例如：volumeMounts: [{name: tmp, mountPath: /tmp, medium: Memory}] - 避免应用向
/var/log直接写日志——改用 stdout/stderr，由容器运行时统一采集
构建阶段就固化只读意图
只读不是运行时补丁，而应从镜像构建源头控制：
- Dockerfile 中避免
RUN chmod +w /app、RUN echo > /etc/config等会污染镜像层的操作；配置类文件应通过ARG+ENV或挂载方式注入 - 使用多阶段构建，最终 stage 只 COPY 编译产物，不带构建工具、包管理器、shell 历史等无关内容
- 镜像签名与校验不可少：用
cosign sign对镜像签名，运行时通过containerd的image verification插件校验，确保 lowerdir 内容自构建起未被篡改
验证与监控只读是否生效
上线前必须实测，不能仅靠配置：
- 进容器执行：
touch /test-ro && echo "FAIL" || echo "OK"—— 应输出 OK - 检查
/proc/mounts中 rootfs 是否含ro标志，且无remount,rw记录 - 监控指标：采集
container_fs_usage_bytes{read_only="false"}（Prometheus + cAdvisor），异常上涨说明有绕过只读的写行为
