Containerd OverlayFS 快照目录架构剖析

在 Kubernetes 集群中，当 Containerd 配置为使用 OverlayFS 作为底层存储驱动时，/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs 便成为管理容器与镜像文件系统快照的核心枢纽。理解该目录的内部构造是进行磁盘空间排查与清理的前提。

核心组件与功能映射

路径/组件	功能解析
snapshots/	快照数据根目录。其内部的每个数字命名的子目录（如 102/、455/）均代表一个独立的文件系统快照层。
snapshots/<id>/fs	快照的物理数据载体。若为镜像层（Committed 状态），此处存储只读文件；若为容器运行层（Active 状态），则记录容器运行时产生的所有增量写入数据。
snapshots/<id>/work	OverlayFS 机制专属的工作区。主要用于保障联合文件系统挂载时文件操作（如重命名、删除）的原子性。严禁人工干预或修改此目录。
metadata.db	基于 BoltDB 构建的元数据仓库，持久化记录所有快照的拓扑结构（如父子层级依赖）及时间戳等属性。

底层运行与联合挂载机制

Containerd 的存储管理高度依赖快照（Snapshot）抽象。每一个镜像层在拉取后都会生成一个状态为 committed 的只读快照。当 Pod 调度并启动容器时，系统会基于该镜像的最顶层快照，派生出一个状态为 active 的可读写快照层，容器内部的所有文件变更均落盘于此。

在容器进程启动前夕，OverlayFS 驱动会介入执行联合挂载操作：将多个底层的只读镜像层（lowerdir）与顶层唯一的容器可读写层（upperdir）融合，呈现为一个统一的 merged 视图供容器内部进程访问。

磁盘空间排查与容器追踪

当节点出现磁盘容量告警时，需精准定位导致空间膨胀的快照层，并将其映射至具体的业务容器。

1. 锁定高占用快照层

通过系统级磁盘分析工具，可以快速筛选出体积异常的快照目录：

# 统计各快照层大小并提取前15个最大目录
sudo du -sh /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/* | sort -rh | head -n 15

此外，也可借助 CRI 工具直接审视容器级别的资源消耗：

# 获取所有运行中容器的资源消耗概览
crictl stats --all

# 针对特定容器ID进行资源监控
crictl stats -a <target_container_id>

2. 建立快照与容器的映射关系

假设通过上述步骤发现 ID 为 893 的快照目录占用极高，可通过检索系统挂载表来追踪其关联的容器任务路径：

# 通过 /proc/mounts 检索特定快照ID的挂载详情
cat /proc/mounts | grep "snapshots/893/fs"

输出结果中通常会暴露包含容器 ID 的运行时路径（多位于 /run/containerd/io.containerd.runtime.v2.task/ 命名空间下）。提取该容器 ID 后，即可查询其所属的 Pod 与业务模块：

# 利用精确匹配过滤容器信息
crictl ps --id <partial_container_id>

# 获取容器的详细元数据（推荐使用 jq 解析）
crictl inspect <full_container_id> | jq '.info'

规范化空间清理策略

在处理 Containerd 磁盘膨胀时，绝对禁止使用 rm -rf 直接物理删除 snapshots 目录下的任何文件，这将直接破坏 metadata.db 中的依赖树，导致运行时崩溃或容器无法启动。正确的回收流程应通过 CRI 接口触发垃圾回收（GC）：

# 批量清理悬空镜像以释放快照空间
crictl rmi --prune

# 使用 ctr 移除特定容器及关联镜像（需指定 k8s.io 命名空间）
ctr -n k8s.io containers rm <target_container_id>
ctr -n k8s.io images rm <target_image_ref>

当废弃的容器与镜像被安全移除后，Containerd 内置的 GC 机制会自动识别并清理那些失去引用的孤立快照层，从而安全地释放底层磁盘空间。

架构对比：Containerd 与 Docker 的存储抽象

尽管 Docker 的 overlay2 驱动与 Containerd 的 io.containerd.snapshotter.v1.overlayfs 在内核层面均依赖 OverlayFS 技术，但两者的架构设计存在显著差异。Containerd 将存储管理高度抽象为独立的 Snapshotter 插件，实现了存储逻辑与容器运行时（Runtime）的彻底解耦。这种设计不仅提升了快照操作的灵活性，也为支持更多样化的存储后端（如 Stargz、Nydus 等延迟加载技术）奠定了架构基础。