docker，containerd，runc，docker-shim

• docker，是一个客户端工具，用来把用户的请求发送给 docker daemon(dockerd)。
• dockerd, docker daemon，一般也会被称为 docker engine。dockerd 启动时会启动 containerd 子进程。
• Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性，几乎囊括了单机运行一个容器运行时所需要的一切：执行，分发，监控，网络，构建，日志等。主要作用是：
  • 管理容器的生命周期
  • 拉取/推送容器镜像
  • 存储管理(管理镜像及容器数据的存储)
  • 调用 runC 运行容器(与 runC 等容器运行时交互)
  • 管理容器网络接口及网络
• ctr 是 containerd 的 cli。
• 为了能够支持多种 OCI Runtime，containerd 内部使用 containerd-shim，每启动一个容器都会创建一个新的 containerd-shim 进程，指定容器 ID，Bundle 目录，运行时的二进制（比如 runc）。
• RunC 是一个轻量级的工具，用来运行容器的，我们可以不用通过 docker 引擎，直接运行容器。事实上，runC 是标准化的产物，它根据 OCI 标准来创建和运行容器。

docker 启动一个标准化容器需要经历这样的流程：

在容器标准的大战中，docker公司围绕docker swarm推出了CNM，Google 等xxxx k8s 推出了CNI，目前来看，k8s已经奠定了在 PaaS 事实的地位。

CRI 是一套通过 protocol buffers 定义的 API，如下图：

kubelet 实现了 client 端，CRI shim 实现 server 端。只要实现CRI对应的接口，就能接入 k8s 作为 Container Runtime。

1. k8s 1.5 中自己实现了 docker CRI shim，此时启动容器的流程如下：

1.从 containerd 1.0 开始，为了能够减少一层调用的开销（废掉docker，也就是把上边的docker cri shim和docker踢掉），containerd 开发了一个新的 daemon，叫做 CRI-Containerd，直接与 containerd 通信，从而取代了 dockershim：

2.但是这仍然多了一个独立的 daemon，从 containerd 1.1 开始，社区选择在 containerd 中直接内建 CRI plugin，通过方法调用来进行交互，从而减少一层 gRPC 的开销，最终的容器启动流程如下：

3.最终的结果是 k8s 的 Pod 启动延迟得到了降低，CPU 和内存占用率都有不同程度的降低。

但是这还不是终点，为了能够直接对接 OCI 的 runtime 而不是 containerd，社区孵化了 CRI-O 并加入了 CNCF。CRI-O 的目标是让 kubelet 与运行时直接对接，减少任何不必要的中间层开销。CRI-O 运行时可以替换为任意 OCI 兼容的 Runtime，镜像管理，存储管理和网络均使用标准化的实现。

某位大神的图,抄过来学习一下

参考资料

• 开放容器标准(OCI) 内部分享