太平洋科技企业站

为什么容器运行时仍然很重要

佚名整合编辑：王珂玥发布于：2023-10-26 09:56

今天，Kubernetes和相关项目是云开发中最受关注的焦点——除了作为实现细节之外，“容器”这个词几乎被遗忘了。尽管如此，CRI-O容器运行时项目仍在不断发展，并经常实现新特性，以提高云的灵活性、安全性和性能。重要的是，这是Kubernetes用户需要的工作，只能在容器运行时级别完成。

容器运行时项目已经在云原生计算基金会(CNCF)中达到了毕业阶段，与另一个主要的容器运行时项目containerd一起显示了它的成熟度。这显示了Kubernetes的两个容器选项的完整性和稳定性。然而，改进容器运行时的主要工作仍在继续，包括管理设备和插件、保护供应链以及创建一个用Rust编写的新容器监视器。大部分工作都是在两个项目之间协调完成的，它们的关系可以被描述为“友好的竞争”。

containerd和CRI-O维护者之间的合作使我们能够开发复杂的Kubernetes功能，或者一起维护像cri-tools这样的项目，”CRI-O维护者和Kubernetes SIG-Release主席Sascha Grunert说。

什么是容器运行时?

大多数人都知道Kubernetes是一个在服务器集群上运行容器的服务。但是Kubernetes实际上并不运行容器；相反，它调度它们，然后使用容器运行时接口(container runtime Interface, CRI)向每个服务器节点上的容器运行时程序发送请求。运行时处理容器的实际下载和执行。有两个主流项目，CRI-O和containerd，它们都是CNCF下的开源项目。

“人们可以把Kubernetes(或者更具体地说，在这种情况下，Kubelet)、CRI和CRI-O想象成老板、他们说的语言和员工。Kubelet将container/pod/image操作的实际工作委托给CRI-O，并通过CRI协议委托这些责任，”CRI-O维护者Peter Hunt解释说。

在Kubernetes的早期，它使用Docker运行时运行容器。Docker是一个重量级的交互式开发人员环境，但它并不是真正想要成为更大系统的一小部分。因此，在2016年，像Antonio Murdaca 和 Mrunal Patel 这样的Kubernetes贡献者开始研究一个容器运行时，它将满足CRI，而不是更多，并将其命名为CRI-O。一年后，Docker开发人员分离了Docker的容器运行时内核，命名为containerd，并将其贡献给CNCF。这两个项目都得到了快速的发展，在2022年，Kubernetes项目能够放弃使用完整的Docker作为其容器运行时的支持，而是提供CRI-O和容器运行时的选择。

除了CRI-O和containerd(有时也称为高级容器运行时或容器管理器)的CRI实现之外，OCI和CNCF生态系统也在不断发展，发明了运行容器和自定义行为的新方法。例如，Kata Containers是一个OCI运行时(有时称为低级运行时)，它在虚拟机(VM)中运行pod。许多用户甚至希望进一步定制资源和容器创建，特别是在CRI-O和容器都支持它们的情况下。

NRI添加插件到容器运行时

虽然替代容器运行时令人兴奋，但最终它们代表了容器技术的碎片化问题。拥有数十个容器运行时，特别是一些为支持特殊硬件设备而设计的容器运行时，会给用户带来困惑和问题。开放容器计划(OCI)的规范团队在2017年认识到这一点，并开始研究扩展容器运行时的方法。运行时开发人员尝试了几种不同的东西，最终产生了节点资源接口(NRI)，这是一种允许供应商构建容器运行时插件的规范和API。NRI是containerd和CRI-O开发人员之间的一个完全协作的项目。它于9月发布了0.5版本，该项目预计在2023年底达到1.0稳定性。

NRI允许插件作者修改容器运行时的行为，以支持诸如将容器执行固定到特定CPU核心或支持专用硬件之类的事情。人工智能和机器学习系统可以在NVIDIA GPU上运行容器。这允许系统供应商和所有者编写设备管理器，为他们的特定硬件(甚至是边缘设备)优化容器行为。

随着Kubernetes扩展到边缘计算和人工智能用例，能够在这些特殊硬件环境中运行的需求越来越大。Kubernetes不能自己启用它们;它需要容器运行时功能的支持。NRI将实现这一点。

重写Rust中的conmon

甚至容器运行时也涉及多个组件。其中一种是conmon，是“容器监视器”的简称，它调度执行请求并对容器事件作出反应。Conmon可以追溯到CRI-O的创建，因此，它被旧代码和技术债务所拖累。2022年，CRI-O维护者在Rust中重新编写了common。Rust是一种较新的编程语言，由于其内存安全性而进入公众视野，这使得美国网络安全和基础设施安全局(U.S. Cybersecurity and Infrastructure Security Agency,CISA)对该语言给予了特别关注。

Hunt说:“common虽然忠实地为CRI-O服务了一辈子，但已经变得难以处理，难以扩展。”“此外，混合的过程比需要的更多。Conmon-rs受益于用现代语言编写，并且更容易扩展。”

确保图像供应链

除了重写common之外，CRI-O项目还致力于其他地方的安全性，特别是Sigstore签名验证的集成。Sigstore是一个允许在软件组件上进行加密验证签名的项目，确保它们实际上起源于它们应该去的地方。Kubernetes发布自己的带有签名的官方容器映像，它支持安全策略，让管理员决定他们信任哪些经过验证的源。

CRI-O的维护人员Mrunal Patel解释说:“Sigstore是供应链安全的关键组成部分，正在结合Kubernetes上游对Sigstore验证工作的一流支持。”

通过在容器运行时直接评估签名策略，CRI-O和Kubernetes能够确保不受信任的映像不会被下载或运行，无论容器是如何调度的。在Kubernetes 1.28中，CRI-O甚至能够支持每个名称空间策略，以便用户可以对其云的不同租户具有不同的信任级别。计划在即将发布的1.29版本中全面支持该功能。

在容器运行时中要做的更多工作

除此之外，CRI-O团队还致力于容器的检查点恢复、新的指标接口和基于事件的更新。containerd正在编纂容器沙箱API，并创建一个长期支持(LTS)版本。两者都在添加特性和api来支持Kubernetes的新特性，比如动态资源分配(DRA)。

容器运行时仍在积极开发中。虽然成熟了，但它们还没有结束。

运行时特性对于Kubernetes云的创新和特性开发至关重要。

原文《Why Container Runtimes Still Matter》

by/ Sascha Grunert，Senior Software Engineer at Red Hat

Peter Hunt

Kubernetes 容器运行时 CRI-O

佚名

原创栏目