一 什么是Containerd?
Containerd 最早出现在 Docker Engine 中，后来为了将 Docker Engine 做得更加轻量、快速和健壮，在 2016 年 Docker 将 containerd 从 daemon（dockerd） 中独立出来，并完成了与 daemon 的集成
独立出来的 containerd 全面支持 OCI（Open Container Initiative）资源的启动和生命周期的管理，也因此 containerd 可以支持 runc（前身是 Docker 中的 libcontainer，后来捐赠给 LF）以外的其他 OCI 实现。2017 年 Docker 将 containerd 捐献给 CNCF；2019 年 2 月，containerd 毕业
CRI
CRI（Container Runtime Interface 容器运行时接口）Kubernetes 定义的一组与容器运行时进行交互的接口，只要实现了这套接口的容器运行时都可以接到 Kubernetes 平台上来
部分容器运行时并未实现 CRI 接口，可以通过Shim去对接， shim 的职责就是作为适配器将各种容器运行时本身的接口适配到 Kubernetes 的 CRI 接口上，这样Kubernetes就可以通过CRI的统一接口和容器运行状态交互，其中 Docker-Shim 就是 Kubernetes 对接 Docker 到 CRI 接口上的一个垫片实现, 而在1.24以后Kubernetes不在使用Docker-Shim
1.1 Docker 使用Containerd
containerd 独立出来之后，发送到 Docker Engine 的请求：
- Docker daemon 完成镜像管理的操作（拉取、更新镜像）
- daemon 会为创建容器进行准备工作（创建 OCI bundles）：镜像的信息和运行时的信息。
- daemon 调用 containerd 的 CRI 接口启动Container
1.2 Kubelet 使用Containerd
二 Containerd 各个组件及功能
| 模块 | 功能描述 |
| /usr/lib/systemd/system/containerd.service： | ystemd标准的Unit文件，被systemd管理：systemctl start|stop containerd.service |
| /usr/bin/containerd | containerd的守护进程文件，在containerd.service Unit文件中通过ExecStart=/usr/bin/containerd调用，以启动containerd守护进程 |
| /etc/containerd/config.toml | 在启动过程中加载此配置文件，可以在该配置文件中进行丰富多样的配置，以令containerd更贴合我们的实际需要（比如配置私有镜像源等） |
| /usr/bin/containerd-shim | containerd套件，其目的主要是隔离containerd和容器。containerd守护进程收到gRPC调用请求（比如来自Kubelet或Docker的创建容器请求），便会启动/usr/bin/containerd-shim套件 |
| /usr/bin/containerd-shim-runc-v2 | containerd-shim启动后会去启动/usr/bin/containerd-shim-runc-v2，然后立即退出，此时containerd-shim-runc-v2的父进程就变成了systemd(1)，这样containerd-shim-runc-v2就和containerd脱离了关系，即便containerd退出也不会影响到容器 |
| /usr/bin/runc | OCI标准的具体实现就是runc，真正创建和维护容器最终便是由runc来完成的。/usr/bin/containerd-shim-runc-v2会启动runc去create、start容器，然后runc立即退出，容器的父进程就变成了containerd-shim-runc-v2，这也是容器内部可以看到的PID=1的进程 |
| /usr/bin/ctr | 容器管理的客户端工具，可以对标docker命令 |
