Containerd作为容器运行时已是趋势，但由于开始还是起于docker, k8s也是默认支持docker的，所以是有个转向的过程的，从docker向Container，这其中必定会有基于基于原来不一致的认知需要更新。
Containerd简介
ctr是containerd的一个客户端工具, 由containerd.io包提供。
containerd 相比于docker , 多了namespace概念, 每个image和container 都会在各自的namespace下可见, 目前k8s会使用k8s.io 作为命名空间
为什么crictl和ctr
- 更换Containerd后，以往我们常用的docker命令也不再使用，取而代之的分别是crictl和ctr两个命令客户端。crictl是遵循CRI接口规范的一个命令行工具，通常用它来检查和管理kubelet节点上的容器运行时和镜像,由kubernetes社区提供的cri-tools，Crictl容器运行命令行界面（CLI）是一个有用的系统和应用故障排除工具。
- 使用Docker作为Kubernetes的容器运行时，系统管理员有时登陆到Kubernetes node去执行Docker命令来搜集系统和应用的信息。例如，使用docker ps和docker inspect检查应用进程的状态，使用docker images列出node上的镜像，以及使用docker info验证容器运行配置等。
- Crictl的适用范围是有限的故障排除工具，并非是Docker或者kubectl的替代品。Docker的CLI提供了一系列丰富的命令，使其成为非常有用的开发工具。但是它不是最适合作为Kubernetes nodes的故障排除工具。一些Docker的命令，如docker network和docker build并不适用于Kubernetes；甚至有些命令会破坏Kubernetes系统，如docker rename。Crictl提供刚刚适合的命令来为生产环境中的node故障排除。
- Crictl提供对Kubernetes更友好的容器界面。Docker CLI缺少核心的Kubernetes概念，如pod和namespace，因此它不能提供清晰的容器和pods的信息。比如，docker ps显示有些混乱，长的容器名字，Pause容器和应用容器显示在一起。
- ctr: 是containerd本身的 CLI (https://github.com/containerd/containerd/tree/master/cmd/ctr)
- crictl: 是Kubernetes社区定义的专门 CLI 工具 (https://github.com/kubernetes-sigs/cri-tools)
- 这里需注意的是，由于Containerd也有namespaces的概念，对于上层编排系统的支持，主要区分了3个命名空间分别是k8s.io、moby和default，以上我们用crictl操作的均在k8s.io命名空间完成如查看镜像列表就需要加上-n参数
命令对照
接下来就是crictl的的常见命令，其中能完全替代docker命令的参照下列表格
| 操作 | crictl | docker |
|---|---|---|
| 查看运行容器 | crictl ps | docker ps |
| 查看镜像 | crictl images | docker images |
| 查看容器日志 | crictl logs | docker logs |
| 登陆容器控制台 | crictl exec | docker exec |
| pull镜像 | crictl pull | docker pull |
| 容器启动/停止 | crictl start/stop | docker start/stop |
| 容器资源情况 | crictl stats | docker stats |
可以看到crictl对容器生命周期的管理基本已经覆盖，不过在crictl我们不 能完成操作也比较多，比如对镜像的管理就不属于它的管理范围。这部分还得依靠ctr来实现，操作方式同样可以参照下表
| 操作 | ctr | docker |
|---|---|---|
| 查看镜像 | ctr images ls | docker images |
| 镜像导入/导出 | ctr images import/exporter | docker load/save |
| 镜像拉取/推送 | ctr images pull/push | docker pull/push |
| 镜像tag | ctr images tag | docker tag |
敲下命令
1 | [root ~]# whereis crictl |
性能比较
性能优化主要包括Pod启动延迟和进程资源的占用，启停时间/list/stat等，稳定情况下的105个Pod，containerd 1.1比Docker 18.03 dockershim消耗更少的CPU和内存。Node中Pod数量的不同会使结果也不同，之所以选择105个Pod是因为这是每个Node的最大Pod数量。下图的数据显示，和Docker 18.03 dockershim比较，containerd 1.1降低了30.80%的Kubelet的CPU使用率，降低了68.13%的容器运行CPU使用率，降低了11.30%Kubelet resident set size（RSS）内存使用率，降低了12.78%容器运行RSS内存使用率。