在最新k8s的版本中，containerdruntime已经不在使用docker,而是使用containerd了。​containerd是什么？containerd的自我介绍中说它是一个开放、可靠的容器运行时，实际上它包含了单机运行一个容器运行时的功能。 containerd为了支持多种OCI Runtime实现，内部使用containerd-shim，shim英文翻译过来是"垫片"的意思。

官网见：​ ​containerd docs – Getting started with containerd​​

Kubernetes, Docker和Containerd

​kubernetes的出现是为了解决容器编排的问题，在早期为了支持多个容器引擎，是在Kubernetes内部对多个容器引擎做兼容，例如kubelet启动一个docker-manager的进程直接调用docker的api进行容器的创建。

后来k8s为了隔离各个容器引擎之间的差异，在docker分出containerd后，k8s也搞出了自己的容器运行时接口(CRI)，CRI的出现是为了统一k8s与不同容器引擎之间交互的接口，与OCI的容器运行时规范不同，CRI更加适合k8s，不仅包含对容器的管理，还引入了k8s中Pod的概念及对Pod生命周期的管理。 k8s开始把containerd接入CRI标准。kubelet通过CRI接口调用docker-shim，进一步调用docker api。此时在每个k8s节点上kubelet大致按下图流程启动容器:

​为了更好的将containerd接入到CRI标准中，k8s又搞出了cri-containerd​项目，cri-containerd是一个守护进程用来实现kubelet和containerd之间的交互，此时k8s节点上kubelet大致按下图流程启动容器:

在上图中cri-containerd和containerd还是两个独立的进程，他们之间通过gRPC通信，后来在Containerd 1.1时，将cri-containerd改成了Containerd的CRI插件，CRI插件位于containerd内部，这让k8s启动Pod时的通信更加高效，此时k8s节点上kubelet大致按下图流程启动容器:

kubelet启动容器的发展历程总结

早期: kubelet --> docker-manager --> docker
中期: kubelet -CRI-> docker-shim --> docker --> containerd --> runc
中期: kubelet -CRI-> cri-containerd --> containerd --> runc
当前: kubelet -CRI-> containerd(CRI plugin) --> runc
当前: kubelet -CRI-> cri-o --> runc
1.
2.
3.
4.
5.

ctr cli与crictl联系与区别

使用containerd的命令行工具ctr来启动一个容器。启动流程如下：

从containerd作为k8s容器运行，流程如下：

crt是containerd的一个客户端工具，定位和作用与docker一样，命令使用也大概一致。

crictl 是 CRI 兼容的容器运行时命令行接口，可以使用它来检查和调试 k8s 节点上的容器运行时和应用程序。

ctr -v 输出的是 containerd 的版本，crictl -v 输出的是当前 k8s 的版本，从结果显而易见你可以认为 crictl 是用于 k8s 的。

一般来说你某个主机安装了 k8s 后，命令行才会有 crictl 命令。而 ctr 是跟 k8s 无关的，你主机安装了 containerd 服务后就可以操作 ctr 命令。

命令对比

更多的命令操作，可以直接在命令行后输入查看帮助。

需要注意的是，containerd 相比于docker , 多了namespace概念, 每个image和container 都会在各自的namespace下可见, 目前k8s会使用k8s.io 作为命名空间

crictl 使用命名空间 k8s.io

crictl image list = ctr -n=k8s.io image list