containerd 的垃圾回收（Garbage Collection, GC）主要分为 镜像 GC 和 容器 GC 两种类型，分别用于清理未使用的镜像和容器资源。

一、containerd gc 分类

类型	作用	清理目标
Image GC	清理未被任何容器引用的镜像	无用的镜像层（layers）、旧版本镜像
Container GC	清理已删除但残留的容器	无用的容器层、容器元数据
Log GC（可选）	清理容器日志文件	容器日志目录（如 /var/log/containers）

二、gc 配置方式

containerd 的 GC 配置主要通过修改 config.toml 文件实现，配置文件默认路径为：

/etc/containerd/config.toml

2.1、 Image GC 配置

示例配置：

[plugins."io.containerd.gc.v1.scheduler"]
  deletion_threshold = 0.1       # 当未使用镜像占比 > 10% 时触发 GC
  mutation_threshold = 100       # 每 100 次镜像操作触发 GC
  schedule_delay = "5s"          # GC 延迟 5 秒启动

• deletion_threshold
  • 含义：
    定义触发垃圾回收的 资源删除比例阈值。当未使用的资源（如镜像层）占总资源的比例超过此值时，会自动触发 GC。
  • 默认值：0（表示禁用基于此阈值的触发）。
  • 典型场景：
    • 设置为 0.1（10%）时，当未使用资源占比超过 10%，containerd 会主动清理。
    • 适用于磁盘空间有限且希望自动清理的场景。
• mutation_threshold
  • 含义：
    定义触发垃圾回收的 资源变更次数阈值。当系统中资源（如容器、镜像）的创建、删除或更新操作次数达到此值时，触发 GC。
  • 默认值：100（表示每 100 次资源变更触发一次 GC）。
  • 典型场景：
    • 适用于高频率容器操作的环境（如持续集成/部署流水线），通过定期清理减少磁盘碎片。
• schedule_delay
  • 含义：
    定义 GC 任务启动前的 等待时间。设置为 “0s” 表示立即执行 GC，非零值可延迟启动。
  • 默认值：“0s”（立即执行）。
  • 典型场景：
    • 设置为 “5s” 可避免频繁触发 GC，减少系统抖动。

2.2、Container GC 配置

自动清理：通过 scheduler 参数控制容器 GC 的触发频率。
示例配置：

[plugins."io.containerd.gc.v1.scheduler"]
  pause_threshold = 0.02         # GC 暂停时间上限为 20ms
  startup_delay = "100ms"        # 启动后 100ms 首次 GC

• pause_threshold

  • 含义：
    定义 GC 执行时允许的最大 暂停时间（Pause Time）阈值。如果 GC 的暂停时间超过此值，containerd 可能调整 GC 策略以减少性能影响。
  • 默认值：0.02（20 毫秒）。
  • 典型场景：
    • 在高性能要求的环境中（如低延迟服务），限制 GC 暂停时间以避免影响业务。

• startup_delay

  • 含义：
    定义 containerd 启动后首次 GC 的 延迟时间。防止在启动时立即执行 GC 影响初始化性能。
  • 默认值：“100ms”（100 毫秒）。
  • 典型场景：
    • 适用于容器集群启动后快速恢复服务的场景，避免启动阶段因 GC 导致延迟。

2.3、 手动触发 GC

• Image GC：

sudo ctr -n default images gc

• Container GC：

sudo ctr -n default containers gc

• 全部 GC：

sudo ctr -n default gc

三、典型配置场景

3.1、 保留最新 N 个镜像版本

[plugins."io.containerd.grpc.v1.cri".image_puller]
  keep = 3  # 保留每个镜像的最近 3 个版本

3.2、 禁用自动 GC

如果希望完全禁用自动 GC，设置以下参数：

[plugins."io.containerd.gc.v1.scheduler"]
  deletion_threshold = 0
  mutation_threshold = 0

3.3、 调整 GC 触发频率

• 高频清理（适合开发环境）：

[plugins."io.containerd.gc.v1.scheduler"]
  mutation_threshold = 50       # 每 50 次资源变更触发 GC
  schedule_delay = "0s"         # 立即执行

• 低频清理（适合生产环境）：

[plugins."io.containerd.gc.v1.scheduler"]
  mutation_threshold = 500      # 每 500 次资源变更触发 GC
  schedule_delay = "30s"        # 延迟 30 秒执行

四、GC 的工作原理

• 资源扫描：
  containerd 定期扫描所有镜像和容器，识别未被引用的资源（如无容器使用的镜像层）。
• 标记与清理：
  • 标记：确定哪些资源可以安全删除。
  • 清理：删除孤立资源（如镜像层、容器层）及残留数据。
• 触发条件：
  根据配置参数（如 deletion_threshold、mutation_threshold）自动触发。
  支持手动触发（通过 ctr gc 命令）。

五、containerd gc 意义

在 containerd 中，垃圾回收（Garbage Collection, GC） 的核心意义是 自动清理不再使用的容器和镜像资源，释放磁盘空间并优化系统性能。以下是其关键作用和意义：

5.1、 释放磁盘空间

• 问题场景：
  容器运行后，即使被删除，其关联的镜像层（image layers）、容器层（container layers）仍可能残留。随着时间推移，这些未使用的资源会占用大量磁盘空间，导致存储不足。
• GC 解决方案：
  • 自动识别并删除 孤立的镜像层（未被任何容器引用的镜像部分）。
  • 清理 已删除容器的残留数据（如容器层、日志文件等）。
  • 通过定期扫描，防止磁盘空间被无用数据填满。

5.2、减少磁盘碎片和文件系统压力

• 问题场景：
  频繁创建和删除容器会导致文件系统产生大量小文件（如容器层），降低磁盘性能。
• GC 解决方案：
  • 合并或删除碎片化的文件，保持文件系统的高效读写能力。
  • 避免因碎片化导致的性能下降（如 I/O 延迟增加）。

5.3、提升系统稳定性和可靠性

• 问题场景：
  磁盘空间耗尽可能导致容器无法启动、服务崩溃，甚至影响整个集群的稳定性。
• GC 解决方案：
  • 通过自动清理，确保关键服务（如 Kubernetes 的 kubelet）有足够的磁盘空间运行。
  • 避免因手动清理遗漏导致的资源泄露问题。

5.4、 降低运维成本

• 问题场景：
  运维人员需要手动检查和清理无用容器/镜像，耗时且容易出错。
• GC 解决方案：
  • 自动化的资源回收机制减少人工干预。
  • 通过配置阈值（如 deletion_threshold、mutation_threshold），实现按需清理。

5.5、与容器编排系统的协同

• Kubernetes 场景：
  • Kubernetes 依赖 containerd 的 GC 机制来管理节点上的容器资源。
  • 若 GC 未启用或配置不当，可能导致节点磁盘空间耗尽，触发 NoDiskSpace 错误，影响 Pod 调度。

参考文档

1、https://blog.csdn.net/gitblog_01078/article/details/152405231