Containerd 简介

我们可以把 docker 抽象为下图所示的结构(此图来自互联网)：

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

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

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

为什么需要 containerd

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

• 继续从整体 docker 引擎中分离出的项目(开源项目的思路)
• 可以被 Kubernetes CRI 等项目使用(通用化)
• 为广泛的行业合作打下基础(就像 runC 一样)

重复一遍：Containerd 被设计成嵌入到一个更大的系统中，而不是直接由开发人员或终端用户使用。所以 containerd 具有宏大的愿景(此图来自互联网)：

当 containerd 和 runC 成为标准化容器服务的基石后，上层的应用就可以直接建立在 containerd 和 runC 之上。上图中展示的容器平台都已经支持 containerd 和 runC 的组合了，相信接下来会有更多类似的容器平台出现。

Containerd 的技术方向和目标

• 简洁的基于 gRPC 的 API 和 client library
• 完整的 OCI 支持(runtime 和 image spec)
• 同时具备稳定性和高性能的定义良好的容器核心功能
• 一个解耦的系统(让 image、filesystem、runtime 解耦合)，实现插件式的扩展和重用

下图展示了 containerd 的架构(此图来自互联网)：

在架构设计和实现方面，核心开发人员在他们的博客里提到了通过反思 graphdriver 的实现，他们将 containerd 设计成了 snapshotter 的模式，这也使得 containerd 对于 overlay 文件系、snapshot 文件系统的支持比较好。
storage、metadata 和 runtime 的三大块划分非常清晰，通过抽象出 events 的设计，containerd 也得以将网络层面的复杂度交给了上层处理，仅提供 network namespace 相关的一些接口添加和配置 API。这样做的好处无疑是巨大的，保留最小功能集合的纯粹和高效，而将更多的复杂性及灵活性交给了插件及上层系统。

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的标准来创建和运行容器。