解决nerdctl中k8s.io命名空间下镜像重复显示问题

在容器运行时管理工具nerdctl的实际使用过程中，我们发现当操作k8s.io命名空间下的镜像时，会出现镜像重复显示的问题。这个问题源于containerd内部CRI接口与原生接口在镜像存储机制上的差异，给用户带来了诸多不便。

问题现象分析

当用户通过不同方式操作镜像时，会出现以下异常现象：

1. 通过crictl查看镜像时显示正常，但通过nerdctl查看会出现多个重复条目
2. 删除镜像时需要多次操作才能完全清理
3. 尝试通过镜像ID删除时会报错"multiple IDs found"

根本原因在于CRI接口和containerd原生接口采用了不同的镜像存储策略。CRI端会对镜像进行去重处理，而containerd原生接口直接从数据库读取，导致在k8s.io命名空间下出现重复的镜像条目。

技术背景解析

containerd的架构设计中，CRI插件作为Kubernetes容器运行时接口的实现层，与containerd核心之间存在镜像管理上的差异：

1. CRI插件在拉取或加载镜像时会向meta.db重复写入数据
2. CRI端的imageStore实现了去重逻辑
3. ctr工具直接读取数据库原始数据

这种设计差异导致了镜像在k8s.io命名空间下的重复存储问题，进而影响了用户体验。

解决方案设计

我们提出的解决方案是在镜像列表查询时对相同digest的镜像进行去重处理：

1. 利用nerdctl已有的--all参数作为控制开关
2. 默认情况下(--all=false)只显示精简后的镜像列表
3. 显式指定--all时才会显示完整的镜像信息

实现技术上采用digest作为去重依据，通过维护digest映射表来过滤重复条目。这种方案既解决了重复显示问题，又保留了查看完整信息的能力。

实际效果对比

修改前后的效果对比明显：

修改前：

REPOSITORY    TAG       IMAGE ID        CREATED           PLATFORM       SIZE
centos        7         be65f488b776    38分钟前         linux/amd64    211.5MB
centos        <none>    be65f488b776    39分钟前         linux/amd64    211.5MB
<none>        <none>    be65f488b776    39分钟前         linux/amd64    211.5MB

修改后：

REPOSITORY    TAG    IMAGE ID        CREATED          PLATFORM       SIZE
centos        7      be65f488b776    1小时前         linux/amd64    211.5MB

技术价值

这一改进带来了多方面的提升：

1. 显著改善了用户体验，避免了冗余信息的干扰
2. 简化了镜像管理操作，特别是删除流程
3. 保持了功能的完整性，通过参数控制查看详细信息的灵活性
4. 为后续可能的存储机制优化奠定了基础

这个问题的解决展示了容器运行时领域深层次的设计考量，也体现了开源社区通过协作不断完善工具的典型过程。