本篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

功能亮點：CPU 管理器

作者：Balaji Subramaniam (Intel), Connor Doyle (Intel) |

這篇部落格文章描述了 CPU 管理器，這是 Kubernetes 中的 Beta 功能。Kubelet（Kubernetes 節點代理程式）中的 CPU 管理器功能透過為某些 pod 容器分配獨佔 CPU，來實現更好的工作負載放置。

cpu manager

聽起來不錯！但 CPU 管理器對我有幫助嗎？

這取決於您的工作負載。Kubernetes 叢集中的單個計算節點可以執行許多 pod，而其中一些 pod 可能正在執行 CPU 密集型工作負載。在這種情況下，pod 可能會爭奪該計算節點中可用的 CPU 資源。當這種競爭加劇時，工作負載可能會根據 pod 是否受到節流以及排程時 CPU 的可用性而移動到不同的 CPU。在某些情況下，工作負載可能對上下文切換敏感。在所有上述情況下，工作負載的效能都可能受到影響。

如果您的工作負載對此類情況敏感，則可以啟用 CPU 管理器，透過為您的工作負載分配獨佔 CPU 來提供更好的效能隔離。

CPU 管理器可能有助於具有以下特性的工作負載

  • 對 CPU 節流效應敏感。
  • 對上下文切換敏感。
  • 對處理器快取未命中敏感。
  • 受益於共享處理器資源（例如，資料和指令快取）。
  • 對跨插槽記憶體流量敏感。
  • 對來自同一物理 CPU 核心的超執行緒敏感或需要超執行緒。

好的！我該如何使用它？

使用 CPU 管理器很簡單。首先，在叢集的計算節點上執行的 Kubelet 中使用靜態策略啟用 CPU 管理器。然後將您的 pod 組態為 Guaranteed 服務品質 (QoS) 類別。為需要獨佔核心的容器請求整數個 CPU 核心（例如，1000m、4000m）。以與之前相同的方式建立您的 pod（例如，kubectl create -f pod.yaml）。瞧！，CPU 管理器將根據每個容器的 CPU 請求，為 pod 中的每個容器分配獨佔 CPU。

apiVersion: v1
kind: Pod
metadata:
  name: exclusive-2
spec:
  containers:
  - image: quay.io/connordoyle/cpuset-visualizer
    name: exclusive-2
    resources:
      # Pod is in the Guaranteed QoS class because requests == limits
      requests:
        # CPU request is an integer
        cpu: 2
        memory: "256M"
      limits:
        cpu: 2
        memory: "256M"

請求兩個獨佔 CPU 的 Pod 規格。

嗯…CPU 管理器如何運作？

對於 Kubernetes 以及這篇部落格文章的目的，我們將討論大多數 Linux 發行版中可用的三種 CPU 資源控制。前兩種是 CFS 份額（我在這個系統上 CPU 時間的加權公平份額是多少）和 CFS 配額（我在一段時間內 CPU 時間的硬性上限是多少）。CPU 管理器使用第三種控制，稱為 CPU 親和性（我被允許在哪些邏輯 CPU 上執行）。

預設情況下，在 Kubernetes 叢集的計算節點上執行的所有 pod 和容器都可以在系統中任何可用的核心上執行。可分配的總份額和配額量受到明確保留給 kubernetes 和系統守護進程的 CPU 資源的限制。但是，可以使用 pod 規格中的 CPU 限制來指定正在使用的 CPU 時間的限制。Kubernetes 使用 CFS 配額來強制執行 pod 容器的 CPU 限制。

當啟用 CPU 管理器並使用「靜態」策略時，它會管理一個 CPU 共享池。最初，這個共享池包含計算節點中的所有 CPU。當 Kubelet 建立 Guaranteed pod 中具有整數 CPU 請求的容器時，該容器的 CPU 會從共享池中移除，並在容器的生命週期內獨佔分配。其他容器會從這些獨佔分配的 CPU 中遷移出去。

所有非獨佔 CPU 容器（Burstable、BestEffort 和具有非整數 CPU 的 Guaranteed）都在共享池中剩餘的 CPU 上執行。當具有獨佔 CPU 的容器終止時，其 CPU 會加回共享 CPU 池。

請提供更多詳細資訊...

cpu manager

上圖顯示了 CPU 管理器的結構。CPU 管理器使用容器運行時介面的 UpdateContainerResources 方法來修改容器可以運行的 CPU。管理器定期將每個正在運行的容器的 CPU 資源的當前狀態與 cgroupfs 進行調和。

CPU 管理器使用 策略來決定 CPU 的分配。實作了兩種策略：None 和 Static。預設情況下，從 Kubernetes 1.10 版本開始，CPU 管理器啟用 None 策略。

