使用ctr向离线Kubernetes导入镜像时部分镜像丢失的排查求助

排查步骤 #

• 查看ctr image import的实时输出：执行导入命令时不要忽略输出，重点看是否有镜像删除、覆盖或磁盘空间不足的提示，这类信息直接指向问题原因。
• 检查containerd日志：查看/var/log/containerd.log，搜索delete或gc关键词，确认是否是自动垃圾回收（GC）清理了已导入的镜像。
• 验证磁盘空间：执行df -h /var/lib/containerd，确认存储目录是否已满——磁盘空间不足时，containerd会触发GC清理旧镜像来腾出空间。
• 单独测试镜像包：拿那些导入后导致其他镜像消失的tar包，单独执行ctr image import xxx.tar，导入后立即用ctr image list检查现有镜像是否减少，定位是特定包的问题还是普遍问题。
• 检查镜像标识冲突：用docker inspect <image>查看本地打包的镜像，确认是否存在相同tag但不同digest的镜像，导入时可能会覆盖或触发异常清理。

解决方法 #

• 合并镜像包批量导入：不要单个镜像单独打包，改用docker save img1 img2 img3 ... > all-images.tar将所有需要的镜像打包到一个文件中，再一次性执行ctr image import all-images.tar --platform linux/amd64。批量导入能减少GC触发的概率，避免频繁导入导致的镜像清理。
• 临时禁用containerd GC：修改/etc/containerd/config.toml，在disabled_plugins中添加"io.containerd.gc.v1.scheduler"，然后执行systemctl restart containerd。完成所有镜像导入后，再移除该配置并重启containerd恢复GC。
• 调整GC策略：如果是GC自动清理了镜像，可修改containerd配置中的GC参数：

  [plugins."io.containerd.gc.v1.scheduler"]
    pause_threshold = 0.02
    mutation_threshold = 100
    schedule_delay = "0s"
    startup_delay = "10s"
  

  调高mutation_threshold（默认100，即镜像变更100次触发GC），延长schedule_delay，减少GC触发频率。
• 确保磁盘空间充足：清理/var/lib/containerd下的冗余文件（如未被引用的镜像层），或扩容存储磁盘，避免因空间不足触发强制清理。
• 逐个导入并校验：每次导入一个镜像后，立即执行ctr image list确认所有已导入镜像都存在，再进行下一个导入，这样能快速定位到导致问题的特定镜像包，排查该包是否损坏或存在异常依赖。

内容的提问来源于stack exchange，提问作者Astin Gengo