CRI（Container Runtime Interface，容器运行时接口）是kubernetes定义的接口，定义了如何操作容器和镜像的统一规范，它主要包含ImageService和ContainerService。因为它已经是一个标准，所以你可以选择任何一个CRI的实现（ containerd和CRI-O）来使用。

CRI-O也是一个CRI的实现，它来自于Red Hat/IBM等

OCI（Open Container Initialtive）提供了容器镜像和运行容器的规范。runc是OCI的一个实现，它是一个创建和运行容器进程的工具。

RUNC 实际上是从libcontainer演化过来的，并且是docker贡献给社区的第一个OCI参考实现，它就是用来创建和运行容器进行的工具。

containerd是容器虚拟化技术，从docker中剥离出来，形成开放容器接口（OCI）标准的一部分。

docker对容器的管理和操作基本都是通过containerd完成的。Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等。详细点说，Containerd 负责干下面这些事情：

管理容器的生命周期(从创建容器到销毁容器)
拉取/推送容器镜像
存储管理(管理镜像及容器数据的存储)
调用 runC 运行容器(与 runC 等容器运行时交互)
管理容器网络接口及网络

注意：Containerd 被设计成嵌入到一个更大的系统中，而不是直接由开发人员或终端用户使用。

我们可以从下面几点来理解为什么需要独立的 containerd：

继续从整体 docker 引擎中分离出的项目(开源项目的思路)

可以被 Kubernets CRI 等项目使用(通用化)

为广泛的行业合作打下基础(就像 runC 一样)

docker安装后containerd默认已安装，containerd包含如下命令组件：

containerd：高性能容器运行时。
ctr：containerd的命令行客户端。
runc：运行容器的命令行工具。

docker、containerd、docker-shim、runC关系：

docker：docker本身而言，包括了docker client和dockerd，dockerd实属是对容器相关操作的api的最上层封装，直接面向操作用户。
containerd：dockerd实际真实调用的还是containerd的api接口（rpc方式实现），containerd是dockerd和runC之间的一个中间交流组件。
docker-shim：一个真实运行容器的载体，每启动一个容器都会起一个新的docker-shim的进程。它通过指定三个参数：容器ID、boundle目录（containerd对应某个容器生成目录）、运行时二进制（默认是runC）来调用runC的api创建一个容器。
runC：一个命令行工具端，根据OCI的标准来创建和运行容器。

containerd应用

docker镜像和containerd镜像通用，但组织方式和存放目录不同，导致docker与ctr命令不通用，各自管理自己的镜像和容器。

此外k8s还有客户端命令crictl，用法与docker基本相同，可crictl -h查看用法。

containerd的默认配置文件为/etc/containerd/config.toml，可通过命令：

containerd config default

输出默认配置，可参考文档https://github.com/containerd/containerd/blob/master/docs/ops.md