本文對Kubernetes集群在虛擬機和裸機上在CPU、內(nèi)存、存儲和網(wǎng)絡性能方面的表現(xiàn)進行了詳細的比較和分析。

譯自Does Kubernetes Really Perform Better on Bare Metal vs. VMs?，作者 Oleg Zinovyev 是 Gcore 的技術(shù)內(nèi)容編輯，Gcore 是一家全球云邊緣提供商。他在與云原生技術(shù)(包括 Kubernetes)相關的各種公司有超過 5 年的撰稿經(jīng)驗。在轉(zhuǎn)向?qū)懽髦埃琌leg 曾擔任過......

許多人認為部署在物理機上的 Kubernetes 集群性能比部署在虛擬機上的要好，但直到現(xiàn)在還沒有任何證據(jù)支撐這一假設。在 Gcore，我們只向客戶提供有充分證據(jù)支撐的信息，所以我們決定自己測試一下 K8S 部署在物理機和虛擬機上的性能是否真的有差異，如果有的話差異有多大。我將分享我們內(nèi)部測試的結(jié)果。

我有意不討論物理機節(jié)點與虛擬節(jié)點的其他方面的競爭，比如成本效益或基礎設施控制水平。這已經(jīng)超出了本文的范圍，本文僅專注于性能比較。

當您在虛擬機上部署 Kubernetes 集群時，與物理機相比，您會得到額外的基礎架構(gòu)層——一個虛擬機管理程序（hypervisor）和一個虛擬機操作系統(tǒng)。

圖 1:物理機和虛擬機架構(gòu)的區(qū)別。

這些層會消耗物理 CPU 和 RAM 來運行，從而占用了一些計算能力。虛擬化也會影響網(wǎng)絡和存儲性能：虛擬網(wǎng)絡和存儲比物理網(wǎng)絡和存儲慢。

相比之下，當您在物理服務器上部署 Kubernetes 集群時，您不會有任何額外的基礎架構(gòu)層和虛擬化。服務器的物理資源完全專用于您的工作負載，并且容器化應用程序直接訪問這些資源。

我們?nèi)绾伪容^虛擬機和物理機 Kubernetes 性能

為了全面了解虛擬機和物理機集群性能的比較，我們測量了以下指標:

• CPU: 速度和利用率
• RAM: 延遲
• 存儲: 每秒事務數(shù)(TPS)和延遲
• 網(wǎng)絡: 帶寬和延遲

為了實驗的純凈性，所有測試應用程序都是容器化的，并部署在正在比較的工作節(jié)點上。

我們的測試條件

為了測試，我們使用了在 Gcore 托管 Kuberneteshttps://gcore.com/cloud/managed-kubernetes 上運行的 K8s 集群。但是，結(jié)果也適用于原生 Kubernetes，因為托管 Kubernetes 不會增加工作節(jié)點性能的額外開銷。

為了使工作負載保持相同的條件，我們選擇了類似配置的虛擬機和物理機工作節(jié)點。以下是這樣的對比配置的一個示例:

• 物理機工作節(jié)點: 1x Intel Xeon E-2388 8C/16T 3.2 GHz / 64 GB / Ubuntu 22.04
• 虛擬機工作節(jié)點: 16 vCPU / 64 GiB 內(nèi)存 / Ubuntu 22.04

測試結(jié)果摘要

在測試中，我們比較了兩個 Kubernetes 集群，一個部署在虛擬機(VM)上，另一個部署在物理機上。它們的配置相似。作為測試工作負載，我們運行了:

• CPU基準測試用于 CPU 測試
• Sysbench 用于 RAM 測試
• Pgbench 用于存儲測試
• Netperf 用于網(wǎng)絡測試

下表總結(jié)了最重要的測試結(jié)果:

圖 2:測試結(jié)果摘要。

顯然，在所有情況下，物理機集群的效率都更高。

我們將在本文后面詳細檢查結(jié)果，并確定更好的物理機性能對您的工作負載意味著什么。但是首先，讓我們簡單回顧一下在虛擬機上部署的 Kubernetes 集群與物理機上的基本區(qū)別。

詳細的測試結(jié)果

現(xiàn)在讓我們詳細看一下物理機和虛擬機集群在每個評估標準方面的性能。

CPU 速度和利用率

