本文所有分析均基于Kata容器1.6.2版本。在参加了2019年伦敦OpenInfraDays的KataContainers研讨会后，我们对它们的启动时间印象深刻，与Kubernetes集群中的普通runC容器相比，它们的启动时间仅略慢一些。我们自然很好奇它们的磁盘I/O性能以及它们是否也达到了性能要求。在本文中，我们探讨了这个主题，以了解在I/O绑定性能和安全性是关键要求的环境中使用此技术的优缺点。什么是Kata容器？Kata容器是轻量级虚拟机，旨在与Docker和Kubernetes等容器编排软件无缝集成。设想的一个用例是运行不受信任的工作负载，利用通过不与主机共享操作系统内核而获得的额外隔离。然而，在最近对虚拟机和容器的调查中，使用主机内核会带来额外安全性这一毋庸置疑的假设受到了挑战。Kata源自IntelClearContainers和HyperrunV技术。gVisor旨在通过过滤系统调用并将其重定向到单独的用户空间内核来解决类似的问题。因此，gVisor会遭受运行时性能损失。gVisor的进一步讨论超出了本博客的范围。为Kata配置KubernetesKata容器符合OCI，这意味着支持外部运行时类的容器运行时接口(CRI)可以使用Kata来运行工作负载。这些CRI的示例目前包括CRI-O和containerd，它们都默认使用runC，但这可以用kataqemurun代替。从Kubernetes1.14+开始，RuntimeClass特性标志已经升级到beta，因此默认启用。因此，设置相对简单。目前Kata支持qemu和firecrackerhypervisor后端，但对后者的支持被认为是初步的，特别是缺乏主机到客户的文件共享。这给我们留下了kataqemu作为当前选项，其中virtio-9p提供基本的共享文件系统功能，这对分析至关重要（测试路径是安装在主机上的网络文件系统）。没有这些先决条件，Kata启动将悄无声息地失败（我们从惨痛的教训中学到了这一点）。这个示例要点展示了如何在Minikube集群中用Kata运行时替换runC。请注意，在撰写本文时，Kata容器有额外的主机要求：Kata只能在配置为支持嵌套虚拟化的机器上运行。Kata至少需要一个Westmere处理器架构。如果没有这些先决条件，套路就会悄无声息地失败（我们已经从多次实践中学到了这一点）。对于此分析，部署了裸机Kubernetes集群，使用OpenStackHeat通过我们的设备playbook配置机器，并使用Kubespray将它们配置为Kubernetes集群。Kubespray支持除Docker之外的其他容器运行时规范，例如CRI-O和containerd，这是支持Kata运行时所必需的。设计I/O性能测试方案为了对Kata容器的I/O性能进行基准测试，我们提出了裸机和runC容器情况下的等效场景进行比较。在所有情况下，我们都使用fio（3.1版）作为I/O基准测试工具，调用方式如下，其中$SCRATCH_DIR是安装在主机上的BeeGFS（本节稍后详述）网络存储的路径：fiofio_jobfile.fio--fallocate=none--runtime=30--directory=$SCRATCH_DIR--output-format=json+--blocksize=65536--output=65536.json上面引用的fio_jobfile.fio内容如下：[global];Parameterscommontoalltestenvironments;Ensurethatjobsrunforaspecifiedtimelimit,notI/Oquantitytime_based=1;Tomodelapplicationloadatgreaterscale,eachtestclientwillmaintain;anumberofconcurrentI/Os.ioengine=libaioiodepth=8;Note:thesetwosettingsaremutuallyexclusive;(andmaynotapplyforWindowstestclients)direct=1buffered=0;Setanumberofworkersonthisclientthread=0numjobs=4group_reporting=1;Eachfileforeachjobthreadisthissizefilesize=32gsize=32gfilename_format=$jobnum.dat[fio-job];FIO_RWisread,write,randreadorrandwriterw=${FIO_RW}clients场景数磁盘I/O模式baremetal1sequential读取runC容器8随机读取Kata容器64次顺序写入随机写入I/O性能研究探索的参数空间涵盖了36个场景、客户端数量和磁盘I/O模式的综合结果磁盘I/O吞吐量在这些结果中，我们总计绘制了所有客户端的带宽，显示了单个客户端可实现的纵向扩展带宽和多个客户端可实现的横向扩展吞吐量。裸机、runC和Kata之间的磁盘I/O带宽比较。在所有情况下，runC容器实现的带宽都略低于裸机。然而，Kata容器的性能通常要差得多，在有64个客户端时获得裸机读取带宽的15%左右，随机写入带宽的百分比要小得多。唯一的例外是具有64个客户端的顺序写入案例，其中Kata容器优于裸机解决方案约25%。提交延迟累积分布函数(CDF)在对延迟敏感的工作负载中，I/O延迟可能占主导地位。I/O操作提交延迟以对数标度绘制，以适应非常广泛的数据点。分别针对裸机、1、8和64个客户端提交runC和Kata容器环境之间的延迟CDF比较。与将它们作为runC容器运行相比，在裸机中运行fio作业之间存在细微差别。然而，将裸机与Kata容器进行比较，在所有情况下开销都很大。Numberofclients>1864ModeScenario50%99%50%99%50%99%sequentialReadBare15812670241633781453247095Runc20072506239139071506246022Kata41124620126484646486409563806RandomReadBare9702342258033051493543884运行C11552277250638561537842229Kata547265861351731080109805314277Section2592150233730258834Runc10111990254714892430848824102616014821190742RandomWriteBare1269202336981161619722159285Runc1286195739281179619374151756Kata43585275456614254178055915343845此表总结了前面显示的数字对应的50%和99%提交延迟（以μs为单位）*展望未来在这种I/O密集型场景中，Kata容器尚未达到以下性能传统容器。从结果中可以明显看出，在裸机、runC容器和Kata容器之间进行选择时需要权衡取舍。尽管runC容器为大多数用例提供了更复杂的考虑，但它们仍然使主机内核容易受到利用系统调用接口作为攻击面的攻击。Kata容器提供硬件支持的隔离，但目前存在巨大的性能开销，尤其是对于磁盘I/O绑定操作。Kata的发展路线图和发展步伐有着坚实的基础和乐观的前景。Kata团队已经意识到使用virtio-9p作为存储驱动程序在主机和来宾VM之间共享路径的性能缺陷。Kata1.7版（将于2019年5月15日发布）预计将附带对virtiofs的实验性支持，这有望改善I/O性能问题。初步结果令人鼓舞，其他已发布的基准测试报告显示，与virtio-9p相比，virtiofs驱动程序的磁盘I/O带宽提高了2到8倍。当新功能可用时，我们将重复我们的测试和分析。原文：https://www.stackhpc.com/kata-io-1.html
