自 Docker Engine 29.0 起，容器镜像存储的后端架构发生了显著变化：全新安装的 Docker 环境将默认采用 containerd 镜像存储（containerd image store）作为镜像和容器数据的存储后端，而不再使用经典的 Docker graph driver（默认为 overlay2）。这一变更意味着镜像数据的物理布局从传统的 /var/lib/docker 目录迁移至 containerd 管理的 /var/lib/containerd 路径体系。对于已经在生产环境中运行旧版 Docker 的用户，官方提供了明确的 opt-in 迁移路径，用户需要主动启用才能将镜像存储切换至 containerd 后端。
存储后端架构差异与新安装默认行为
Docker 传统存储架构使用 graph driver 模式，镜像层和容器文件系统通过 Docker daemon 自身维护的存储驱动（如 overlay2、aufs、devicemapper）管理，数据最终落地于 /var/lib/docker/overlay2 等目录。containerd 镜像存储则是将镜像元数据和层数据完全交由 containerd 组件管理，形成独立的存储平面。在 Docker Engine 29 的全新安装场景下，系统初始化时 daemon.json 配置中默认不指定 graphdriver，而是由 containerd 的快照管理器（snapshotter）接管镜像层解压和容器根文件系统分发。
这种架构变化带来的直接差异体现在两个层面：第一，镜像不再以 Docker 传统的层目录结构存储，而是采用 containerd 的 content store 格式，镜像层被统一管理为不可变的 content blobs；第二，容器运行时的根文件系统挂载点从 Docker 维护的 overlay 挂载变为 containerd 通过 snapshotter 提供的视图层。官方数据显示，containerd 镜像存储在并发拉取和并发启动场景下相比传统 graph driver 有显著性能优势，尤其在大规模镜像分发环境中。
对于全新安装的系统，无需执行任何额外配置即可自动获得 containerd 镜像存储。Docker Engine 29 安装程序在首次启动 daemon 时检测到 data-root 目录下不存在历史存储结构，即自动初始化 containerd 的镜像存储平面。安装完成后，使用 docker info 命令可以在 "Storage Driver" 一栏看到 "containerd" 或 "stargz" 等快照管理器名称，而非传统的 "overlay2"。
升级场景下的迁移路径与兼容性处理
从 Docker Engine 28 或更早版本升级至 29 的系统不会自动迁移至 containerd 镜像存储。官方明确指出，迁移是 opt-in 行为，用户必须在确认业务兼容性后手动启用。这一设计决策的核心考量在于：containerd 镜像存储虽已成熟，但某些高级特性（如特定的数据卷插件、自定义存储驱动）可能与新后端存在行为差异。生产环境升级前建议在隔离环境中完成完整的功能验证。
手动启用 containerd 镜像存储需要修改 Docker daemon 配置文件 /etc/docker/daemon.json，添加或确认以下关键配置项：
{
"storage-driver": "containerd",
"containerd-snapshotter": "stargz"
}
其中 "storage-driver" 指定为 containerd，而 "containerd-snapshotter" 可选 stargz（支持延迟拉取）或 native（同步拉取）。修改配置后需执行 sudo systemctl restart docker 重启 daemon。值得注意的是，首次启用时 Docker 会扫描现有镜像并将其导入至 containerd 镜像存储，此过程可能耗时数分钟取决于已有镜像数量和大小。迁移完成后，旧版 /var/lib/docker 目录中的镜像数据不会被自动删除，建议在确认新存储正常工作后再行清理以释放磁盘空间。
对于需要回滚至传统存储的场景，官方建议的策略是：在执行迁移前完整备份 /var/lib/docker 目录或创建 LVM / 文件系统快照。回滚时只需将 daemon.json 中的 "storage-driver" 改回 "overlay2" 并重启 daemon 即可恢复至传统存储。需要特别注意的是，containerd 镜像存储中新增的镜像在切换回传统存储后将不可见，因为两种后端的数据平面完全独立。若业务对数据连续性要求极高，建议在测试环境验证完整的工作负载后再在生产环境执行切换。
现有环境的兼容性评估要点
在决定是否为现有环境启用 containerd 镜像存储前，需要评估以下几个兼容性维度。首先，检查是否使用了依赖 Docker graph driver 的第三方工具或插件，例如某些日志收集 agent、存储卷驱动（如 RexRay）、或自定义的镜像审计工具。containerd 镜像存储暴露的镜像元数据通过 containerd 的 API 访问，部分工具可能需要适配或更新至支持 containerd 的版本。
其次，评估镜像推送和拉取的工作流是否涉及私有_registry 认证的特殊配置。在 containerd 镜像存储下，Registry 认证信息仍由 Docker daemon 管理，但镜像层数据的传输路径发生了变化。如果企业使用自签发证书或需要配置特殊的 TLS 选项，需要确认 containerd 端的配置是否同步生效。Docker 官方文档建议将证书放置在 /etc/docker/certs.d/ 目录下的配置同时被 containerd 端读取。
第三，监控和告警体系需要相应调整。传统存储模式下，磁盘使用量监控通常指向 /var/lib/docker 目录；切换至 containerd 后，监控目标应更新为 /var/lib/containerd。此外，containerd 镜像存储引入了 content store 的 garbage collection 机制，管理员可以通过 docker system events 观察清理行为，或使用 crictl info 查看 content store 的使用统计。建议在启用新存储后的一周内密切监控磁盘使用趋势，以确认 GC 策略符合预期。
迁移验证与回滚操作清单
完整的迁移实施建议遵循以下检查清单。迁移前阶段应完成：使用 docker images --format '{{.Repository}}:{{.Tag}} {{.Size}}' 导出当前镜像列表；创建 /var/lib/docker 的完整备份或文件系统快照；准备回滚脚本，将 daemon.json 恢复至 overlay2 配置并包含重启命令。
迁移中阶段应执行：在测试机或非核心业务节点先执行一次完整迁移，观察镜像拉取、容器启动、日志收集的完整链路；验证 docker images 输出与迁移前列表一致；使用 docker run --rm alpine echo test 确认容器文件系统挂载正常。迁移后阶段应确认：监控告警已指向新的存储路径；关键业务容器的启动时间未出现显著退化；使用 docker info | grep -A5 "Storage Driver" 确认驱动已切换至 containerd。
若迁移后出现预期外的行为，回滚操作应在业务低峰期执行。回滚步骤为：停止 Docker daemon；修改 daemon.json 将 storage-driver 恢复为 overlay2；删除或重命名 /var/lib/containerd 目录（可选，保留以避免后续再次迁移时的重新初始化）；启动 Docker daemon 并验证镜像和容器可访问。需要注意的是，回滚后 containerd 镜像存储中创建的新镜像将不可用，业务可能需要重新拉取镜像。
Docker Engine 29 引入的默认 containerd 镜像存储代表了容器运行时存储架构的演进方向。对于新部署的环境，直接使用新存储后端可以获得更好的性能和现代化特性；对于已有环境，建议在充分测试的基础上逐步推进迁移，并始终保留回滚能力以应对不可预见的问题。
资料来源
- Docker 官方文档：containerd image store with Docker Engine（https://docs.docker.com/engine/storage/containerd/）
- Docker Engine v29 Release Notes（https://www.docker.com/blog/docker-engine-version-29/）