1. 课程导论：为什么需要垃圾回收与磁盘释放？

在 Kubernetes 集群中，容器运行时（Container Runtime）是承载 Pod 生命周期的核心组件。以 containerd 为例，它负责拉取镜像、创建容器、管理容器文件系统。然而，随着业务的持续部署、版本迭代与故障恢复，节点磁盘空间会迅速被以下三类数据吞噬：

• 悬空镜像层（Dangling Layers）：镜像更新后，旧层不再被任何镜像或容器引用，但仍残留在磁盘上。
• 已退出容器的读写层（Read-Write Layers）：容器退出后，其上层可写层（snapshotter 挂载点）未被及时清理。
• 临时挂载与快照元数据（Snapshots & Metadata）：containerd 的 snapshotter 维护大量中间快照，长期积累导致元数据膨胀。

若不引入有效的垃圾回收（Garbage Collection, GC）策略，磁盘容量将逐步逼近上限，最终引发 Eviction（驱逐）、Pod 创建失败 甚至 节点 NotReady 等生产事故。

1.1 容器镜像与层文件系统带来的磁盘压力

容器镜像采用 分层联合文件系统（OverlayFS / AUFS / devicemapper） 设计。每个镜像由多个只读层（Layer）叠加而成，容器启动时在最上层添加一个可写层。这种设计虽然实现了存储复用与快速分发，但也带来了独特的磁盘管理挑战：

1.2 磁盘压力引发的连锁故障

当节点磁盘使用率超过阈值（通常为 85%~95%），kubelet 会触发 节点压力驱逐（Node Pressure Eviction）。以下是典型的故障演进路径：

1. 镜像拉取失败：磁盘空间不足，containerd 无法写入新层，Pod 启动卡在 ImagePullBackOff。
2. 容器 OOM 与写延迟：文件系统元数据操作变慢，容器日志写入阻塞，引发健康检查失败。
3. kubelet 驱逐 Pod：kubelet 根据 evictionHard 配置驱逐低优先级 Pod，导致服务抖动。
4. 节点 NotReady：磁盘 I/O 完全阻塞，kubelet 心跳上报超时，节点从集群中脱离。

1.3 垃圾回收的核心目标

containerd 的垃圾回收机制围绕以下三个目标设计：

• 回收悬空镜像层：删除未被任何镜像或容器引用的层，释放只读层空间。
• 清理已退出容器的可写层：根据容器状态与保留策略，删除不再需要的快照。
• 压缩元数据存储：定期对 snapshotter 的元数据库进行碎片整理与空间回收。

下图展示了 containerd 垃圾回收在节点存储体系中的位置与作用范围：

1.4 课程内容预览

本课程将深入 containerd 的垃圾回收实现，涵盖以下核心模块：