谁在运行我的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