谁在运行我的 Kubernetes Pod？容器运行时的过去、现在和未来

本文关键点

• 随着时间的推移，容器运行时的选择已经不仅仅是 Docker 引擎了，还有了其他的选项

• 开放容器计划(OCI)已成功标准化了容器和容器镜像的概念，以保证运行时之间的互操作性

• Kubernetes 增加了一个容器运行时界面(CRI)，允许容器运行时可插入下面的 Kubernetes 编排层

• 为了日益增长的安全性需求，在这个领域的创新允许容器使用轻量级虚拟化和其他独特的隔离技术

• 在 OCI 和 CRI 之间，互操作性和选择正在成为容器运行时和编制生态系统的现实

在 Linux 操作系统的世界中，容器技术已经存在了很长一段时间，可以追溯到十多年前关于文件系统和进程的独立命名空间的最初想法。在最近的某个时间点，LXC 诞生了，并成为 Linux 用户访问隐藏在 Linux 内核中的强大隔离技术的常见方式。

即使 LXC 屏蔽一些组装的各种技术基础的复杂性，我们现在通常将此称之为一个“容器”，但容器仍然像魔法一般，并没有被大众广泛使用，除了那些精通容器艺术的人。

Docker 的到来改变了所有这一切，在 2014 年新的 Linux 内核开发人员以 LXC 为底层更好地包装了相同的技术，事实上,早期版本的 Docker 背后仍在使用 LXC ，容器真正走向大众是因为开发人员被 Docker 容器镜像的简单性和重用性以及简单的运行时命令吸引了。

当然，Docker 并不是唯一一个想要实现容器市场份额的公司，因为在 2014 年最初的兴趣爆发之后，炒作周期并没有显示出放缓的迹象。在过去的几年中，CoreOS (rkt),Intel Clear Containers 和hyper.sh (与容器相结合的轻量级虚拟化)等公司提出了各种不同的容器运行时方案，在高性能计算(HPC)科学研究领域出现了 Singularity 以及shifter技术。

随着市场的持续增长和成熟，Docker 通过开放容器计划 (OCI)推广的最初想法开始标准化。如今，许多容器运行时要么是 OCI 兼容的，要么正在要 OCI 兼容的，这为供应商提供了一个公平的竞争环境，以区分它们的特性或专门关注的功能。

Kubernetes 大受欢迎

容器进化的下一步是将分布式计算、微服务和容器一起引入这个快速开发和部署迭代的新世界，我们可能会称其为 DevOps 吧，它将随着 Docker 的日益流行而迅速兴起。

Apache Mesos和其他分布式软件编配平台在其占据优势地位之前就已经存在，而 Kubernetes也从谷歌的一个小型开源项目快速崛起，成为云原生计算基金会(CNCF)的旗舰项目。即使在 Docker 发布了一个竞争的编配平台 Swarm之后，Docker 本身就内置了 Docker 的简单风格，并关注于默认安全集群配置，但它似乎还不足以阻止人们对 Kubernetes 日益增长的兴趣。

在云原生社区之外，许多感兴趣的人还是会把它搞混，忽然间分不清 Kubernetes 和 Docker 是竞争关系，还是合作关系。由于 Kubernetes 只是一个编排平台，因此需要一个容器运行时来管理通过 Kubernetes 编排的实际运行的容器。从第一天起，Kubernetes 就一直在使用 Docker 引擎，即使 Swarm 和 Kubernetes 是关系紧张的编配竞争对手，Docker 仍然是一个可运维的 Kubernetes 集群所需的默认运行时。

除了 Docker 之外，还有几个容器运行时可供选择，但很明显，若某个容器运行时想与 Kubernetes 交互，则需要为其专门编写一个接口(或 shim)，每个容器运行时都得专门编写。由于缺乏明确接口用于容器运行时的实现，向 Kubernetes 添加更多的运行时选项变得很麻烦。

容器运行时接口(CRI)

将运行时选择合入到 Kubernetes 中的需求日益增长，为了解决这一挑战，社区定义了一个接口，它是一个特定的函数，容器运行时必须代表 kubernet 实现它，称为容器运行时接口(CRI)。这既解决了变更容器运行时必须得更改大量位置的问题，又明确了潜在的运行时要成为 CRI 运行时必须支持哪些功能。

正如您可能预期的那样，CRI 对运行时的期望相当简单。运行时必须能够启动/停止 pod，并处理 pod 中的所有容器操作(启动、停止、暂停、终止、删除)，以及使用容器注册表处理镜像管理。还要有一些收集日志、度量收集等相关的实用程序和辅助功能，就像您所期望的那样。

当新特性进入 Kubernetes 时，如果它们依赖于容器运行时层，那么就要更改版本控制的 CRI API,新特性和新版本的运行时支持(比如最近的一个例子就是用户命名空间)必须发布以处理来自 Kubernetes 的新功能依赖。

当前 CRI 格局

截至 2018 年，Kubernetes 下面的容器运行时有几个选项。如下图所示，Docker 仍然是 Kubernetes 一个有效选择，它的shim现在实现了 CRI API。事实上，今天在大多数情况下，Docker 仍然是 Kubernetes 安装的默认运行时。

