这篇文章给大家介绍如何分析Kata容器的I/O性能，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站建设、成都网站设计、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的虞城网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

下面的所有分析是基于Kata容器1.6.2版本，我们将探讨这个主题，以了解在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容器有额外的主机要求：

• Kata将只在配置为支持嵌套虚拟化的计算机上运行。

• Kata至少需要一个Westmere处理器架构。

如果没有这些先决条件，Kata的将悄无声息地失败(我们是从多次实践中得到的)。

为了进行此分析，部署了一个裸机Kubernetes集群，使用OpenStack Heat通过我们的appliances  playbooks配置机器，并使用Kubespray将它们配置为Kubernetes集群。Kubespray支持除Docker之外的其他容器运行时规范，例如CRI-O和  containerd，这是支持Kata运行时所必需的。

设计I/O性能测试方案

为了对Kata容器的I/O性能进行基准测试，我们在裸机和runC容器的情况下提出了等效的场景来进行比较。在所有情况下，我们都使用fio(3.1版)作为I/O基准测试工具，调用方式如下，其中$SCRATCH_DIR是安装在主机上的BeeGFS(本节稍后将详细介绍)网络存储的路径：

fio fio_jobfile.fio --fallocate=none --runtime=30 --directory=$SCRATCH_DIR --output-format=json+ --blocksize=65536 --output=65536.json

该fio_jobfile.fio上述引用的文件内容如下：

[global] ; Parameters common to all test environments ; Ensure that jobs run for a specified time limit, not I/O quantity time_based=1 ; To model application load at greater scale, each test client will maintain ; a number of concurrent I/Os. ioengine=libaio iodepth=8 ; Note: these two settings are mutually exclusive ; (and may not apply for Windows test clients) direct=1 buffered=0 ; Set a number of workers on this client thread=0 numjobs=4 group_reporting=1 ; Each file for each job thread is this size filesize=32g size=32g filename_format=$jobnum.dat [fio-job] ; FIO_RW is read, write, randread or randwrite rw=${FIO_RW}

Scenario	客户端数量	磁盘I/O模式
裸机	1	顺序读取
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容器进行比较，在所有情况下的开销都非常大。

Number of clients >		1		8		64
Mode	Scenario	50%	99%	50%	99%	50%	99%
sequential read	bare	1581	2670	2416	3378	14532	47095
runC	2007	2506	2391	3907	15062	46022
Kata	4112	4620	12648	46464	86409	563806
random read	bare	970	2342	2580	3305	14935	43884
runC	1155	2277	2506	3856	15378	42229
Kata	5472	6586	13517	31080	109805	314277
sequential write	bare	1011	1728	2592	15023	3730	258834
runC	1011	1990	2547	14892	4308	233832
Kata	3948	4882	4102	6160	14821	190742
random write	bare	1269	2023	3698	11616	19722	159285
runC	1286	1957	3928	11796	19374	151756
Kata	4358	5275	4566	14254	1780559	15343845

该表总结了与之前显示的数字相对应的50%和99%的提交延迟(以μs为单位)。*

展望未来

在这种I/O密集型方案中，Kata容器尚未达到传统容器的性能。

从结果可以明显看出，在裸机、runC容器和Kata容器之间进行选择时，需要权衡取舍。尽管runC容器为大多数用例提供了更完善的考量，但它们仍然使主机内核易于受到系统调用接口作为攻击面的利用。Kata容器提供了硬件支持的隔离，但是目前存在巨大的性能开销，尤其是对于磁盘I/O绑定操作。

Kata的发展路线图和发展速度拥有坚实的基础以及乐观的前景。Kata团队已经意识到使用virtio-9p作为存储驱动程序在主机和来宾VM之间共享路径的性能缺陷。

Kata版本1.7(将于2019年5月15日发布)预计将附带virtio  fs的实验支持，该版本有望改善I/O性能问题。初步结果令人鼓舞，其他已发布的基准测试报告显示，virtio  fs驱动程序的磁盘I/O带宽比virtio-9p提高了2到8倍。当新功能可用时，我们将重复我们的测试以及分析。

关于如何分析Kata容器的I/O性能就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

当前题目：如何分析Kata容器的I/O性能
转载注明：http://abwzjs.com/article/ppjpsj.html