共计 3547 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章给大家介绍如何分析 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 ModeScenario50%99%50%99%50%99%sequential readbare15812670241633781453247095runC20072506239139071506246022 Kata41124620126484646486409563806 random readbare9702342258033051493543884runC11552277250638561537842229 Kata547265861351731080109805314277 sequential writebare101117282592150233730258834runC101119902547148924308233832 Kata394848824102616014821190742 random writebare1269202336981161619722159285runC1286195739281179619374151756 Kata43585275456614254178055915343845
该表总结了与之前显示的数字相对应的 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 性能就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
