本文對Kube.NETes集群在虛擬機和裸機上在CPU、內(nèi)存、存儲和網(wǎng)絡(luò)性能方面的表現(xiàn)進(jìn)行了詳細(xì)的比較和分析。
譯自Does Kubernetes Really Perform Better on Bare Metal vs. VMs?，作者 Oleg Zinovyev 是 Gcore 的技術(shù)內(nèi)容編輯，Gcore 是一家全球云邊緣提供商。他在與云原生技術(shù)(包括 Kubernetes)相關(guān)的各種公司有超過 5 年的撰稿經(jīng)驗。在轉(zhuǎn)向?qū)懽髦埃琌leg 曾擔(dān)任過......
許多人認(rèn)為部署在物理機上的 Kubernetes 集群性能比部署在虛擬機上的要好，但直到現(xiàn)在還沒有任何證據(jù)支撐這一假設(shè)。在 Gcore，我們只向客戶提供有充分證據(jù)支撐的信息，所以我們決定自己測試一下 K8S 部署在物理機和虛擬機上的性能是否真的有差異，如果有的話差異有多大。我將分享我們內(nèi)部測試的結(jié)果。
我有意不討論物理機節(jié)點與虛擬節(jié)點的其他方面的競爭，比如成本效益或基礎(chǔ)設(shè)施控制水平。這已經(jīng)超出了本文的范圍，本文僅專注于性能比較。
當(dāng)您在虛擬機上部署 Kubernetes 集群時，與物理機相比，您會得到額外的基礎(chǔ)架構(gòu)層——一個虛擬機管理程序（hypervisor）和一個虛擬機操作系統(tǒng)。
圖 1:物理機和虛擬機架構(gòu)的區(qū)別。
這些層會消耗物理 CPU 和 RAM 來運行，從而占用了一些計算能力。虛擬化也會影響網(wǎng)絡(luò)和存儲性能：虛擬網(wǎng)絡(luò)和存儲比物理網(wǎng)絡(luò)和存儲慢。
相比之下，當(dāng)您在物理服務(wù)器上部署 Kubernetes 集群時，您不會有任何額外的基礎(chǔ)架構(gòu)層和虛擬化。服務(wù)器的物理資源完全專用于您的工作負(fù)載，并且容器化應(yīng)用程序直接訪問這些資源。
我們?nèi)绾伪容^虛擬機和物理機 Kubernetes 性能
為了全面了解虛擬機和物理機集群性能的比較，我們測量了以下指標(biāo):
- CPU: 速度和利用率
- RAM: 延遲
- 存儲: 每秒事務(wù)數(shù)(TPS)和延遲
- 網(wǎng)絡(luò): 帶寬和延遲
為了實驗的純凈性，所有測試應(yīng)用程序都是容器化的，并部署在正在比較的工作節(jié)點上。
我們的測試條件
為了測試，我們使用了在 Gcore 托管 Kuberneteshttps://gcore.com/cloud/managed-kubernetes 上運行的 K8s 集群。但是，結(jié)果也適用于原生 Kubernetes，因為托管 Kubernetes 不會增加工作節(jié)點性能的額外開銷。
為了使工作負(fù)載保持相同的條件，我們選擇了類似配置的虛擬機和物理機工作節(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)上，另一個部署在物理機上。它們的配置相似。作為測試工作負(fù)載，我們運行了:
- CPU基準(zhǔn)測試用于 CPU 測試
- Sysbench 用于 RAM 測試
- Pgbench 用于存儲測試
- Netperf 用于網(wǎng)絡(luò)測試
下表總結(jié)了最重要的測試結(jié)果:
圖 2:測試結(jié)果摘要。
顯然，在所有情況下，物理機集群的效率都更高。
我們將在本文后面詳細(xì)檢查結(jié)果，并確定更好的物理機性能對您的工作負(fù)載意味著什么。但是首先，讓我們簡單回顧一下在虛擬機上部署的 Kubernetes 集群與物理機上的基本區(qū)別。
詳細(xì)的測試結(jié)果
現(xiàn)在讓我們詳細(xì)看一下物理機和虛擬機集群在每個評估標(biāo)準(zhǔn)方面的性能。
CPU 速度和利用率
對于 CPU 速度比較，我們使用了 Alex Dedyura 的CPU 基準(zhǔn)測試。這是一個計算 π 到 10，000 位小數(shù)的腳本。計算時間以秒為單位，在 10 次測試中取平均值，作為測試結(jié)果。計算 π 是一個 CPU 密集型任務(wù)，因此基準(zhǔn)測試可以清楚地表明所測試 CPU 的性能。
以下是 CPU 速度比較結(jié)果:
圖 3:物理機集群的 CPU 速度比虛擬機集群的 CPU 快兩倍多。
虛擬機集群的 10 次重試平均時間為 47.07 秒;對于物理機集群，它是 21.46 秒。因此，物理機集群速度快了兩倍多。
以下是虛擬機集群的 CPU 利用率測試結(jié)果:
圖片
圖 4:虛擬機集群的 CPU 平均利用率為 86.81%。
圖 5:虛擬機集群 CPU 每個核心的利用率信息。
在上面的圖 4 中，紅點是最大 CPU 核心負(fù)載，綠色代表所有核心的總 CPU 負(fù)載。在執(zhí)行腳本期間，核心大部分時間以 100% 的利用率運行；平均值為 86.81%。在 15:16 左右還有一個小的搶占時間峰值，這是當(dāng)一個虛擬機由于等待物理 CPU 共享其計算資源而不執(zhí)行的常見情況。
*最大 CPU 核心負(fù)載: 此指標(biāo)通常指在 VM 內(nèi)或跨 VM 主機上觀察到的單個 CPU 內(nèi)核的最高利用率百分比。它指示某個特定 CPU 內(nèi)核被利用的程度。**所有內(nèi)核的總 CPU 負(fù)載：此指標(biāo)表示主機上所有可用 CPU 內(nèi)核的總體 CPU 利用率。它考慮到所有 CPU 內(nèi)核的組合使用情況，并提供有關(guān)主機上運行的所有 VM 使用的 CPU 容量的整體視圖。
以下是物理機集群的 CPU 利用率測試結(jié)果:
圖 6:物理機集群的 CPU 平均利用率為 43.75%。
平均 CPU 負(fù)載約為 43.75%，最大值為 62.57%，沒有搶占時間。因此，就 CPU 性能而言，測試表明物理機集群的效率約為虛擬機集群的兩倍。
RAM 延遲
對于 RAM 測試，我們使用了 sysbench并通過 RAM 傳輸了 6400 GB 的數(shù)據(jù)。以下是執(zhí)行的寫操作和讀操作的關(guān)鍵結(jié)果:
圖片
7:物理機集群的 RAM 速度比虛擬機集群快約三倍。
虛擬機集群的寫入平均時間為 174.53 毫秒，而物理機集群進(jìn)行相同操作的時間為 62.02 毫秒。讀操作分別在 173.75 和 47.33 毫秒內(nèi)完成。
這意味著物理機集群的 RAM 速度比虛擬機集群的 RAM 快約三倍。
存儲 TPS 和延遲
為了測試存儲性能，我們運行了一個 PostgreSQL 集群，并使用pgbench 基準(zhǔn)測試。我們測量了 TPS(每秒事務(wù)數(shù))和延遲。我們還改變了工作負(fù)載，在相同的集群配置上測試了 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)絡(luò)帶寬和延遲
為了測試網(wǎng)絡(luò)性能，我們使用了netperf基準(zhǔn)測試，最大報文段大小(MSS)范圍從1到65，536。MSS中的“段”元素是通過網(wǎng)絡(luò)傳輸?shù)囊环NIP數(shù)據(jù)包束。因此，MSS越大，傳輸?shù)牧髁烤驮酱蟆?/p>
我們在兩個物理節(jié)點上部署了三個工作節(jié)點：Worker 1和Worker 2位于第一個節(jié)點上，Worker 3位于第二個節(jié)點上。然后我們測試了所有三個工作節(jié)點之間的網(wǎng)絡(luò)性能。結(jié)果趨勢在所有情況下都是相似的——物理機優(yōu)于虛擬機。
最有趣的測試是工作節(jié)點之間物理距離最大的測試，即當(dāng)流量在第一個和第二個物理節(jié)點之間流動時，Worker 1/Worker 2(在第一個節(jié)點上)和Worker 3(在第二個節(jié)點上)之間的距離。我們可以認(rèn)為這是所有測試中最具挑戰(zhàn)性的條件。圖10和圖11顯示了此測試的結(jié)果。圖10顯示了MSS值為1、2、4和8時的網(wǎng)絡(luò)帶寬比較:
圖11:物理機集群的網(wǎng)絡(luò)帶寬是虛擬機集群的5倍。
虛擬機集群的帶寬范圍從 MSS=1 時的 862KB/sec 到 MSS=8 時的 6.52MB/sec，而物理機集群的帶寬范圍從 MSS 值為 4.17MB/sec 到 31MB/sec。平均而言，物理機集群的帶寬是虛擬機集群的 5 倍。
圖 12 顯示了使用相同 MSS 值的網(wǎng)絡(luò)延遲比較:
圖 12:物理機集群的網(wǎng)絡(luò)延遲最高可降低虛擬機集群的 6 倍。
正如我們所見，在 MSS=8 時測量，虛擬機集群的延遲約為 145 微秒，而物理機的延遲為 24.5 微秒，高出約 6 倍。此外，對于物理機集群，隨著 MSS 的增加，延遲的增長速度更慢。
對于所有測試，請注意，我們報告的是集群網(wǎng)絡(luò)內(nèi)部的網(wǎng)絡(luò)性能比較。我們測量了一個網(wǎng)絡(luò)內(nèi)部節(jié)點之間的帶寬和延遲，位于一個位置。如果我們使用不同位置的節(jié)點，這將增加互聯(lián)網(wǎng)延遲，而互聯(lián)網(wǎng)延遲是不穩(wěn)定的，并且可能因提供商而異。我們在合成條件下保持純凈;它們可能無法在實際環(huán)境中復(fù)制。但是，可以預(yù)期普遍趨勢得以重現(xiàn)。
物理機性能優(yōu)勢的意義
與虛擬機相比，更好的物理機性能提供了兩個簡單但關(guān)鍵的優(yōu)勢:
- 部署在物理機工作節(jié)點上的應(yīng)用程序運行和響應(yīng)速度比部署在虛擬機上的快。
- 因此，當(dāng)您選擇物理機時，客戶使用您的產(chǎn)品體驗會更好。
我們的測試結(jié)果證明了一個常識，即對需要高性能和低延遲的計算密集型工作負(fù)載(例如數(shù)據(jù)庫、AI/ML 模型和其他類型的實時應(yīng)用程序)來說，物理機確實更好。虛擬機適合對計算和延遲不敏感的工作負(fù)載，例如 Web 服務(wù)器、網(wǎng)站和開發(fā)環(huán)境。如果高性能和低延遲對您的用戶至關(guān)重要，并直接影響您的業(yè)務(wù)，您應(yīng)該考慮在 Kubernetes 集群中使用物理機。
結(jié)論
我們的測試證實了物理機工作節(jié)點優(yōu)于虛擬機工作節(jié)點的假設(shè)。我們還產(chǎn)生了關(guān)于物理機工作節(jié)點確實優(yōu)于多少的具體數(shù)據(jù)，即:
- CPU 速度和利用率提高兩倍
- RAM 延遲降低三倍
- 存儲性能提高兩倍以上
- 網(wǎng)絡(luò)延遲降低五倍以上
如果您想在物理機工作節(jié)點上試用 Kubernetes，請查看Gcore 的托管 Kubernetes。我們提供了幾種類型的工作節(jié)點配置，包括用于加速 AI/ML 工作負(fù)載的 NVIDIA GPU。
我要感謝我在 Gcore 的同事進(jìn)行測試并幫助撰寫本文: Sergey Kalinin、Sergey Mikhalev 和 Andrei Novoselov。
