本文對Kubernetes集群在虛擬機(jī)和裸機(jī)上在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)驗(yàn)。在轉(zhuǎn)向?qū)懽髦埃琌leg 曾擔(dān)任過......

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

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

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

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

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

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

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

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

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

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

我們的測試條件

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

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

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

測試結(jié)果摘要

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

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

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

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

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

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

詳細(xì)的測試結(jié)果

現(xiàn)在讓我們詳細(xì)看一下物理機(jī)和虛擬機(jī)集群在每個評估標(biāo)準(zhǔn)方面的性能。

CPU 速度和利用率

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

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

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

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

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

圖片

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

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

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

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

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

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

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

RAM 延遲

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

圖片

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

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

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

存儲 TPS 和延遲

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

以下是實(shí)例的配置:

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

存儲 TPS 結(jié)果

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

圖片

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

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

存儲延遲結(jié)果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)論

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

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

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

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