靜態策略為 Guaranteed QoS 類別中請求整數 CPU 的 pod 容器分配獨佔 CPU。在盡力而為的基礎上，靜態策略嘗試按以下順序拓撲地分配 CPU

  1. 如果可用且容器請求至少一個插槽價值的 CPU，則分配同一處理器插槽中的所有 CPU。
  2. 如果可用且容器請求一個核心價值的 CPU，則分配來自同一物理 CPU 核心的所有邏輯 CPU（超執行緒）。
  3. 分配任何可用的邏輯 CPU，優先從同一插槽獲取 CPU。

CPU 管理器如何改善效能隔離？

啟用 CPU 管理器靜態策略後，工作負載可能會由於以下原因之一而表現更好

  1. 可以為工作負載容器分配獨佔 CPU，但不能為其他容器分配。這些容器不共享 CPU 資源。因此，當涉及侵略者或共置工作負載時，我們期望由於隔離而獲得更好的效能。
  2. 由於我們可以在工作負載之間劃分 CPU，因此減少了工作負載使用的資源之間的干擾。這些資源也可能包括快取層次結構和記憶體頻寬，而不僅僅是 CPU。這有助於總體上提高工作負載的效能。
  3. CPU 管理器在盡力而為的基礎上以拓撲順序分配 CPU。如果整個插槽是空閒的，則 CPU 管理器將獨佔地將來自空閒插槽的 CPU 分配給工作負載。這透過避免任何跨插槽流量來提升工作負載的效能。
  4. Guaranteed QoS pod 中的容器受 CFS 配額限制。非常突發的工作負載可能會被排程，在週期結束前耗盡其配額，並受到節流。在此期間，可能會有也可能沒有有意義的工作要使用這些 CPU 執行。由於 CPU 配額和靜態策略分配的獨佔 CPU 數量之間的資源數學對齊方式，這些容器不受 CFS 節流的影響（配額等於配額週期內最大可能的 CPU 時間）。

好的！好的！您有任何結果嗎？

很高興您問了！為了了解在 Kubelet 中啟用 CPU 管理器功能所提供的效能提升和隔離，我們在啟用超執行緒的雙插槽計算節點（Intel Xeon CPU E5-2680 v3）上進行了實驗。該節點包含 48 個邏輯 CPU（24 個物理核心，每個核心具有 2 向超執行緒）。在這裡，我們使用基準測試和真實世界工作負載，針對三種不同的情境，展示 CPU 管理器功能提供的效能優勢和隔離。

我該如何解釋圖表？

對於每個情境，我們都顯示箱形圖，說明在啟用和未啟用 CPU 管理器的情況下，運行基準測試或真實世界工作負載的標準化執行時間及其變異性。運行的執行時間標準化為表現最佳的運行（y 軸上的 1.00 代表表現最佳的運行，數值越低越好）。箱形圖的高度顯示了效能的變化。例如，如果箱形圖是一條線，則各次運行之間的效能沒有變化。在箱形圖中，中間線是中位數，上線是第 75 百分位數，下線是第 25 百分位數。箱形圖的高度（即第 75 百分位數和第 25 百分位數之間的差值）定義為四分位距 (IQR)。鬚線顯示該範圍外的數據，點顯示離群值。離群值定義為分別低於或高於下四分位數或上四分位數 1.5 倍 IQR 的任何數據。每個實驗運行十次。

防止侵略者工作負載

我們在啟用和未啟用 CPU 管理器功能的情況下，運行了來自 PARSEC 基準測試套件 的六個基準測試（受害者工作負載），並與 CPU 壓力容器（侵略者工作負載）共置。CPU 壓力容器 作為 pod 在 Burstable QoS 類別中運行，請求 23 個 CPU，並帶有 --cpus 48 標誌。基準測試作為 pod 運行在 Guaranteed QoS 類別中，請求一個插槽價值的 CPU（在此系統上為 24 個 CPU）。下圖繪製了在啟用和未啟用 CPU 管理器靜態策略的情況下，運行與壓力 pod 共置的基準測試 pod 的標準化執行時間。我們看到，對於所有測試案例，啟用靜態策略時，效能得到改善，效能變異性降低。

execution time

共置工作負載的效能隔離

在本節中，我們示範 CPU 管理器如何在共置工作負載情境中對多個工作負載有利。在下面的箱形圖中，我們顯示了來自 PARSEC 基準測試套件的兩個基準測試（Blackscholes 和 Canneal）在彼此共置的 Guaranteed (Gu) 和 Burstable (Bu) QoS 類別中運行的效能，無論是否啟用 CPU 管理器靜態策略。

