Kubernetes 裸机vs虚构机性能对比

本文对Kubernetes集群在虚构机和裸机上在CPU、内存、存储和网络性能方面的体现启动了详细的比拟和剖析。

许多人以为部署在物理机上的 Kubernetes 集群性能比部署在虚构机上的要好，但直到如今还没有任何证据撑持这一假定。在 Gcore，咱们只向客户提供有充沛证据撑持的消息，所以咱们选择自己测试一下K8S部署在物理机和虚构机上的性能能否真的有差异，假设有的话差异有多大。我将分享咱们外部测试的结果。

我无心不探讨物理机节点与虚构节点的其余方面的竞争，比如老本效益或基础设备控制水平。这曾经超出了本文的范畴，本文仅专一于性能比拟。

当您在虚构机上部署 Kubernetes 集群时，与物理机相比，您会获取额外的基础架构层——一个虚构机治理程序（hypervisor）和一个虚构机操作系统。

图 1:物理机和虚构机架构的区别。

这些层会消耗物理 CPU 和 RAM 来运转，从而占用了一些计算才干。虚构化也会影响网络和存储性能：虚构网络和存储比物理网络和存储慢。

相比之下，当您在物理主机上部署 Kubernetes 集群时，您不会有任何额外的基础架构层和虚构化。主机的物理资源齐全公用于您的上班负载，并且容器化运行程序间接访问这些资源。

咱们如何比拟虚构机和物理机 Kubernetes 性能

为了片面了解虚构机和物理机集群性能的比拟，咱们测量了以下目的:

为了试验的污浊性，一切测试运行程序都是容器化的，并部署在正在比拟的上班节点上。

咱们的测试条件

为了测试，咱们经常使用了在 Gcore 托管 Kubernetes上运转的 K8s 集群。然而，结果也实用于原生 Kubernetes，由于托管 Kubernetes 不会参与上班节点性能的额外开支。

为了使上班负载坚持相反的条件，咱们选用了相似性能的虚构机和物理机上班节点。以下是这样的对比性能的一个示例:

测试结果摘要

在测试中，咱们比拟了两个 Kubernetes 集群，一个部署在虚构机(VM)上，另一个部署在物理机上。它们的性能相似。作为测试上班负载，咱们运转了:

下表总结了最关键的测试结果:

显然，在一切状况下，物理机集群的效率都更高。

咱们将在本文前面详细审核结果，并确定更好的物理机性能对您的上班负载象征着什么。然而首先，让咱们便捷回忆一下在虚构机上部署的 Kubernetes 集群与物理机上的基本区别。

详细的测试结果

如今让咱们详细看一下物理机和虚构机集群在每个评价规范方面的性能。

CPU 速度和应用率

关于 CPU 速度比拟，咱们经常使用了 Alex Dedyura 的CPU 基准测试。这是一个计算 π 到 10，000 位小数的脚本。计算时期以秒为单位，在 10 次测试中取平均值，作为测试结果。计算 π 是一个 CPU 密集型义务，因此基准测试可以清楚地标明所测试 CPU 的性能。

以下是 CPU 速度比拟结果:

图 3:物理机集群的 CPU 速度比虚构机集群的 CPU 快两倍多。

虚构机集群的 10 次重试平均时期为 47.07 秒;关于物理机集群，它是 21.46 秒。因此，物理机集群速度快了两倍多。

以下是虚构机集群的 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 传输了 6 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 毫秒。

运转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 倍。

图 12 显示了经常使用相反 MSS 值的网络提前比拟:

图 12:物理机集群的网络提前最高可降落虚构机集群的 6 倍。

正如咱们所见，在 MSS=8 时测量，虚构机集群的提前约为 145 微秒，而物理机的提前为 24.5 微秒，高出约 6 倍。此外，关于物理机集群，随着 MSS 的参与，提前的增长速度更慢。

关于一切测试，请留意，咱们报告的是集群网络外部的网络性能比拟。咱们测量了一个网络外部节点之间的带宽和提前，位于一个位置。假设咱们经常使用不同位置的节点，这将参与互联网提前，而互联网提前是不稳固的，并且或许因提供商而异。咱们在分解条件下坚持污浊;它们或许不可在实践环境中复制。然而，可以预期广泛趋向得以重现。

物理机性能长处的意义

与虚构机相比，更好的物理机性能提供了两个便捷但关键的长处:

咱们的测试结果证明了一个知识，即对须要高性能和低提前的计算密集型上班负载(例如数据库、AI/ML 模型和其余类型的实时运行程序)来说，物理机确实更好。虚构机适宜对计算和提前不敏感的上班负载，例如 Web 主机、网站和开发环境。假设高性能和低提前对您的用户至关关键，并间接影响您的业务，您应该思考在 Kubernetes 集群中经常使用物理机。

论断

咱们的测试证明了物理机上班节点优于虚构机上班节点的假定。咱们还发生了关于物理机上班节点确实优于多少的详细数据，即:

假设您想在物理机上班节点上试用 Kubernetes，请检查Gcore 的托管 Kubernetes。咱们提供了几种类型的上班节点性能，包含用于减速 AI/ML 上班负载的 NVIDIA GPU。

我要感谢我在 Gcore 的共事启动测试并协助撰写本文: Sergey Kalinin、Sergey Mikhalev 和 Andrei Novoselov。