對于 CPU 速度比較，我們使用了 Alex Dedyura 的CPU 基準測試。這是一個計算 π 到 10，000 位小數(shù)的腳本。計算時間以秒為單位，在 10 次測試中取平均值，作為測試結(jié)果。計算 π 是一個 CPU 密集型任務，因此基準測試可以清楚地表明所測試 CPU 的性能。

以下是 CPU 速度比較結(jié)果:

圖 3:物理機集群的 CPU 速度比虛擬機集群的 CPU 快兩倍多。

虛擬機集群的 10 次重試平均時間為 47.07 秒;對于物理機集群，它是 21.46 秒。因此，物理機集群速度快了兩倍多。

以下是虛擬機集群的 CPU 利用率測試結(jié)果:

圖片

圖 4:虛擬機集群的 CPU 平均利用率為 86.81%。

圖 5:虛擬機集群 CPU 每個核心的利用率信息。

在上面的圖 4 中，紅點是最大 CPU 核心負載，綠色代表所有核心的總 CPU 負載。在執(zhí)行腳本期間，核心大部分時間以 100% 的利用率運行；平均值為 86.81%。在 15:16 左右還有一個小的搶占時間峰值，這是當一個虛擬機由于等待物理 CPU 共享其計算資源而不執(zhí)行的常見情況。

*最大 CPU 核心負載: 此指標通常指在 VM 內(nèi)或跨 VM 主機上觀察到的單個 CPU 內(nèi)核的最高利用率百分比。它指示某個特定 CPU 內(nèi)核被利用的程度。**所有內(nèi)核的總 CPU 負載：此指標表示主機上所有可用 CPU 內(nèi)核的總體 CPU 利用率。它考慮到所有 CPU 內(nèi)核的組合使用情況，并提供有關主機上運行的所有 VM 使用的 CPU 容量的整體視圖。

以下是物理機集群的 CPU 利用率測試結(jié)果:

圖 6:物理機集群的 CPU 平均利用率為 43.75%。

平均 CPU 負載約為 43.75%，最大值為 62.57%，沒有搶占時間。因此，就 CPU 性能而言，測試表明物理機集群的效率約為虛擬機集群的兩倍。

RAM 延遲

對于 RAM 測試，我們使用了 sysbench并通過 RAM 傳輸了 6400 GB 的數(shù)據(jù)。以下是執(zhí)行的寫操作和讀操作的關鍵結(jié)果:

圖片

 7:物理機集群的 RAM 速度比虛擬機集群快約三倍。

虛擬機集群的寫入平均時間為 174.53 毫秒，而物理機集群進行相同操作的時間為 62.02 毫秒。讀操作分別在 173.75 和 47.33 毫秒內(nèi)完成。

這意味著物理機集群的 RAM 速度比虛擬機集群的 RAM 快約三倍。

存儲 TPS 和延遲

為了測試存儲性能，我們運行了一個 PostgreSQL 集群，并使用pgbench 基準測試。我們測量了 TPS(每秒事務數(shù))和延遲。我們還改變了工作負載，在相同的集群配置上測試了 8GB 和 75GB 數(shù)據(jù)庫。

以下是實例的配置:

圖 8:存儲測試的物理機和虛擬機集群配置。

存儲 TPS 結(jié)果

以下是 TPS 比較的平均結(jié)果:

圖片

圖 9:物理機集群的存儲 TPS 值約為虛擬機集群的兩倍。

運行 8GB 數(shù)據(jù)庫時，虛擬機集群顯示 7，359 TPS，而物理機集群為 14，087 TPS。75GB 數(shù)據(jù)庫的性能結(jié)果分別為 4，636 和 12，029 TPS。

存儲延遲結(jié)果

以下是延遲測試的平均結(jié)果:

圖 10:物理機在存儲延遲方面優(yōu)于虛擬機。

運行 8GB 數(shù)據(jù)庫時，虛擬機集群的延遲為 34.78 毫秒，而物理機集群的延遲為 18.17 毫秒。對于 75GB 數(shù)據(jù)庫，延遲分別為 55.21 毫秒和 21.28 毫秒。

運行8GB數(shù)據(jù)庫時，物理機集群的存儲性能約為虛擬機集群的兩倍。對于75GB數(shù)據(jù)庫，物理機集群相對于虛擬機集群的優(yōu)勢更加明顯。

網(wǎng)絡帶寬和延遲

