文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

聊聊Kata容器的I/O性能

2024-12-11 22:23

关注

[[329552]]

在参加了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容器有额外的主机要求:

如果没有这些先决条件,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(本节稍后将详细介绍)网络存储的路径:

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

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

  1. [global
  2. ; Parameters common to all test environments 
  3. ; Ensure that jobs run for a specified time limit, not I/O quantity 
  4. time_based=1 
  5. To model application load at greater scale, each test client will maintain 
  6. ; a number of concurrent I/Os. 
  7. ioengine=libaio 
  8. iodepth=8 
  9. ; Note: these two settings are mutually exclusive 
  10. ; (and may not apply for Windows test clients) 
  11. direct=1 
  12. buffered=0 
  13. Set a number of workers on this client 
  14. thread=0 
  15. numjobs=4 
  16. group_reporting=1 
  17. ; Each file for each job thread is this size 
  18. filesize=32g 
  19. size=32g 
  20. filename_format=$jobnum.dat 
  21. [fio-job] 
  22. ; FIO_RW is read, write, randread or randwrite 
  23. 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倍。当新功能可用时,我们将重复我们的测试以及分析。

原文: https://www.stackhpc.com/kata-io-1.html

 

来源:新钛云服内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