docker-cli nerdctl ctr crictl容器命令比较
一、docker-cli、nerdctl 和 ctr 以及 crictl 介绍
docker, nerdctl 和 ctr 和 crictl 都是用于容器管理的命令行工具，但它们在设计目的、使用场景和技术栈上有所不同。下面分别对这四个工具进行介绍，并指出它们之间的主要差异。
1.1、Docker CLI
Docker CLI（Command Line Interface） 是 Docker 项目提供的官方命令行工具，广泛应用于基于 Docker 技术的容器管理和操作。用户可以通过它来构建、运行、管理和分发 Docker 容器和镜像。Docker CLI 支持与 Docker daemon 通信，执行如创建容器、执行命令、管理网络、数据卷等操作。它的易用性和全面的功能集使其成为容器技术中最流行的工具之一。
- 特点：用户友好、功能全面，支持广泛的容器管理操作。
- 适用场景：通用的容器开发、部署和管理任务，特别是与 Docker 引擎集成的环境。
1.2、Nerdctl
nerdctl 是一个与 Docker CLI 风格和语义兼容的命令行工具，专为 Containerd 设计。它由 Rancher Labs 开发，旨在为那些熟悉 Docker CLI 使用方式的用户提供一种更加轻量级且与 Containerd 深度集成的管理工具。Nerdctl 使得从 Docker 迁移到 Containerd 成为一个平滑的过程，因为它支持大部分 Docker CLI 的命令和选项，同时利用了 Containerd 的高效和灵活性。
主要特点：
-
Docker CLI 兼容性：nerdctl 的命令和选项设计与 Docker CLI 高度相似，这意味着 Docker 用户可以几乎无缝地切换到使用 nerdctl，无需重新学习大量新命令。
-
轻量级：相比于 Docker，nerdctl 直接与 Containerd 交互，避免了 Docker daemon 的额外资源消耗，适合追求更高性能和更小资源占用的场景。
-
Kubernetes 集成友好：由于 Containerd 是 Kubernetes 默认的容器运行时之一，nerdctl 自然非常适合在 Kubernetes 环境下使用，尤其是对于那些希望保持 CLI 统一性和简化管理流程的用户。
-
增强功能：除了基本的 Docker CLI 兼容功能外，nerdctl 还提供了一些额外的特性和命令，以更好地利用 Containerd 的特性，比如对多平台镜像的支持等。
1.3、Ctr
Ctr 是 Containerd 项目提供的一个轻量级的命令行工具，旨在替代 Docker CLI 在与 Containerd 交互时的角色。Containerd 是一个容器运行时，提供了容器生命周期管理的基础能力，被设计为低层级的系统组件，常作为 Kubernetes 等更高级容器编排系统的底层技术。Ctr 提供了直接管理容器、镜像、沙箱等底层功能，相比 Docker CLI 更加面向底层和系统集成。
- 特点：轻量、底层、面向系统集成，特别适合与 Containerd 配合使用。
- 适用场景：在使用 Containerd 作为容器运行时的环境中，进行更底层的容器管理操作，或在 Kubernetes 等平台中作为后台服务的一部分。
1.4、Crictl
Crictl (CRI Control) 是 Kubernetes 项目的容器运行时接口 (CRI, Container Runtime Interface) 的一个命令行客户端工具。CRI 是 Kubernetes 为了支持多种容器运行时而引入的标准接口，允许 Kubernetes 与不同的容器运行时（如 Docker、Containerd、CRI-O 等）通信。Crictl 专门设计用来与实现了 CRI 接口的容器运行时进行交互，进行容器和 Pod 的管理。
- 特点：专为 Kubernetes 设计，支持多种遵循 CRI 的容器运行时。
- 适用场景：在 Kubernetes 集群中进行容器和 Pod 的调试、监控等操作，特别是在需要跨不同容器运行时标准化管理操作时。
差异总结
- 目标用户和场景：
- Docker CLI 面向更广泛的用户群体，特别是那些直接与 Docker 引擎交互的开发者和运维人员；
- Ctr 更适用于与 Containerd 集成的底层操作和系统级管理；
- Crictl 则聚焦于 Kubernetes 环境下的容器管理，提供跨容器运行时的一致性操作。
- 功能和深度：
- Docker CLI 功能最为全面，覆盖了从构建到部署的整个容器生命周期；
- Ctr 和 Crictl 更专注于底层容器操作，其中 Crictl 通过 CRI 标准化了与容器运行时的交互。
- 集成与生态系统：
- Docker CLI 与 Docker 生态紧密集成；
- Ctr 与 Containerd（及背后的 CNCF 生态）相辅相成；
- Crictl 是 Kubernetes 生态中的一部分，特别适合云原生应用的管理。
二、命令对比
| 命令描述 | docker | nerdctl | ctr | crictl |
|---|---|---|---|---|
| 显示正在运行的容器 | docker ps | nerdctl ps | ctr task ls ctr containers ls | crictl ps |
| 显示所有的容器（包含退出等） | docker ps -a | nerdctl ps -a | - | crictl ps -a |
| 仅显示容器id | docker ps -q | nerdctl ps -q | ctr containers ls -q | crictl ps -q |
| 启动容器 | docker run | nerdctl run | ctr run | crictl run |
| 进入容器 | docker exec | nerdctl exec | - | crictl exec |
| 停止容器 | docker stop | nerdctl stop | ctr pause | - |
| 删除容器 | docker rm | nerdctl rm | ctr task rm | - |
| 强制删除 | docker rm -f | nerdctl rm -f | ctr task rm -f | - |
| 删除退出状态的所有容器 | docker container prune | nerdctl container prune | - | - |
| copy 文件 | docker cp | nerdctl cp | - | - |
| 查看日志 | docker logs | nerdctl logs | - | crictl logs |
| 查看容器/镜像元信息 | docker inspect | nerdctl inspect | - | crictl inspect/inspecti |
| 查看版本 | docker version | nerdctl version | ctr version | crictl version |
| 查看系统级信息 | docker info | nerdctl info | - | crictl info |
| 下载镜像 | docker pull | nerdctl pull | ctr images pull | crictl pull |
| 删除镜像 | docker rmi | nerdctl rmi | ctr image rm | crictl rmi |
| 查看镜像列表 | docker images | nerdctl images | ctr image ls | crictl images |
| 镜像tag | docker tag | nerdctl tag | ctr image tag | - |
| 镜像仓库登录 | docker login | nerdctl login | - | - |
| 镜像仓库登出 | docker logout | nerdctl logout | - | - |
| 包方式导入镜像 | docker load -idocker import | nerdctl load -inerdctl import | -/ctr image import | - |
| 包方式导出镜像 | dcoker save -odocker export | nerdctl save -o | ctr image export | - |
| 镜像label | docker label | - | ctr image label | - |
| 镜像push | docker push | nerdctl push | ctr image push | - |
| 镜像构建 | docker build | nerdctl build | - | - |
三、具体差异
3.1、docker ps -q & nerdctl ps -q & ctr containers ls -q & crictl ps -q 显示的是所有容器的id，还是仅是正在运行容器的ID
docker
$ docker ps | wc -l
3 # 包含首行，实际为2$ docker ps -a | wc -l
8$ docker ps -q | wc -l
2docker ps -q 显示的是正在运行的
nerdctl
$ nerdctl ps | wc -l
29$ nerdctl ps -a | wc -l
94$ nerdctl ps -q | wc -l
28crictl
$ crictl ps | wc -l
15$ crictl ps -a | wc -l
33$ crictl ps -q | wc -l
14
综上：
docker、nerdctl 和crictl 均是显示正在运行的容器id,ctr 没有-a 命令
3.2 指定运行时 sock
docker, nerdctl, ctr, 和 crictl 这四个命令行工具在与容器运行时（如 Containerd）交互时，对于指定运行时socket（通常为containerd.sock）的方式存在一些差异，这主要是由于它们的设计目的、使用场景以及与底层容器运行时的集成方式不同所致。下面分别说明它们的差异：
Docker
- 默认配置：Docker 有自己的守护进程（daemon），默认情况下，Docker 客户端会连接到本地的 Docker 守护进程，而不是直接与 Containerd 交互。Docker 守护进程自身负责与容器运行时（可能是 Docker 自带的或其他，如Containerd）的通信。
- Socket配置：Docker 守护进程的socket位置通常是固定的（例如，在Linux上通常是
/var/run/docker.sock），用户通常不需要直接指定socket地址。
Nerdctl
- 设计目的：Nerdctl 是为了提供一个与 Docker CLI 风格和功能相匹配的工具，专为 Containerd 设计。它直接与 Containerd 交互，模仿 Docker CLI 的使用体验。
- Socket配置：默认情况下，nerdctl 会查找 Containerd 的默认 socket 位置（通常是
/run/containerd/containerd.sock）。如果修改了containerd.sock路径，可以通过环境变量或如下命令行参数指定不同的socket，例如：
nerdctl --address /path/to/containerd.sock ps
Ctr
-
定位：Ctr 是 Containerd 自带的低级别命令行工具，主要用于调试和直接管理 Containerd。它提供了更底层的控制能力。
-
Socket配置：Ctr 也默认查找
/run/containerd/containerd.sock，但可以通过-a或--address参数显式指定socket位置，例如：ctr -a /path/to/containerd.sock containers ls
Crictl
- Kubernetes集成：Crictl 是为 Kubernetes 与 CRI 兼容的容器运行时（包括 Containerd）设计的。它通过 CRI 接口与运行时通信，主要用于 Kubernetes 环境下的容器管理。
- Socket配置：Crictl 通常通过环境变量或配置文件（如
/etc/crictl.yaml）来指定运行时socket，而不是每次执行命令时都指定。例如，在配置文件中，你可以设置runtime-endpoint来指定 Containerd 的socket地址。$ cat /etc/crictl.yaml runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock
3.3 run 命令参数差异
| 参数 | docker run | nerdctl run | ctr run | crictl run |
|---|---|---|---|---|
| -i | ✅ | ✅ | ✅ | ❌ |
| -t | ✅ | ✅ | ✅ | ❌ |
| -d | ✅ | ✅ | ✅ | ❌ |
| -it | ✅ | ✅ | ❌ | ❌ |
| -itd | ✅ | ❌ | ❌ | ❌ |
| –env | ✅ | ✅ | ✅ | ❌ |
| –network | ✅ | ✅ | ❌ | ❌ |
| –name | ✅ | ✅ | ❌ | ❌ |
3.4 覆盖或指定 entrypoint 差异
docker run 允许你通过 --entrypoint 参数覆盖镜像中定义的 ENTRYPOINT。如果你提供了这个参数，指定的命令将会替代镜像中的 ENTRYPOINT，并且可以结合命令参数。例如，docker run --entrypoint "/bin/bash" myimage 将使用 /bin/bash 作为容器的入口点。
nerdctl run 设计上力求与 Docker CLI 兼容，因此它也支持 --entrypoint 参数来覆盖镜像的默认入口点。用法与 docker run 相似，允许你自定义容器启动时执行的第一个命令或脚本。
ctr run 的命令行参数较为基础，它没有直接提供一个等同于 --entrypoint 的参数来轻松覆盖镜像的 ENTRYPOINT。通常，你需要通过直接指定命令来间接改变入口点行为，这意味着你输入的命令会替代镜像的默认 ENTRYPOINT 和 CMD。
crictl 命令行工具并不直接提供 run 命令来启动独立容器，因为它主要针对 Kubernetes 环境下的容器管理。在 Kubernetes 中，容器的启动配置是通过 Pod 的定义（YAML 文件）来完成的，其中包括 command 和 args 字段，它们分别对应于镜像的 ENTRYPOINT 和 CMD。这意味着，你不是通过 crictl 直接指定 entrypoint，而是通过修改 Pod 配置文件来达到目的。
3.5 都各自支持哪些类型的shell？
支持哪些shell 不由命令行决定，由镜像决定
/etc/shells展示了系统支持哪些shell
$ cat /etc/shells
/bin/bash
/bin/csh
/bin/dash
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
如下方式可以查看机器默认的shell
$ echo $SHELL
/bin/bash$ cat /etc/passwd
username:x:UID:GID:User Info:/home/username:/bin/bash
3.6 ctr 和crictl 如何实现docker login 功能
ctr 和 crictl 并没有像docker login这样直接管理registry权限的命令；ctr 用containerd的配置文件 /etc/containerd/config.toml 来存储账号密码，示例如下：
[plugins."io.containerd.grpc.v1.cri".registry.configs."https://index.docker.io/v1/"]auth = "YOUR_AUTH_TOKEN"username = "YOUR_USERNAME"
crictl 通常与 Kubernetes 集群一起使用，而 Kubernetes 集群的镜像拉取认证信息是通过集群内的服务账户（ServiceAccount）或 ImagePullSecrets 来管理的，而不是直接通过 crictl 登录。但如果你需要在没有 Kubernetes 环境下使用 crictl 与私有 registry 交互，可能需要通过相应 registry 的认证令牌或证书来配置,这与上面一致了。
另外。还可以通过创建secret来实现使用docker的配置文件~/.docker/config.json,如下：
https://kkgithub.com/containerd/containerd/blob/main/vendor/k8s.io/api/core/v1/types.go
// SecretTypeDockerConfigJson contains a dockercfg file that follows the same format rules as ~/.docker/config.json
//
// Required fields:
// - Secret.Data[".dockerconfigjson"] - a serialized ~/.docker/config.json file
SecretTypeDockerConfigJson SecretType = "kubernetes.io/dockerconfigjson"
参考文档
1、https://kkgithub.com/containerd/containerd/blob/main/cmd/ctr/main.go
2、https://kkgithub.com/docker/cli/blob/master/README.md
3、https://kkgithub.com/containerd/nerdctl
4、https://blog.csdn.net/zfw_666666/article/details/136898245
5、https://www.cnblogs.com/liugp/p/16633732.html
6、https://kkgithub.com/containerd/containerd/blob/main/docs/cri/crictl.md
7、https://kkgithub.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md