為了測試網(wǎng)絡性能，我們使用了netperf基準測試，最大報文段大小(MSS)范圍從1到65，536。MSS中的“段”元素是通過網(wǎng)絡傳輸?shù)囊环NIP數(shù)據(jù)包束。因此，MSS越大，傳輸?shù)牧髁烤驮酱蟆?/p>

我們在兩個物理節(jié)點上部署了三個工作節(jié)點：Worker 1和Worker 2位于第一個節(jié)點上，Worker 3位于第二個節(jié)點上。然后我們測試了所有三個工作節(jié)點之間的網(wǎng)絡性能。結(jié)果趨勢在所有情況下都是相似的——物理機優(yōu)于虛擬機。

最有趣的測試是工作節(jié)點之間物理距離最大的測試，即當流量在第一個和第二個物理節(jié)點之間流動時，Worker 1/Worker 2(在第一個節(jié)點上)和Worker 3(在第二個節(jié)點上)之間的距離。我們可以認為這是所有測試中最具挑戰(zhàn)性的條件。圖10和圖11顯示了此測試的結(jié)果。圖10顯示了MSS值為1、2、4和8時的網(wǎng)絡帶寬比較:

圖11:物理機集群的網(wǎng)絡帶寬是虛擬機集群的5倍。

虛擬機集群的帶寬范圍從 MSS=1 時的 862KB/sec 到 MSS=8 時的 6.52MB/sec，而物理機集群的帶寬范圍從 MSS 值為 4.17MB/sec 到 31MB/sec。平均而言，物理機集群的帶寬是虛擬機集群的 5 倍。

圖 12 顯示了使用相同 MSS 值的網(wǎng)絡延遲比較:

圖 12:物理機集群的網(wǎng)絡延遲最高可降低虛擬機集群的 6 倍。

正如我們所見，在 MSS=8 時測量，虛擬機集群的延遲約為 145 微秒，而物理機的延遲為 24.5 微秒，高出約 6 倍。此外，對于物理機集群，隨著 MSS 的增加，延遲的增長速度更慢。

對于所有測試，請注意，我們報告的是集群網(wǎng)絡內(nèi)部的網(wǎng)絡性能比較。我們測量了一個網(wǎng)絡內(nèi)部節(jié)點之間的帶寬和延遲，位于一個位置。如果我們使用不同位置的節(jié)點，這將增加互聯(lián)網(wǎng)延遲，而互聯(lián)網(wǎng)延遲是不穩(wěn)定的，并且可能因提供商而異。我們在合成條件下保持純凈;它們可能無法在實際環(huán)境中復制。但是，可以預期普遍趨勢得以重現(xiàn)。

物理機性能優(yōu)勢的意義

與虛擬機相比，更好的物理機性能提供了兩個簡單但關鍵的優(yōu)勢:

• 部署在物理機工作節(jié)點上的應用程序運行和響應速度比部署在虛擬機上的快。
• 因此，當您選擇物理機時，客戶使用您的產(chǎn)品體驗會更好。

我們的測試結(jié)果證明了一個常識，即對需要高性能和低延遲的計算密集型工作負載(例如數(shù)據(jù)庫、AI/ML 模型和其他類型的實時應用程序)來說，物理機確實更好。虛擬機適合對計算和延遲不敏感的工作負載，例如 Web 服務器、網(wǎng)站和開發(fā)環(huán)境。如果高性能和低延遲對您的用戶至關重要，并直接影響您的業(yè)務，您應該考慮在 Kubernetes 集群中使用物理機。

結(jié)論

我們的測試證實了物理機工作節(jié)點優(yōu)于虛擬機工作節(jié)點的假設。我們還產(chǎn)生了關于物理機工作節(jié)點確實優(yōu)于多少的具體數(shù)據(jù)，即:

• CPU 速度和利用率提高兩倍
• RAM 延遲降低三倍
• 存儲性能提高兩倍以上
• 網(wǎng)絡延遲降低五倍以上

如果您想在物理機工作節(jié)點上試用 Kubernetes，請查看Gcore 的托管 Kubernetes。我們提供了幾種類型的工作節(jié)點配置，包括用于加速 AI/ML 工作負載的 NVIDIA GPU。

我要感謝我在 Gcore 的同事進行測試并幫助撰寫本文: Sergey Kalinin、Sergey Mikhalev 和 Andrei Novoselov。