10. Docker——Containerd

本章讲解知识点

• 容器运行时（Container Runtime）
• Containerd
• Containerd 与 Docker 命令对比

<br>

1. 容器运行时（Container Runtime）

容器运行时（Container Runtime）是一种程序，用于管理和运行容器镜像。它可以在计算机上创建和运行容器，提供容器隔离的环境，以及与其他计算机资源进行交互。

常用的容器运行时包括 Docker、rkt、CRI-O 等，它们都能够将容器镜像转换为运行中的容器实例，并且能够提供许多功能，如存储管理、网络管理和安全管理等。

所以说，Docker 只是其中一种容器运行时，不能代表容器虚拟技术的全部，只是由于 Docker 发展最快，以至于成为了容器的标准。

然而三十年河东，三十年河西，就当我们一直以外 Docker 稳坐容器霸主地位时，Kubernetes 突然宣布，容器运行时弃用 Docker，换用 Contained，在业界也引起了不小的震动。

说起来又是一段腥风血雨的故事：

2014 年，Docker 正如日中天，在容器领域没有任何对手，而这时 Kubernetes 才刚刚诞生，虽然背后有 Google 和 Borg 的支持，但还是比较弱小的。所以，Kubernetes 很自然就选择了在 Docker 上运行，毕竟“背靠大树好乘凉”，同时也能趁机“养精蓄锐”逐步发展壮大自己。

整个容器社区可谓热闹非凡。这令人兴奋的繁荣背后，却浮现出了更多的担忧。这其中最主要的负面情绪，是对 Docker 公司商业化战略的种种顾虑。事实上，很多从业者也都看得明白，Docker 项目此时已经成为 Docker 公司一个商业产品。而开源，只是 Docker 公司吸引开发者群体的一个重要手段。不过这么多年来，开源社区的商业化其实都是类似的思路，无非是高不高调、心不心急的问题罢了。而真正令大多数人不满意的是，Docker 公司在 Docker 开源项目的发展上，始终保持着绝对的权威和发言权，并在多个场合用实际行动挑战到了其他玩家（比如，CoreOS、RedHat，甚至谷歌和微软）的切身利益。

这种情绪在 2015 年达到了一个小高潮，容器领域的其他几位玩家开始商议“切割” Docker 项目的话语权。而“切割”的手段也非常经典，那就是成立一个中立的基金会。于是，2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。

这套标准和规范，就是 OCI（ Open Container Initiative ）。OCI 的提出，意在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来。这样做，一方面可以改善 Docker 公司在容器技术上一家独大的现状，另一方面也为其他玩家不依赖于 Docker 项目构建各自的平台层能力提供了可能。不过，不难看出，OCI 的成立更多的是这些容器玩家出于自身利益进行干涉的一个妥协结果。所以，尽管 Docker 是 OCI 的发起者和创始成员，它却很少在 OCI 的技术推进和标准制定等事务上扮演关键角色，也没有动力去积极地推进这些所谓的标准。这，也正是迄今为止 OCI 组织效率持续低下的根本原因。眼看着 OCI 并没能改变 Docker 公司在容器领域一家独大的现状，Google 和 RedHat 等公司于是把与第二把武器摆上了台面。Docker 之所以不担心 OCI 的威胁，原因就在于它的 Docker 项目是容器生态的事实标准，而它所维护的 Docker 社区也足够庞大。可是，一旦这场斗争被转移到容器之上的平台层，或者说 PaaS 层，Docker 公司的竞争优势便立刻捉襟见肘了。在这个领域里，像 Google 和 RedHat 这样的成熟公司，都拥有着深厚的技术积累；而像 CoreOS 这样的创业公司，也拥有像 Etcd 这样被广泛使用的开源基础设施项目。可是 Docker 公司呢？它却只有一个 Swarm。

所以这次，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。

而为了打造出这样一条围绕 Kubernetes 项目的“护城河”，CNCF 社区就需要至少确保两件事情：1.Kubernetes 项目必须能够在容器编排领域取得足够大的竞争优势；2.CNCF 社区必须以 Kubernetes 项目为核心，覆盖足够多的场景。

在 2016 年底的 1.5 版里，Kubernetes 引入了一个新的接口标准：CRI ，Container Runtime Interface。CRI 采用了 ProtoBuffer 和 gPRC，规定 kubelet 该如何调用容器运行时去管理容器和镜像，但这是一套全新的接口，和之前的 Docker 调用完全不兼容。

Kubernetes 意思很明显，就是不想再绑定在 Docker 上了，允许在底层接入其他容器技术（比如 rkt、kata 等），随时可以把 Docker“踢开”。

但是这个时候 Docker 已经非常成熟，而且市场的惯性也非常强大，各大云厂商不可能一下子就把 Docker 全部替换掉。所以 Kubernetes 也只能同时提供一个“折中”方案，在 kubelet 和 Docker 中间加入一个“适配器”，把 Docker 的接口转换成符合 CRI 标准的接口。因为这个“适配器”夹在 kubelet 和 Docker 之间，所以就被形象地称为是“shim”，也就是“垫片”的意思。有了 CRI 和 shim，虽然 Kubernetes 还使用 Docker 作为底层运行时，但也具备了和 Docker 解耦的条件，从此就拉开了“弃用 Docker”这场大戏的帷幕。

面对 Kubernetes“咄咄逼人”的架势，Docker 是看在眼里痛在心里，虽然有苦心经营了多年的社区和用户群，但公司的