Kata容器的I/O性能

本文的所有分析是基于Kata容器1.6.2版本。

在参加了2019年伦敦OpenInfra Days的Kata容器研讨会之后，我们对它们的启动时间印象比较深刻，与Kubernetes集群中的普通runC容器相比仅稍慢一些。我们自然而然的对它们的磁盘I/O绑定性能以及它们是否也符性能要求感到好奇。在本文中，我们将探讨这个主题，以了解在I/O绑定性能和安全性都是关键需求的环境中使用此技术的利弊。

什么是Kata容器？

Kata容器是轻量级vm，旨在与Docker和Kubernetes等容器编排软件无缝集成。设想的一个用例是运行不受信任的工作负载，利用不与主机共享操作系统内核所获得的额外隔离。然而，在最近一次对虚拟机和容器的调查中，使用宿主机内核导致额外安全性这一毫无疑问的假设受到了挑战。Kata源于Intel Clear Containers和Hyper runV技术。gVisor的目标是通过过滤和重定向系统调用到单独的用户空间内核来解决类似的问题。因此，gVisor会受到运行时性能损失。关于gVisor的进一步讨论超出了本博客的范围。

为Kata配置Kubernetes

Kata容器符合OCI，这意味着支持外部运行时类的容器运行时接口（CRI）可以使用Kata来运行工作负载。这些CRI的例子目前包括CRI-O和containerd，它们都默认使用runC，但这可以替换为kata qemu运行。从Kubernetes 1.14+开始，RuntimeClass特性标志已升级到beta，因此默认启用。因此，设置相对简单。

目前Kata支持qemu和firecracker hypervisor后端，但对后者的支持被认为是初步的，特别是缺乏主机到客户的文件共享。这让我们将kata qemu作为当前的选项，其中virtio-9p提供了基本的共享文件系统功能，这对分析至关重要（测试路径是安装在主机上的网络文件系统）。

没有这些先决条件，Kata启动将无声地失败（我们很难学到了这一点）。

这个示例要点展示了如何在Minikube集群中将runC替换为Kata运行时。注意，在编写本文时，Kata容器有额外的主机要求：