虽然Docker不是最早的容器技术，但却把容器技术推向了应用的高峰。从Docker中拆分而来的Containerd容器运行时，成为了CNCF毕业的第5个项目(前面4个分别是K8s、Prometheus、Envoy和CoreDNS)。本文将介绍容器技术从Docker到Containerd这一路的发展历程。

Docker的拆分

Docker 诞生于 2013 年，Docker 最开始的执行环境是 LXC(Linux Container)，但从版本 0.9 开始 LXC 被 libcontainer 取代。

Linux Container容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。Libcontainer 为 Docker 封装了 Linux 提供的基础功能，如 cgroups，namespaces，netlink 和 netfilter 等。

2016年，Docker 分拆了 Containerd，并将其捐赠给了社区。将这个组件分解为一个单独的项目，使得 Docker 将容器的管理功能移出 Docker 引擎，并移入一个单独的守护进程中，即 Containerd。

Docker拆分以后，对于整个容器技术的发展是非常有利的。容器标准成为一个开放标准，给了其他企业或组织参与的机会。拆分以后的Docker，各组件关系如下所示。

Docker启动容器的过程如下：

1. Docker 引擎创建容器映像
2. 将容器映像传递给 Containerd
3. Containerd 调用 containerd-shim
4. containerd-shim 使用 runC 来运行容器

runC是一个轻量级的跨平台的容器运行时，就是在前面提到的Libcontainer的基础上进化而来的。

实际上，Containerd是Docker管理后台进程dockerd和runC之间的一个中间交流组件。

那么Containerd为什么不直接调用runC，还要通过这个 containerd-shim的进程呢？

Containerd 之所以通过 containerd-shim 去操作容器，这是因为容器进程需要一个父进程来做诸如收集状态。假如这个父进程是 Containerd，每次 Containerd 挂掉或升级，整个宿主机上所有的容器都得退出。引入了 containerd-shim 就规避了这个问题，Containerd 和 container-shim 并不是父子进程关系。

Containerd的发展

从Docker中独立以后，Containerd走上了独立发展的道路，对K8s的容器运行时接口CRI进行了一系列兼容性改造，使其可以独立于Docker，在K8s体系下工作，与K8s生态紧密结合在一起。

Containerd 1.0版本，通过一个单独的进程 CRI-containerd 来完成对 CRI 的适配。

Containerd 1.1 砍掉了 CRI-containerd 这个进程，直接把适配逻辑作为插件(CRI-plugin)放进了 Containerd 主进程中。

通过CRI Plugin插件，Containerd可以由Kubelet来控制，Containerd创建的容器由K8s以Pod方式来组织和管理。

与Containerd类似，Red Hat也推出了另外一个兼容CRI接口的容器运行时CRI-O。CRI-O的目标非常纯粹，就是做一个只服务于K8s的容器运行时，兼容CRI和OCI标准。CRI-O可以说是最小的 CRI 接口实现，遵从 Unix 只做一件事并把它做好的设计哲学。

我们从以上几图中可以注意到，Containerd与底层的容器运行时之间还有一个接口标准，这个标准也非常重要，就是OCI(开放容器计划)标准，篇幅有限，准备放在下一篇文章中介绍。

我会持续更新关于物联网、云原生、数字化技术方面的文章，用简单的语言描述复杂的技术，也会偶尔发表一下对IT产业的看法，请大家多多关注，欢迎留言和转发，希望与大家互动交流，谢谢。