本篇是第八部分“生态篇”的第二篇。在这个部分，我会为你介绍 Docker>Docker 生态中的相关项目，以及如何参与到 Docker>Docker 项目中，最后会聊聊 Docker>Docker 未来的走向，上篇，我为你介绍下 Docker>Docker 与 Kubernetes>Kubernetes 相关的内容。本篇，我们来聊聊容器运行时 containerd。

背景

在之前的《Docker>Docker 核心架构及拆解（上）》中，我曾为你介绍了一些 containerd 与 Docker>Docker 之间的联系。也可以说 containerd 目前是 Docker>Docker 的运行时，是 Docker>Docker 核心架构中一个重要的组成部分了。

那么 containerd 为何有如此重要的作用呢？这就要从 containerd 诞生的背景开始说起了。

containerd 是由 Docker>Docker Inc. 创建并开源出的容器运行时工具，自 Docker>Docker v1.11 中开始集成进 Docker>Docker。在 2017 年时，Docker>Docker 将 containerd 捐给 CNCF，并且 containerd 于 2019 年 2 月底正式从 CNCF 毕业。

我认为 containerd 出现的主要原因有以下几个：

• 为了减小 Docker>Docker 的体积，将其核心组件进行拆分，这样所有的组件都可以分解成单独的项目并且不断迭代改进，Docker>Docker 可以选择性的进行集成。这有点像我们谈论微服务架构时的思路。
• 为了改善 Docker>Docker 的性能，containerd 专门为性能做过优化，使用它作为 Docker>Docker 的容器运行时管理组件，可显著提升 Docker>Docker 的性能。
• 为了实现容器生态的行业标准，Docker>Docker 将 containerd 分拆成了独立项目，并捐给了 CNCF 这个中立基金会。这样无论是