成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Kubernetes:裸機vs虛擬機性能對比

云計算 虛擬化
如果您想在物理機工作節點上試用 Kubernetes,請查看Gcore 的托管 Kubernetes。我們提供了幾種類型的工作節點配置,包括用于加速 AI/ML 工作負載的 NVIDIA GPU。

本文對Kubernetes集群在虛擬機和裸機上在CPU、內存、存儲和網絡性能方面的表現進行了詳細的比較和分析。

譯自Does Kubernetes Really Perform Better on Bare Metal vs. VMs?,作者 Oleg Zinovyev 是 Gcore 的技術內容編輯,Gcore 是一家全球云邊緣提供商。他在與云原生技術(包括 Kubernetes)相關的各種公司有超過 5 年的撰稿經驗。在轉向寫作之前,Oleg 曾擔任過......

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

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

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

圖 1:物理機和虛擬機架構的區別。圖 1:物理機和虛擬機架構的區別。

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

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

我們如何比較虛擬機和物理機 Kubernetes 性能

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

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

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

我們的測試條件

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

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

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

測試結果摘要

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

  • CPU基準測試用于 CPU 測試
  • Sysbench 用于 RAM 測試
  • Pgbench 用于存儲測試
  • Netperf 用于網絡測試

下表總結了最重要的測試結果:

圖 2:測試結果摘要。圖 2:測試結果摘要。

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

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

詳細的測試結果

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

CPU 速度和利用率

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

以下是 CPU 速度比較結果:

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

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

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

圖片圖片

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

圖 5:虛擬機集群 CPU 每個核心的利用率信息。圖 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%。圖 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:存儲測試的物理機和虛擬機集群配置。圖 8:存儲測試的物理機和虛擬機集群配置。

存儲 TPS 結果

以下是 TPS 比較的平均結果:

圖片圖片

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

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

存儲延遲結果

以下是延遲測試的平均結果:

圖 10:物理機在存儲延遲方面優于虛擬機。圖 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倍。圖11:物理機集群的網絡帶寬是虛擬機集群的5倍。

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

圖 12 顯示了使用相同 MSS 值的網絡延遲比較:

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

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

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

物理機性能優勢的意義

與虛擬機相比,更好的物理機性能提供了兩個簡單但關鍵的優勢:

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

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

結論

我們的測試證實了物理機工作節點優于虛擬機工作節點的假設。我們還產生了關于物理機工作節點確實優于多少的具體數據,即:

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

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

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

責任編輯:武曉燕 來源: 云云眾生s
相關推薦

2024-10-09 11:31:51

2019-12-25 09:53:01

虛擬機技術固態硬盤

2022-08-14 09:11:13

Kubernetes容器云原生

2018-08-17 07:49:01

2017-11-02 13:20:08

數據處理PythonNumpy

2023-02-16 08:03:01

開源Kubernetes

2020-03-18 13:22:33

虛擬機OpenStack裸機

2010-05-14 11:38:24

虛擬機備份

2010-02-04 10:05:28

Dalvik虛擬機

2021-05-07 17:46:53

存儲IO

2013-11-08 10:59:17

Hadoop虛擬化VMware vSph

2023-02-06 15:28:51

2019-01-03 11:18:43

Kubernetes虛擬機容器

2014-01-13 09:47:35

虛擬機

2012-05-18 10:22:23

2024-10-07 08:40:56

Spring應用程序Java

2022-06-06 14:35:59

KubevirtKubernetes虛擬機

2012-09-28 09:39:27

華為

2009-01-05 19:07:03

服務器虛擬化虛擬機

2016-10-12 15:05:28

虛擬機性能虛擬機密度虛擬機成本
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 在线中文字幕第一页 | h片在线观看网站 | 亚洲精品白浆高清久久久久久 | 特一级毛片 | 国产免费福利在线 | 天天操操| 国产精品3区 | 国产在视频一区二区三区吞精 | 一本大道久久a久久精二百 欧洲一区二区三区 | 伊人精品 | 一本色道精品久久一区二区三区 | 亚洲一区二区视频在线播放 | 久久精品—区二区三区 | 日日夜夜草 | av喷水| 日韩一区二区三区在线观看视频 | 这里只有精品999 | 欧美久久久久久 | 国产精品久久网 | 欧一区二区| 国产亚洲一区二区精品 | 国产日韩欧美一区二区 | 国产精品区二区三区日本 | 玖玖精品| 国产福利视频在线观看 | 日韩二三区 | 精品国产18久久久久久二百 | 成年网站在线观看 | 久久久久久久网 | 国产高清在线精品一区二区三区 | 日韩一区二区三区视频在线观看 | 亚洲第一视频网 | 亚洲不卡在线观看 | 中文字幕一区二区三区精彩视频 | a视频在线| 毛色毛片免费看 | 婷婷色国产偷v国产偷v小说 | 精品一区二区久久 | 91久久久久 | 久久久久国产一区二区三区 | 成人欧美 |