注意事项 佩雷夫 ：我们已经写了不止一个关于容器运行时（容器运行时）的出版物（请参阅本文结尾的链接）-通常，它们是在Kubernetes的上下文中讨论的。 但是，这些材料经常引起读者的疑问，表明对下一个项目的来源，与其他项目的联系方式以及整个容器“动物园”中通常发生的情况缺乏了解。
IBM Watson＆Cloud Platform容器和Linux体系结构技术总监Phil Estes最近发表的一篇文章，对如何导航和更广泛地了解谁丢失（或从未抓住）事件线索进行了很好的回顾。 作为Moby和容器项目的维护者之一，Open Container Initiative（OCI）和Moby的技术委员会的成员，并且还拥有Docker Captain的身份，作者撰写了关于容器运行时新世界的过去，现在和未来的文章。 最懒惰的是，材料从紧凑的TL开始；关于主题的DR ... 主要发现
- 随着时间的流逝，容器运行时之间的选择越来越多，比流行的Docker引擎提供了更多的选择。
- 开放容器倡议（OCI）已成功标准化容器和容器映像的概念，以确保运行时环境之间的互操作性（“互操作性”-大约是Transl。） 。
- Kubernetes添加了Container Runtime Interface（CRI），该容器允许容器使用K8s中的底层业务流程层连接到运行时环境。
- 该领域的创新使容器能够利用轻量级虚拟化和其他独特的隔离技术来满足不断增长的安全要求。
- 借助OCI和CRI，互操作性和选择已成为运行时容器和业务流程环境的生态系统中的现实。
容器化技术在Linux操作系统世界中已经存在了很长一段时间-关于文件系统和进程的单独名称空间的第一个想法出现于十多年前。 在相对较近的过去，LXC出现并成为Linux用户与Linux内核中隐藏的强大隔离技术进行交互的标准方式。
但是，尽管
LXC试图掩盖将当今我们通常称为容器的各种技术“内幕”相结合的复杂性，但是容器仍然是一种魔力，并且仅在那些知识渊博的人的世界中变得更强大，并且在群众中并未得到广泛分布。
2014年，一切都随着
Docker发生了变化，当时出现了一种新的，对开发人员友好的，与LXC服务的相同Linux内核技术的包装器-毕竟，“幕后”的早期Docker版本使用LXC，并且这些容器成为了-这是一种真正的大众现象，因为开发人员沉迷于重用Docker容器映像的简单性和可能性以及使用它们的简单命令。
当然，当伴随着他们的炒作在2014年首次引起人们的浓厚兴趣之后，并没有消退时，Docker并不是唯一一个想要在集装箱市场上获得份额的人。 多年以来，在高性能计算（HPC）研究领域，
CoreOS （rkt） ，
Intel Clear Containers ，
hyper.sh （基于轻量级容器的虚拟化）以及
奇异性和
移位器的可执行容器环境出现了各种替代方案。
市场持续增长和成熟，随着
开放容器倡议（OCI）的出现，人们努力标准化Docker提倡的最初想法。 如今，许多可执行容器环境要么已经与OCI兼容，要么已经与OCI兼容，从而为制造商提供了平等的条件来提升其针对特定应用程序的特性和功能。
Kubernetes的受欢迎程度
容器发展的下一阶段是将分布式计算容器和微服务与容器结合在一起-在快速开发和部署迭代的新世界（我们可以说DevOps）中，所有这些都随着Docker的普及而迅速发展。
尽管
Apache Mesos和其他软件编排平台在
Kubernetes统治之前就已经存在，但
K8迅速从Google的一个小型开源项目发展到
Cloud Native Computing Foundation（CNCF）主项目。
注意事项 佩雷夫 ：您知道CNCF在Kubernetes 1.0发行之际出现在2015年吗？ 同时，该项目由Google转移到一个新的独立组织，该组织成为Linux基金会的一部分。
K8s 1.0发布活动由Mesosphere，CoreOS，Mirantis，OpenStack，Bitnami等赞助
来自有关在ZDNet上发布Kubernetes 1.0的新闻即使Docker发布了竞争对手的编排平台
Swarm （内置于Docker中并具有Docker简单性并专注于默认安全集群配置）之后，这仍然不足以阻止人们对Kubernetes的日益增长的兴趣。
但是，快速增长的云原生社区之外的许多利益相关者感到困惑。 一般的观察者不知道发生了什么：Kubernetes与Docker进行斗争还是他们的合作？ 因为Kubernetes只是一个编排平台，所以需要一个可执行的容器环境来直接启动在Kubernetes中编排的容器。 从一开始，Kubernetes就使用Docker引擎，尽管Swarm和Kubernetes之间存在竞争压力，但Docker仍然是默认运行时，并且是Kubernetes集群正常运行所必需的。
除了Docker以外的少量容器运行时，似乎很明显，将运行时与Kubernetes配对将需要为每个运行时专门编写接口（垫片）。 缺乏用于实现容器运行时的清晰接口，这使得在Kubernetes中添加对新运行时的支持变得非常困难。
容器运行时接口（CRI）
为了解决在Kubernetes中实现运行时的日益复杂性，社区定义了一个接口-容器运行时应在Kubernetes中实现的特定功能-将其命名为
Container Runtime Interface（CRI） （它出现在Kubernetes 1.5中-大约翻译）。 。 该事件不仅解决了Kubernetes代码库中越来越多的片段影响容器运行时使用的问题，而且还有助于准确地了解潜在的运行时如果希望遵守CRI应该支持哪些功能。
您可能会猜到，CRI期望运行时中的事情非常简单。 这样的环境应该能够启动和停止容器，在容器的上下文中处理容器的所有操作（开始，停止，暂停，终止，删除），还应该支持使用注册表管理容器映像。 还有用于收集日志，指标等的辅助功能。
当新功能出现在Kubernetes中时，如果它们取决于容器运行时的层，则会对版本化的CRI API进行此类更改。 反过来，这又在Kubernetes上创建了新的功能依赖关系，并要求发布支持新功能的更新版本的运行时（最近的一个示例是用户名称空间）。
当前的CRI格局
截至2018年，Kubernetes中有多个选项可用作容器运行时。 如下图所示，真正的选择之一仍然是Docker及其实现CRI API的
dockershim 。 实际上，在当今的大多数Kubernetes安装中，仍然是他（Docker）是默认运行时。
Swarm的Docker编排策略与Kubernetes社区之间紧张关系的有趣结果之一是一个联合项目，该项目以Docker的运行时为基础，并从中收集了一个新的，共同开发的开源项目-
容器化的 。 随着时间的流逝，已将集装箱运输到CNCF，CNF是管理和拥有Kubernetes项目的同一组织。
（ 请注意翻译 ：我们在另一篇文章中更详细地描述了容器的外观。）
来自Docker博客上关于容器的公告容器化是Docker和Kubernetes（通过CRI）的简单，基本且独立于公司的运行时实现（通过CRI），已开始流行，可以在许多Kubernetes安装中替代Docker。 迄今为止，IBM Cloud和Google Cloud均具有处于早期访问/ Beta模式的基于容器的集群。 Microsoft Azure还承诺将来会切换到容器化，而Amazon在继续使用Docker的同时，仍在为其容器解决方案（ECS和EKS）考虑运行时的各种选择。
红帽已经通过基于OCI参考实现
runc创建一个称为
cri-o的简单CRI实现进入了容器
运行时空间。 Docker和容器化也是基于runc的，但是cri-o的创建者声称，它们的运行时对于Kubernetes来说“足够”，并且它们不需要更多，他们只是添加了最基本的功能，以在基本runc二进制文件上实现Kubernetes CRI。
（ 请注意翻译 ：我们在本文中详细介绍了CRI-O项目，并在这里以podman的形式介绍了它的进一步开发。）轻量级虚拟化项目：Intel Clear Containers和hyper.sh –出现在OpenStack Foundation的狂热中，
Kata容器 ，并提供了他们的虚拟化容器愿景，可使用名为
frakti的CRI实现进行进一步隔离。 cri-o和containered都可以与Kata容器一起使用，因此可以选择与OCI兼容的运行时作为可插入选项。
预测未来
说您知道未来通常不是很明智，但是随着容器生态系统从热情和炒作转向我们生存的更成熟阶段，我们至少可以解决一些新兴趋势。
早期有人担心容器生态系统会形成一个分散的环境，容器的不同参与者会就容器是什么提出不同且不兼容的想法。 得益于OCI的工作以及主要供应商和参与者的负责任的行动，我们看到了优先与OCI兼容的软件产品行业中的健康环境。
即使在由于现有限制而在Docker使用标准遇到较少阻力的较新环境中（例如，在HPC中），创建非基于Docker的容器容器环境的所有尝试也引起了OCI的注意。 关于OCI是否可以成为满足科学家和研究人员社区特定需求的可行解决方案的讨论正在进行中。
再加上使用CRI在Kubernetes中实现插件容器运行时的标准化，我们可以想象一个世界，开发人员和管理员可以为他们的任务选择正确的工具和软件堆栈，在整个容器生态系统中等待和观察互操作性。
考虑一个具体的例子，以更好地了解这个世界：
- 拥有MacBook的开发人员使用Docker for Mac来开发其应用程序，甚至使用内置的Kubernetes支持（此处的Docker类似于CRI运行时）来尝试在K8s Pod上部署新的应用程序。
- 该应用程序通过供应商软件中的CI / CD进行传递，该CI / CD使用runc和特殊（由供应商编写）代码包装OCI映像并将其加载到容器的公司注册表中以进行测试。
- 本地Kubernetes集群安装与作为CRI运行时的容器一起使用，为应用程序运行了一组测试。
- 由于某种原因，该公司选择了Kata容器用于某些生产工作负载，因此，在部署应用程序时，它从带有容器的Pod开始，容器配置为使用Kata容器而不是runc作为运行时。
由于与运行时环境和映像的OCI规范兼容，并且CRI提供了选择运行时的灵活性，因此，上述整个方案都可以很好地工作。
这种可能的灵活性和选择能力使集装箱生态系统真正地出类拔萃，并且也是行业成熟的重要条件，该行业自2014年以来发展迅速。 在2019年及以后的几年中，对于那些使用和创建基于容器的平台的人来说，我将看到不断的创新和灵活性的光明前景。
有关该主题的更多信息，请参见Phil Estes最近在QCon NY上的演讲：“
CRI运行时深度学习：谁在运行我的Kubernetes Pod ！？ ”
译者的PS
另请参阅我们的博客：