Docker、ctr 与 crictl：容器生态工具对比

发布于 作者: 12 次浏览

背景与演进
技术演进背景
Docker与Kubernetes的分道扬镳
早期Kubernetes依赖Docker座位容器运行时，但是Docker的封闭生态与Kubernetes的开源理念逐渐产生冲突，2016年，Kubernetes退出CRI（Container Runtime Interface）标准表容器运行时接口，解耦对Docker的依赖
关键事件：2022年Kubernetes1.24版本正式移除Dockershim，转而通过CRI对接containerd、CRI-O等轻量级运行时
现状：Docker扔可间接支持Kubernetes（通过cri-cokerd适配层），但生产环境推荐直接使用containerd。
企业混合场景的挑战
混合需求：
1、Kubernetes集群管理：需要兼容CRI的运行时（containerd）
2、镜像构建与存储：依赖Docker的Harbor仓库和Dockerfile构建能力
工具的定位与分析
定位与场景
在容器生态中docker、ctr、crictl是常用的三个命令行工具，但是他们的定位和使用场景差异显著，以下是他们之间的对比：

区别与详解

1. 功能范围

docker：功能最全面，支持镜像的构建、网络、存储管理
ctr：仅提供containerd的基础操作（镜像/容器），无网络/存储功能
crictl：专门为kubernetes crl 设计，支持pod操作，但是无法构建镜像

  1. 与kubernetes关系
    docker：早期kubernetes依赖docker，但是kubernetes1.24移除对docker的直接支持，转为通过CRI对接容器运行时（如containerd）
    ctr：直接操作containerd（kubernetes默认容器运行时之一），但是不兼容CRI接口，可能导致与kubernetes元数据不一致
    crictl：专为CRI设计，完全兼容kubernetes容器运行时，能直接查看和管理kubelet创建的容器/pod
  2. 生产环境深度实践
    生产环境建议：

禁止直接使用docker/ctr命令操作Kubernetes容器，可能波坏kubelet对资源的预期状态。
优先使用crictl确保操作结果与kubectl命令逻辑一致。
命名空间隔离：

containerd默认使用default命名空间，而Kubernetes使用k8s.io。
查看Kubernetes容器：ctr -n kubernetes list
语法对比：

总结
因为生产环境的多样性和复杂性，导致Docker和Kubernetes的共存，也衍生了一些命令行工具，在日常运维工作中我们要根据命令行工具的定位去合理的使用。

​Docker：仍是开发者首选工具，适合镜像构建和单机环境。
ctr：定位为 containerd 的“手术刀”，用于底层调试，需谨慎使用。
crictl：Kubernetes 运维核心工具，完美兼容集群管理逻辑。