Kata Containers 1.5正式发布，支持 Firecracker 和 s390x 架构

最新推荐文章于 2025-07-05 16:07:21 发布

weixin_33943836

最新推荐文章于 2025-07-05 16:07:21 发布

阅读量381

点赞数

CC 4.0 BY-SA版权

文章标签：运维

本文链接：https://blog.youkuaiyun.com/weixin_33943836/article/details/89148057

Kata Containers 1.5 版本引入了 Firecracker hypervisor 支持，增强了安全性与效率，同时增加了对 IBM Z-Series 的 s390x 架构支持。此外，该版本还提供了与 containerd 的集成，简化了运行时的管理和配置。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这是Kata迄今为止最令人兴奋的版本，其中包括对Firecracker hypervisor、s390x架构的支持，并提供了与containerd项目集成的方法。

Firecracker支持

因为知道在功能、资源占用和安全性之间总是存在权衡，Kata Containers项目在设计时就考虑到要支持多个hypervisor。在1.4版本中增加了NEMU，比QEMU更加轻量级。11月底，AWS宣布推出他们的Firecracker hypervisor。Firecracker GitHub主页上写道：“Firecracker采用了简约设计，去除了不必要的设备和面向客户的功能，以减少每个微虚拟机的内存占用和攻击表面积。这样可以提高安全性，缩短启动时间，并提高硬件利用率。”

这对于Kata社区来说是一件令人兴奋的事情，因为它解决了最终用户对简单使用场景下的最小hypervisor解决方案的需求。

Kata Containers1.5版本引入了对Firecracker hypervisor的支持，这是对现有QEMU的补充。考虑到Firecracker可用功能的权衡，我们希望人们将Firecracker用于功能受限的工作负载，并在更高级的工作负载上使用最小的QEMU（例如，如果需要设备分配，可以使用QEMU）。

例如，在单个集群中使用runc、kata-qemu（kata-runtime的QEMU配置）和kata-fc（kata-runtime的Firecracker配置）是很典型的，如下图所示：

$\"\"$

要实现这样的配置，必须将集群配置为使用CRI-O或containerd，以及Kubernetes的runtimeClass功能。containerd正在开发当中，现在只有CRI-O支持devicemapper存储驱动器。通过在Kubernetes和CRI-O中配置runtimeClass，最终用户可以在每个工作负载上选择他们喜欢的隔离类型。使用CRI-O、Kata Containers和Firecracker VMM的设置可以在这个截屏视频中看到：https://asciinema.org/a/219790。

为了帮助开发人员快速开始在Kubernetes中使用Kata + runtimeClass，这里提供了一个沙盒https://github.com/clearlinux/cloud-native-setup/blob/master/clr-k8s-examples/。

Firecracker hypervisor采用了极简设计。因此，在使用Kata + Firecracker时，在Kubernetes的功能方面总是会存在差距，导致无法动态调整pod的内存和CPU定义。同样，由于Firecracker只支持基于块的存储驱动器和卷，现在需要用到devicemapper。这在Kubernetes + CRI-O和Docker 18.06版本中可用。开发人员正在添加更多的存储驱动器选项。有关Kata + Firecracker的当前限制，请参阅https://github.com/kata-containers/documentation/issues/351。

我们很高兴能与Firecracker团队合作，并继续改进对Firecracker VMM的支持，以及与Kubernetes的集成。

s390x架构支持

在来自IBM的社区成员的帮助下，Kata Containers1.5版本增加了对IBM Z-Series的支持。

containerd集成

去年六月，Michael Crosby开始了一个向containerd添加填充API的讨论，以便更好地支持基于VM的运行时，比如Kata Containers。Kata Containers1.5版本提供了可以满足该填充API的初始实现，极大简化了Kata Containers与containerd的集成方式，如下所示：

$\"\"$

除了明显减少了组件之外，API还为Kata Containers带来了更好的接口，比如可以直接从Kata运行时访问容器级别的统计信息，这在之前的命令行界面中是不可能的。同样，因为存储器挂载是由containerd-shim来完成的，所以实现基于块的containerd-shim-kata-v2快照程序支持应该会更加简单。

Kata社区一直非常积极地使用CRI-O项目来定义和利用类似的接口，不过这项工作仍然在进行中，目标是在1.6版本中发布。