之前我们已经围绕
containerd
的不同功能，设计方式，以及解决的一些问题进行了几次讨论。
Containerd
由
Docker
，
Kubernetes CRI
和其他几个项目使用，不过这个帖子是写给可能并不知道
containerd
在这些平台中具体做什么的人。将来我想围绕
containerd
的功能集和设计上多写一些东西，但现在我们将从基础开始说起。
我认为容器系统有时有点让人难以理解，尤其是我们使用的术语。这是什么？运行时。这个呢？运行时
... containerd
从名字上看，并不像有的人告诉我包含电脑迷之类的，
containerd
是一个容器后台驻留程序。它最初是作为
OCI
运行时的集成点，例如
runC
。但在过去六个月里，它增加了很多功能，使其符合现代容器平台（例如
Docker
和
Kubernetes
）的需求。
由于在内核空间中没有像
Linux containers
这样的东西，容器就是将各种内核功能捆绑在一起。当构建一个大型平台或分布式系统时，您希望有一个抽象层来运行一个容器，这个抽象层把管理代码、系统调用和内核功能隔离开来。这个抽象层就是
containerd
发挥作用的地方。
containerd
提供了客户端层，平台在这个基础上搭建，而不必在内核层。与用
clone
（）或
mount
（）管理调用相比，使用
Container, Task,
和
Snapshot
类型的对象则要愉快的多。
Containerd
是针对
Docker
和
Kubernetes
以及任何其他容器平台使用而设计的，这些平台希望免除系统调用以及操作系统特定的功能，直接在
linux
，
windows
，
solaris
或其他操作系统上运行容器。考虑到这些用户，我们想确保
containerd
只有他们需要的功能，而没有其他不需要的功能。实际上这是不可能的，但至少这是我们努力的方向。像网络之类的，不在
containerd
考虑的范围。原因在于，当构建分布式系统时，网络是一个非常重要的方面。现在，有了
SDN
和服务发现技术，网络是更细化的平台，而不只是在
linux
上抽出
netlink
调用。大多数新的覆盖网络是基于路由的，并且每当创建或删除新的容器时，需要更新路由表。服务发现、
DNS
等都必须被通知这些更改。如果我们向
containerd
添加了网络，将会有很繁重的大块代码来支持所有不同的网络接口，钩子和集成点。而我们做的，则是选择了
containerd
内部强大的事件系统，以便多个客户订阅他们关心的事件。我们还公开了一个任务的
API
，允许用户创建一个正在运行的任务，并向容器的网络命名空间添加接口，然后启动容器的进程，而不用在容器生命周期的各个不同节点调用复杂的钩子。
过去几个月里，在
containerd
里添加的另一个领域是完整的存储和分发系统，支持
OCI
和
Docker
的镜像格式。在
containerd API
中有一个完整的内容寻址存储系统，不仅用于镜像，还用于连接到容器的元数据、检查点和任意数据。
我们也花时间重新思考了
“graphdrivers”
的工作原理。这些是覆盖或块级文件系统，允许镜像具有
layers
，支持高效构建。
Graphdrivers
最初是
Solomon
和我一起做的，当时添加了对
devicemapper
的支持。那个时候，
Docker
只支持
AUFS
，因此我们模仿
overlay
文件系统做了
graphdrivers
。然而，做一个像
devicemapper/lvm
这样的块级文件系统，并且性能像
overlay
文件系统一样，从长远来看要更难一些。接口必须不断扩展，以支持不断增加的功能需要。对于
