Dragonfly2 项目中 GC 机制误清理运行中镜像任务数据的分析与解决方案

问题背景

在 Dragonfly2 项目中，当触发垃圾回收（GC）机制时，系统会清理已完成任务的关联数据。但在实际使用中发现，GC 机制可能会错误地清理掉当前正在运行的镜像所关联的任务数据，导致容器运行时出现异常。

问题现象

用户在使用 kind 搭建本地集群时，将 dfget.yaml 中的 /var/lib/dragonfly 数据目录大小限制为 50MB。当启动一个自定义 BusyBox pod 后，观察到该目录中存在任务数据。随后用户拉取多个镜像，导致目录大小超过限制触发 GC。GC 执行后，整个目录被清空，包括正在运行的 BusyBox 镜像的任务数据。

技术分析

1. GC 机制原理：

   • Dragonfly2 的 GC 机制会定期检查存储目录的使用情况
   • 当存储使用超过阈值时，会按照一定策略清理任务数据
   • 默认情况下，系统会清理标记为已完成（Done）的任务数据

2. 问题根源：

   • 当前实现中，GC 只根据任务状态（Done）判断是否清理
   • 对于已完成拉取但仍在运行的镜像，其任务数据也被标记为 Done
   • 这导致 GC 会误清理仍在使用的镜像数据

3. 影响范围：

   • 使用 Dragonfly2 作为镜像分发系统的 Kubernetes 集群
   • 特别是设置了较小存储限制的环境
   • 可能导致正在运行的容器因基础镜像数据丢失而异常

解决方案

项目团队在 v0.1.116 版本中修复了此问题，主要改进包括：

1. 任务状态细化：

   • 区分"已完成拉取"和"正在使用中"两种状态
   • 新增任务使用中的标记机制

2. GC 策略优化：

   • GC 执行时会检查任务是否仍被容器使用
   • 仅清理真正不再使用的任务数据
   • 保留正在运行的容器所需的镜像数据

3. 存储管理增强：

   • 更精确的存储使用计算
   • 优先清理最久未使用的已完成任务数据

最佳实践建议

1. 版本升级：

   • 建议用户升级到 v0.1.116 或更高版本
   • 新版本彻底解决了运行中镜像数据被误清理的问题

2. 配置建议：

   • 根据实际负载合理设置存储限制
   • 监控存储使用情况，避免频繁触发 GC

3. 运维监控：

   • 定期检查 GC 日志
   • 监控容器运行状态，及时发现异常

总结

Dragonfly2 项目通过优化 GC 机制，解决了运行中镜像数据被误清理的问题。这一改进显著提升了系统的稳定性和可靠性，特别是在资源受限的环境中。用户升级到修复版本后，可以避免因此问题导致的容器异常情况。

对于分布式镜像分发系统而言，精细化的资源管理和任务生命周期控制至关重要。Dragonfly2 团队的这一修复体现了对系统健壮性的持续追求，也为其他类似系统提供了有价值的参考。