亚马逊AWS官方博客
Kata Containers 1.5 版发布并提供 Firecracker 支持
Firecracker 在 re:Invent 2018 大会上宣布推出。它提供虚拟机的安全性和隔离性，同时兼具启动时间短、容器密度高的特点。它提供原生云管理程序，从而安全高效地运行容器。在本博文中，来自 Kata Containers 项目的 Eric Ernst 解释了 Firecracker 如何满足他们社区对至简管理程序的需求，以及它现在如何与 Kata Containers 轻松集成。
– Arun
Kata Containers 是一个开源项目，全球社区携手构建轻型虚拟机的标准实现，这种虚拟机的感觉和性能类似于容器，但通过将虚拟机作为第二层防护手段，提供更强的工作负载隔离功能。
虽然 Kata Containers 项目最初是基于 QEMU 的，但它的设计从一开始就以支持多种管理程序解决方案为出发点。
十一月底，Amazon Web Services 宣布它的 Firecracker 管理程序开源化。Firecracker GitHub readme 文件写道：“Firecracker 采用极简主义设计。它不包含不必要的设备和面对来宾的功能，从而减少内存占用，吸引每个 microVM 的表面积。这改善了安全性，减少了启动时间，提高了硬件利用率。”
这令 Kata 社区极为振奋，因为它解决了 Kata 终端用户对用于简单使用案例的更简洁管理程序解决方案的需求。Kata 社区立即开始使用 Firecracker，并获得了与 AWS 的 Firecracker 团队合作的绝佳机会。
最后 @katacontainers 和 @AWSOpen #firecracker 开发人员之间进行了非常热烈的讨论。令人振奋的协作机会很多，同时大家也积极继续探索其他的协作机会。pic.twitter.com/hUpnWhzxSu
— Noah Meyerhans (@nmeyerhans) 2018 年 12 月 11 日
本周我们发布了 Kata Containers 1.5，它推出了对Firecracker 管理程序的初步支持。这是对项目现有的 QEMU 支持的补充。在权衡 Firecracker 中可用的功能后，我们预计 Firecracker 将会用于功能受限的工作负载，并在处理更高级的工作负载时将会使用极简的 QEMU（例如，如果需要分配设备，则应使用 QEMU）。
我们预测在单个 Kubernetes 集群中使用 runc、Kata + QEMU 和 Kata + Firecracker 将变得非常普遍，如下图所示：
如要实现此配置，集群必须配置为使用 CRI-O 或 containerd，并且必须配置为使用 Kubernetes 的 runtimeClass 功能。在 Kubernetes 以及 CRI-O/containerd 中配置 runtimeClass 后，终端用户可以在工作负载前选择需要的隔离类型。在此例中，注册了两个 runtimeClass：kata-qemu 和 kata-fc。 选择基于 Firecracker 的隔离非常简单，只需使用如下 YAML 代码段来为现有的工作负载安装补丁即可：
spec:
template:
spec:
runtimeClassName: kata-fc如要使用 QEMU，应将 runtimeClassName 标签修改为 kata-qemu。
此设置使用了 CRI-O、Kata Containers 和 Firecracker VMM，设置示意图参见截屏分享短片在 CRIO+K8S 中使用 QEMU 和 Firecracker 配置的 Kata。
runtimeClass 在 Kubernetes 1.13 之前一直是一个内部测试功能，因此直到今天，禁用 feature gate 并建立恰当配置了 runtimeClass 的集群仍然较为困难。为便于快速开始使用 Kata、Firecracker, 和 runtimeClass，我们提供了一个 vagrant 映像以及有关如何设置和使用配置集群的说明。
如前面所提到，Firecracker 管理程序采用极简主义设计。因此在使用 Kata + Firecracker 时，始终都会面临 Kubernetes 功能缺口的问题。一个缺口是无法动态调节 pod 的内存和 CPU 定义。同样，由于 Firecracker 仅支持基于块的存储驱动程序和卷，现在要求使用设备映射程序。 这已在 Kubernetes + CRI-O 和 Docker 版本 18.06 中提供。目前正在努力研究增加更多的存储驱动程序选项。有关 Kata + Firecracker 当前限制的详情，请参阅此 GitHub 问题。
对于 1.5 版，Firecracker 包含在我们的 kata containers 静态发布包中，它包含了运行 Kata + Firecracker 所需的所有配置和二进制代码。 我们计划在近期的发布包中提供此功能。如要使用 Docker CLI 对此进行测试，请参阅入门指南，它包含了有关如何使用 Firecracker 或 QEMU 启动工作负载以增加隔离能力的详细信息。
从 1.5 版以后，我们计划推出大量的增强以改善对 Firecracker 的支持：
- 改进对基于块的存储驱动程序的支持
- 使用 Firecracker Jailer 提供更强大的主机隔离能力。
- 有关启动时间的优化
- 推出参考授权控制器，以帮助在使用 Kata Containers 时选择恰当的管理程序隔离
我们很高兴能与 Firecracker 团队共事，继续完善我们对 Firecracker VMM 的支持以及促进它与 Kubernetes 的集成。
Kata Containers 社区由 OpenStack Foundation (OSF) 管理，该基金会通过托管开源项目和实践社区，支持全球开放基础设施的发展和采用。Kata 的开源社区依据 Apache 2 许可证编制代码。任何人都可加入和贡献代码、文档和使用案例。
参加 2019 年 4 月 29 至 5 月 1 日在美国丹佛举行的开放基础设施峰会，与 Kata 团队见面和协作，我们在该此峰会上将有多次演讲，鞋歪还将举办协作工作会议，讨论完善项目的路线图、计划以及亲自动手破解等活动。此外，您可以探索 GitHub 上的 Kata 和 KataContainers.io，并且还可以通过下列渠道参与社区：
Eric Ernst
Eric Ernst 是 Kata Containers 架构委员会的成员，现为英特尔公司开源技术中心高级软件工程师，常驻俄勒冈州波特兰市。Eric 最近几年一直在从事嵌入式固件和 Linux 内核研究工作。Eric 在英特尔担任容器运行时开发人员和技术负责人两年，非常高兴能加入 Kata Containers 项目的架构委员会。
本博文中的内容和意见属于第三方作者，AWS 不对本博文的内容或准确性负责。