Kubernetes：裸机vs虚拟机性能对比( 二 ) _Kubernetes

以下是虚拟机集群的 CPU 利用率测试结果:

文章插图
图片
图 4:虚拟机集群的 CPU 平均利用率为 86.81% 。

文章插图
图 5:虚拟机集群 CPU 每个核心的利用率信息。
在上面的图 4 中，红点是最大 CPU 核心负载，绿色代表所有核心的总 CPU 负载。在执行脚本期间，核心大部分时间以 100% 的利用率运行；平均值为 86.81% 。在 15:16 左右还有一个小的抢占时间峰值，这是当一个虚拟机由于等待物理 CPU 共享其计算资源而不执行的常见情况。
*最大 CPU 核心负载: 此指标通常指在 VM 内或跨 VM 主机上观察到的单个 CPU 内核的最高利用率百分比。它指示某个特定 CPU 内核被利用的程度。**所有内核的总 CPU 负载：此指标表示主机上所有可用 CPU 内核的总体 CPU 利用率。它考虑到所有 CPU 内核的组合使用情况，并提供有关主机上运行的所有 VM 使用的 CPU 容量的整体视图。
以下是物理机集群的 CPU 利用率测试结果:

文章插图
图 6:物理机集群的 CPU 平均利用率为 43.75% 。
平均 CPU 负载约为 43.75%，最大值为 62.57%，没有抢占时间。因此，就 CPU 性能而言，测试表明物理机集群的效率约为虚拟机集群的两倍。
RAM 延迟对于 RAM 测试，我们使用了 sysbench并通过 RAM 传输了 6400 GB 的数据。以下是执行的写操作和读操作的关键结果:

文章插图
图片
7:物理机集群的 RAM 速度比虚拟机集群快约三倍。
虚拟机集群的写入平均时间为 174.53 毫秒，而物理机集群进行相同操作的时间为 62.02 毫秒。读操作分别在 173.75 和 47.33 毫秒内完成。
这意味着物理机集群的 RAM 速度比虚拟机集群的 RAM 快约三倍。
存储 TPS 和延迟为了测试存储性能，我们运行了一个 PostgreSQL 集群，并使用pgbench 基准测试。我们测量了 TPS(每秒事务数)和延迟。我们还改变了工作负载，在相同的集群配置上测试了 8GB 和 75GB 数据库。
以下是实例的配置:

文章插图
图 8:存储测试的物理机和虚拟机集群配置。
存储 TPS 结果以下是 TPS 比较的平均结果:

文章插图
图片
图 9:物理机集群的存储 TPS 值约为虚拟机集群的两倍。
运行 8GB 数据库时，虚拟机集群显示 7 ， 359 TPS ，而物理机集群为 14，087 TPS 。75GB 数据库的性能结果分别为 4，636 和 12 ， 029 TPS 。
存储延迟结果以下是延迟测试的平均结果:

文章插图
图 10:物理机在存储延迟方面优于虚拟机。
运行 8GB 数据库时，虚拟机集群的延迟为 34.78 毫秒，而物理机集群的延迟为 18.17 毫秒。对于 75GB 数据库，延迟分别为 55.21 毫秒和 21.28 毫秒。
【Kubernetes：裸机vs虚拟机性能对比】运行8GB数据库时，物理机集群的存储性能约为虚拟机集群的两倍。对于75GB数据库，物理机集群相对于虚拟机集群的优势更加明显。
网络带宽和延迟为了测试网络性能，我们使用了netperf基准测试，最大报文段大小(MSS)范围从1到65，536 。MSS中的“段”元素是通过网络传输的一种IP数据包束。因此，MSS越大，传输的流量就越大。
我们在两个物理节点上部署了三个工作节点：Worker 1和Worker 2位于第一个节点上， Worker 3位于第二个节点上。然后我们测试了所有三个工作节点之间的网络性能。结果趋势在所有情况下都是相似的——物理机优于虚拟机。
最有趣的测试是工作节点之间物理距离最大的测试，即当流量在第一个和第二个物理节点之间流动时，Worker 1/Worker 2(在第一个节点上)和Worker 3(在第二个节点上)之间的距离。我们可以认为这是所有测试中最具挑战性的条件。图10和图11显示了此测试的结果。图10显示了MSS值为1、2、4和8时的网络带宽比较:

文章插图
图11:物理机集群的网络带宽是虚拟机集群的5倍。
虚拟机集群的带宽范围从 MSS=1 时的 862KB/sec 到 MSS=8 时的 6.52MB/sec，而物理机集群的带宽范围从 MSS 值为 4.17MB/sec 到 31MB/sec 。平均而言，物理机集群的带宽是虚拟机集群的 5 倍。