之前我们已经围绕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文件系统一样，从长远来看要更难一些。接口必须不断扩展，以支持不断增加的功能需要。对于containerd，我们采取了一个截然不同的处理方法，使overlay文件系统像一个snapshotter，而不是反过来的情况。我们这样做更容易，因为overlay文件系统比BTRFS，ZFS和devicemapper等给文件系统做快照的更灵活，因为后者没有严格的父/子关系。这有助于我们为snapshotters构建一个较小的接口，同时仍满足诸如构建之类的需求，并减少所需的代码量，因此从长远来看更易维护。
那么，用containerd，能get到什么？您可以拉取镜像以及管理镜像。使用API去创建，执行和管理容器及其任务，从而获取容器的整个运行周期。一个专门用于快照管理的API。从本质上说，你只需要构建一个容器平台，而不必处理底层操作系统的细节。我认为containerd的最重要部分，是具有一个稳定的API版本，可以修复bug和安全补丁反向移植。