從左上角開始並順時針進行，我們分別顯示了 Bu QoS 類別中 Blackscholes 的效能（左上）、Bu QoS 類別中 Canneal 的效能（右上）、Gu QoS 類別中 Canneal 的效能（右下）和 Gu QoS 類別中 Blackscholes 的效能（左下）。在每種情況下，它們都與 Gu QoS 類別中的 Canneal（左上）、Gu QoS 類別中的 Blackscholes（右上）、Bu QoS 類別中的 Blackscholes（右下）和 Bu QoS 類別中的 Canneal（左下）共置，從左上角開始順時針方向。例如，Bu-blackscholes-Gu-canneal 圖（左上）顯示了 Blackscholes 在 Bu QoS 類別中運行時與在 Gu QoS 類別中運行的 Canneal 共置的效能。在每種情況下，Gu QoS 類別中的 pod 都請求價值整個插槽的核心（即 24 個 CPU），而 Bu QoS 類別中的 pod 請求 23 個 CPU。

在所有測試中，共置工作負載的效能都更好，效能變化更小。例如，考慮 Bu-blackscholes-Gu-canneal（左上）和 Gu-canneal-Bu-blackscholes（右下）的情況。它們顯示了 Blackscholes 和 Canneal 在啟用和未啟用 CPU 管理器的情況下同時運行的效能。在這種特定情況下，由於 Canneal 屬於 Gu QoS 類別並請求整數個 CPU 核心，因此 Canneal 獲得了獨佔核心。但是 Blackscholes 也獲得了獨佔 CPU 集，因為它是共享池中唯一的工作負載。因此，Blackscholes 和 Canneal 都因 CPU 管理器而獲得了一些效能隔離優勢。

performance comparison

獨立工作負載的效能隔離

本節顯示了 CPU 管理器為獨立真實世界工作負載提供的效能提升和隔離。我們使用了來自 TensorFlow 官方模型 的兩個工作負載：wide and deep 和 ResNet。我們分別對 wide and deep 和 ResNet 模型使用 census 和 CIFAR10 數據集。在每種情況下，pod（wide and deep，ResNet）請求 24 個 CPU，這相當於整個插槽價值的核心。如圖所示，CPU 管理器在兩種情況下都能實現更好的效能隔離。

performance comparison

限制

使用者可能希望將 CPU 分配在靠近連接到外部設備（例如加速器或高效能網卡）的總線的插槽上，以避免跨插槽流量。CPU 管理器尚不支援這種對齊方式。由於 CPU 管理器盡力而為地分配屬於插槽和物理核心的 CPU，因此它容易出現邊角案例，並可能導致碎片。CPU 管理器不考慮 isolcpus Linux 核心啟動參數，儘管據報導這是某些低抖動用例的常見做法。

致謝

我們感謝為此功能做出貢獻或提供回饋的社群成員，包括 WG-Resource-Management 和 SIG-Node 的成員。cmx.io（用於有趣的繪圖工具）。

注意事項和免責聲明

效能測試中使用的軟體和工作負載可能僅針對 Intel 微處理器上的效能進行了優化。效能測試（例如 SYSmark 和 MobileMark）是使用特定的電腦系統、組件、軟體、操作和功能來測量的。對任何這些因素的任何變更都可能導致結果產生變化。您應該諮詢其他資訊和效能測試，以協助您充分評估您考慮購買的產品，包括該產品與其他產品組合使用時的效能。如需更多資訊，請造訪 www.intel.com/benchmarks。

Intel 技術的功能和優勢取決於系統配置，可能需要啟用的硬體、軟體或服務啟動。效能因系統配置而異。沒有電腦系統可以絕對安全。請諮詢您的系統製造商或零售商，或造訪 intel.com 了解更多資訊。

工作負載配置：https://gist.github.com/balajismaniam/fac7923f6ee44f1f36969c29354e3902 https://gist.github.com/balajismaniam/7c2d57b2f526a56bb79cf870c122a34c https://gist.github.com/balajismaniam/941db0d0ec14e2bc93b7dfe04d1f6c58 https://gist.github.com/balajismaniam/a1919010fe9081ca37a6e1e7b01f02e3 https://gist.github.com/balajismaniam/9953b54dd240ecf085b35ab1bc283f3c

系統配置：CPU 架構：x86_64 CPU 運作模式：32 位元、64 位元 位元組順序：小端 CPU 數量：48 線上 CPU 列表：0-47 每核心執行緒數：2 每插槽核心數：12 插槽數：2 NUMA 節點數：2 供應商 ID：GenuineIntel 型號名稱：Intel(R) Xeon(R) CPU E5-2680 v3 記憶體 256 GB 作業系統/核心 Linux 3.10.0-693.21.1.el7.x86_64

Intel、Intel 標誌和 Xeon 是 Intel Corporation 或其在美國和/或其他國家/地區的子公司的商標。
*其他名稱和品牌可能被聲稱為其他人的財產。© Intel 公司。