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

特性亮點：CPU Manager

作者：Balaji Subramaniam (英特爾), Connor Doyle (英特爾) |

這篇部落格文章介紹了 CPU 管理器，這是 Kubernetes 中的一個 Beta 功能。CPU 管理器功能透過為某些 Pod 容器分配獨佔 CPU，改進了 Kubernetes 節點代理 Kubelet 中的工作負載放置。

cpu manager

聽起來不錯！但是 CPU 管理器對我有什麼幫助呢？

這取決於您的工作負載。Kubernetes 叢集中的單個計算節點可以執行許多 Pod，其中一些 Pod 可能執行 CPU 密集型工作負載。在這種情況下，Pod 可能會爭奪該計算節點中可用的 CPU 資源。當這種爭用加劇時，工作負載可能會移動到不同的 CPU，具體取決於 Pod 是否受到限制以及排程時 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 建立一個具有整數 CPU 請求的 Guaranteed Pod 中的容器時，該容器的 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 策略。

靜態策略將獨佔 CPU 分配給 Guaranteed QoS 類別中請求整數 CPU 的 Pod 容器。在盡力而為的基礎上，靜態策略會按照以下順序拓撲分配 CPU：

  1. 如果可用且容器請求至少一個完整的處理器套接字 worth 的 CPU，則分配同一處理器套接字中的所有 CPU。
  2. 如果可用且容器請求一個完整的核心 worth 的 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 的資料。每次實驗都運行了十次。

免受攻擊者工作負載的保護

我們運行了來自 PARSEC 基準測試套件的六個基準測試（受害者工作負載），並與一個 CPU 壓力容器（攻擊者工作負載）共同定位，分別在啟用和未啟用 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 共同執行時 Blackscholes 的效能。在每種情況下，Gu QoS 類別中的 Pod 請求一個完整套接字的核心（即 24 個 CPU），Bu QoS 類別中的 Pod 請求 23 個 CPU。

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

performance comparison

獨立工作負載的效能隔離

本節展示了 CPU 管理器為獨立真實世界工作負載提供的效能改進和隔離。我們使用了 TensorFlow 官方模型中的兩個工作負載：wide and deep 和 ResNet。我們分別使用 census 和 CIFAR10 資料集用於 wide and deep 和 ResNet 模型。在每種情況下，Pod（wide and deep，ResNet）都請求 24 個 CPU，這相當於一個完整套接字的核心。如圖所示，CPU 管理器在這兩種情況下都實現了更好的效能隔離。

performance comparison

限制

使用者可能希望在靠近連線外部裝置（如加速器或高效能網絡卡）的匯流排套接字上分配 CPU，以避免跨套接字流量。CPU 管理器尚不支援這種對齊。由於 CPU 管理器盡力而為地分配屬於一個套接字和物理核心的 CPU，因此它容易出現邊緣情況並可能導致碎片化。CPU 管理器不考慮 isolcpus Linux 核心引導引數，儘管這據報道是某些低抖動用例的常見做法。

致謝

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

宣告和免責宣告

效能測試中使用的軟體和工作負載可能已針對英特爾微處理器進行了效能最佳化。效能測試（如 SYSmark 和 MobileMark）是使用特定的計算機系統、元件、軟體、操作和功能進行測量的。任何這些因素的更改都可能導致結果不同。您應該查閱其他資訊和效能測試，以幫助您全面評估您的預期購買，包括該產品與其他產品組合時的效能。欲瞭解更多資訊，請訪問 www.intel.com/benchmarks。

英特爾技術的功能和優勢取決於系統配置，可能需要啟用硬體、軟體或服務啟用。效能因系統配置而異。任何計算機系統都無法絕對安全。請諮詢您的系統製造商或零售商，或訪問 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 是英特爾公司或其在美國和/或其他國家/地區的子公司的商標。
*其他名稱和品牌可能被聲稱屬於他人。© 英特爾公司。