Docker 使用 Swarm 的编排策略和 Kubernetes 社区的紧张竞争关系产生了一个有趣的结果，那就是形成了一个联合项目，它以 Docker 的运行时为核心，并将其作为一个新的联合开发的开源项目，命名为 containerd。然后，Containerd 还向 CNCF 捐了款，CNCF 是管理和拥有 Kubernetes 项目的同一家基金会。

通过将 containerd 作为核心，Docker 和 Kubernetes 都不再固步于自己的纯运行时了，它作为 Docker 的潜在替代品，已经在许多 Kubernetes 安装中流行起来。今天，IBM Cloud 和谷歌云都以 beta/早期访问模式提供了基于 containerd 的集群。微软 Azure 也承诺在未来转向 containerd，亚马逊还在评估 ECS 和 EKS 容器产品下的运行时选择选项，暂时还在继续使用 Docker。

Red Hat 还通过在 OCI 参考实现 runc 周围创建一个名为cri-o的纯 CRI 实现，从而进入了容器运行时领域。Docker 和 containerd 也基于 runc实现，但是 crio 表示，对于 Kubernetes 来说，它的运行时“刚刚好”，不需要更多，只在基本的 runc 二进制文件之上添加了实现 Kubernetes CRI 所必需的函数。

轻量级虚拟化项目 Intel Clear container和hyper.sh，合并了 OpenStack Foundation 项目下的Kata容器，也针对额外的隔离通过 CRI 实现 frakti提供了他们的虚拟化容器风格。cri-o 和 containerd 也支持 Kata 容器，这样它们符合 oci 的运行时也可以作为 CRI 实现中的可插入运行时选项。

未来预测

虽然声称了解未来基本不是个明智的做法，但我们至少可以推断出一些趋势，这些趋势是随着容器生态系统从大量的兴奋和炒作发展到更成熟的存在阶段而出现的。

早期有人担心，容器生态系统的争端会造成一个支离破碎的环境，在这个环境中，各方最终会对容器的概念产生不同的、互不相容的想法。感谢主要供应商和参与者为 OCI 做出的工作努力和承诺，我们看到整个行业在软件产品优先保证 OCI 合规方面进行了健康的投资。

在新的空间中，由于独特的约束(例如 HPC)， Docker 的标准使用得到的关注较少，即使是在可行的容器运行时上非基于 Docker 的尝试现在也开始关注 OCI。目前正在进行讨论，希望 OCI 也能符合科学界和研究社区的具体需要。

增加了通过 CRI 在 Kubernetes 中可插入容器运行时的标准化，我们可以设想这样一个世界：开发人员和运维人员可以针对他们的工作选择工具和软件栈，并且仍然期望并体验跨容器生态系统的互操作性。

为了帮助您更清楚地了解这一点，让我们以下面的具体示例为例：

1. MacBook 上的开发人员使用 Docker 来开发她的应用程序，甚至使用内置的 Kubernetes 支持(使用 Docker 作为 CRI 运行时)来尝试在 Kubernetes pods 中部署她的新应用程序。

2. 应用程序在供应商产品上通过 CI/CD 使用 runc 和一些供应商编写的代码来打包 OCI 映像并将其推到企业容器注册中心进行测试。

3. 在内部部署的 Kubernetes 集群中，使用 containerd 作为 CRI 运行时对应用程序运行一组测试。

4. 这个特定的企业选择使用 Kata 容器来处理生产中的某些工作负载，当应用程序被部署时，它运行在与 containerd 一起运行的 pod 中，它被配置为使用 Kata 容器作为基本运行时，而不是 runc。

整个示例场景工作得完美无缺，因为它符合 OCI 对运行时和镜像的规范，而且 CRI 允许运行时选择这种灵活性。

容器生态系统的灵活性和选择机会对我们来说很有好处，这个行业自 2014 年以来几乎一夜之间崛起，这对于这个行业的成熟非常重要。随着我们进入 2019 年或者更远的将来，对于那些使用和创建基于容器的平台的人来说，持续创新和灵活性的未来是光明的！

更多的信息可以从 Phil Estes 最近的 QCon NY 谈话中找到：“CRI 运行时深度讨论：谁在运行我的 Kubernetes Pod!”

关于作者

Phil Estes 是 IBM Watson 和云平台部门的杰出工程师兼 CTO，负责容器和 Linux OS 架构策略。Phil 目前是 Docker(现在是 Moby)引擎项目 CNCF containerd 的 OSS 维护者，也是开放容器计划

(OCI)技术监督委员会和 Moby 技术指导委员会的成员。Phil 是 Docker captain 项目的成员，在开源和容器生态系统方面有着广泛的经验。Phil 在业界和开发者大会以及见面会上发表演讲，讨论与开源、Docker 和 Linux 容器技术相关的话题。菲尔经常就这些话题写博客，可以在 Twitter 上 @estesp 找到他。

查看英文原文：Who Is Running My Kubernetes Pod? The Past, Present, and Future of Container Runtimes