節點資源管理器

為了支援對延遲敏感和高吞吐量的負載，Kubernetes 提供了一套資源管理器。 這些管理器旨在協調和最佳化節點資源的對齊，以滿足 Pod 對 CPU、裝置和記憶體（大頁）資源提出的特定要求。

硬體拓撲對齊策略

**拓撲管理器（Topology Manager）**是 kubelet 的一個元件，它旨在協調負責這些最佳化的元件集合。 整個資源管理過程由你指定的策略控制。要了解更多資訊，請閱讀控制節點上的拓撲管理策略。

為 Pod 分配 CPU 的策略

特性狀態： Kubernetes v1.26 [stable] (預設啟用：是)

Pod 繫結到節點後，該節點上的 kubelet 可能需要多路複用現有硬體（例如，在多個 Pod 之間共享 CPU），或者透過專用一些資源來分配硬體（例如，為 Pod 獨佔使用分配一個或多個 CPU）。

預設情況下，kubelet 使用 CFS 配額 來強制執行 Pod CPU 限制。 當節點執行許多 CPU 密集型 Pod 時，工作負載可能會移動到不同的 CPU 核心，具體取決於 Pod 是否受到限制以及排程時哪些 CPU 核心可用。許多工作負載對這種遷移不敏感，因此在沒有任何干預的情況下也能正常工作。

然而，對於 CPU 快取親和性和排程延遲顯著影響工作負載效能的工作負載，kubelet 允許使用替代的 CPU 管理策略來確定節點上的某些放置偏好。 這是透過 **CPU 管理器（CPU Manager）**及其策略實現的。有兩種可用的策略：

  • none：none 策略明確啟用現有的預設 CPU 親和方案，除了作業系統排程器自動執行的親和性之外不提供任何親和性。 針對Guaranteed Pod 和Burstable Pod 的 CPU 使用限制使用 CFS 配額強制執行。
  • static：static 策略允許 Guaranteed Pod 中具有整數 CPU requests 的容器訪問節點上的獨佔 CPU。 這種獨佔性透過 cpuset cgroup 控制器強制執行。

CPU 管理器不支援在執行時下線和上線 CPU。

靜態策略

靜態策略支援更細粒度的 CPU 管理和獨佔 CPU 分配。 此策略管理一個共享 CPU 池，該池最初包含節點中的所有 CPU。 獨佔可分配 CPU 的數量等於節點中的 CPU 總數減去 kubelet 配置設定的任何 CPU 預留。這些選項預留的 CPU 以整數形式從初始共享池中按物理核心 ID 升序獲取。 此共享池是執行 BestEffort 和 Burstable Pod 中任何容器的 CPU 集合。 Guaranteed Pod 中具有分數 CPU requests 的容器也執行在共享池中的 CPU 上。 只有屬於 Guaranteed Pod 且具有整數 CPU requests 的容器才被分配獨佔 CPU。

當符合靜態分配要求的 Guaranteed Pod 中的容器被排程到節點時，CPU 會從共享池中移除並放置到容器的 cpuset 中。 CFS 配額不用於限制這些容器的 CPU 使用，因為它們的用途受排程域本身限制。 換句話說，容器 cpuset 中的 CPU 數量等於 Pod 規約中指定的整數 CPU limit。這種靜態分配增加了 CPU 親和性，並減少了由於對 CPU 密集型工作負載進行節流而導致的上下文切換。

考慮以下 Pod 規約中的容器：

spec:
  containers:
  - name: nginx
    image: nginx

由於未指定資源 requests 或 limits，上述 Pod 在 BestEffort QoS 等級下執行。 它執行在共享池中。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

由於資源 requests 不等於 limits 且未指定 cpu 數量，上述 Pod 在 Burstable QoS 等級下執行。 它執行在共享池中。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"

由於資源 requests 不等於 limits，上述 Pod 在 Burstable QoS 等級下執行。 它執行在共享池中。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

由於 requests 等於 limits，上述 Pod 在 Guaranteed QoS 等級下執行。 並且容器對 CPU 資源的資源限制是一個大於或等於一的整數。 nginx 容器被授予 2 個獨佔 CPU。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "1.5"
      requests:
        memory: "200Mi"
        cpu: "1.5"

由於 requests 等於 limits，上述 Pod 在 Guaranteed QoS 等級下執行。 但容器對 CPU 資源的資源限制是一個分數。 它執行在共享池中。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"

由於只指定了 limits，並且在未明確指定 requests 時將其設定為等於 limits，上述 Pod 在 Guaranteed QoS 等級下執行。 並且容器對 CPU 資源的資源限制是一個大於或等於一的整數。 nginx 容器被授予 2 個獨佔 CPU。

靜態策略選項

以下是靜態 CPU 管理策略可用的策略選項，按字母順序排列：

align-by-socket（Alpha 版，預設隱藏）
按物理封裝/插槽邊界而非邏輯 NUMA 邊界對齊 CPU（自 Kubernetes v1.25 起可用）
distribute-cpus-across-cores（Alpha 版，預設隱藏）
將虛擬核心（有時稱為硬體執行緒）分配到不同的物理核心（自 Kubernetes v1.31 起可用）
distribute-cpus-across-numa（Beta 版，預設可見）
將 CPU 分散到不同的 NUMA 域，旨在實現所選域之間的均勻平衡（自 Kubernetes v1.23 起可用）
full-pcpus-only（GA，預設可見）
始終分配完整的物理核心（自 Kubernetes v1.22 起可用，自 Kubernetes v1.33 起達到 GA 狀態）
strict-cpu-reservation（Beta 版，預設可見）
無論 QoS 等級如何，都禁止所有 Pod 在保留的 CPU 上執行（自 Kubernetes v1.32 起可用）
prefer-align-cpus-by-uncorecache（Beta 版，預設可見）
盡力而為地按非核心（末級）快取邊界對齊 CPU（自 Kubernetes v1.32 起可用）

你可以使用以下特性門控根據其成熟度級別來開啟或關閉選項組：

  • CPUManagerPolicyBetaOptions (預設啟用)。停用以隱藏 Beta 級別的選項。
  • CPUManagerPolicyAlphaOptions (預設停用)。啟用以顯示 Alpha 級別的選項。

你仍然需要在 kubelet 配置檔案中使用 cpuManagerPolicyOptions 欄位啟用每個選項。

有關你可以配置的各個選項的更多詳細資訊，請繼續閱讀。

full-pcpus-only

如果指定了 full-pcpus-only 策略選項，靜態策略將始終分配完整的物理核心。 預設情況下，在沒有此選項的情況下，靜態策略使用拓撲感知的最佳匹配分配來分配 CPU。在啟用 SMT 的系統上，該策略可以分配獨立的虛擬核心，這些核心對應於硬體執行緒。這可能導致不同的容器共享相同的物理核心；這種行為反過來又會導致 “吵鬧的鄰居”問題。 啟用此選項後，kubelet 僅在所有容器的 CPU 請求可以透過分配完整的物理核心來滿足時，才會接納 Pod。 如果 Pod 未透過准入，它將進入 Failed 狀態，並顯示訊息 SMTAlignmentError。

distribute-cpus-across-numa

如果指定了 distribute-cpus-across-numa 策略選項，在需要多個 NUMA 節點才能滿足分配的情況下，靜態策略將均勻地分配 CPU 到各個 NUMA 節點。 預設情況下，CPUManager 會將 CPU 儘可能地打包到一個 NUMA 節點上，直到該節點滿載，任何剩餘的 CPU 簡單地溢位到下一個 NUMA 節點。這可能會在依賴屏障（和類似同步原語）的並行程式碼中造成不必要的瓶頸，因為這類程式碼往往只以最慢的 worker（由於至少一個 NUMA 節點上可用的 CPU 較少而變慢）的速度執行。透過在 NUMA 節點之間均勻分配 CPU，應用程式開發人員可以更容易地確保沒有單個 worker 比其他 worker 更多地受到 NUMA 效應的影響，從而提高這些型別應用程式的整體效能。

align-by-socket

如果指定了 align-by-socket 策略選項，在決定如何為容器分配 CPU 時，將認為 CPU 在插槽邊界對齊。 預設情況下，CPUManager 在 NUMA 邊界對齊 CPU 分配，如果需要從多個 NUMA 節點獲取 CPU 才能滿足分配，這可能會導致效能下降。 儘管它嘗試確保所有 CPU 都從**最少**數量的 NUMA 節點分配，但不能保證這些 NUMA 節點將在同一插槽上。 透過指示 CPUManager 明確地在插槽邊界而不是 NUMA 邊界對齊 CPU，我們能夠避免此類問題。 請注意，此策略選項與 TopologyManager 的 single-numa-node 策略不相容，並且不適用於插槽數量大於 NUMA 節點數量的硬體。

distribute-cpus-across-cores

如果指定了 `distribute-cpus-across-cores` 策略選項，靜態策略將嘗試將虛擬核心（硬體執行緒）分配到不同的物理核心。 預設情況下，`CPUManager` 傾向於將 CPU 儘可能地打包到少數物理核心上，這可能導致相同物理核心上的 CPU 之間發生爭用，並導致效能瓶頸。 透過啟用 `distribute-cpus-across-cores` 策略，靜態策略可確保 CPU 儘可能地分佈在多個物理核心上，從而減少相同物理核心上的爭用，從而提高整體效能。然而，需要注意的是，當系統負載過重時，此策略可能效果不佳。在這些條件下，減少爭用的好處會減弱。 相反，預設行為有助於減少核心間通訊開銷，可能在高負載條件下提供更好的效能。

strict-cpu-reservation

KubeletConfiguration 中的 reservedSystemCPUs 引數，或已棄用的 kubelet 命令列選項 --reserved-cpus，為作業系統系統守護程序和 Kubernetes 系統守護程序定義了一個明確的 CPU 集合。 此引數的更多詳細資訊可以在 明確預留 CPU 列表 頁面上找到。 預設情況下，這種隔離僅針對具有整數 CPU 請求的 Guaranteed Pod 實現，而不是針對 Burstable 和 BestEffort Pod（以及具有分數 CPU 請求的 Guaranteed Pod）。 准入僅比較 CPU 請求與可分配 CPU。 由於 CPU 限制高於請求，預設行為允許 Burstable 和 BestEffort Pod 使用 reservedSystemCPUs 的容量，並導致主機作業系統服務在實際部署中餓死。 如果啟用了 strict-cpu-reservation 策略選項，靜態策略將不允許任何工作負載使用 reservedSystemCPUs 中指定的 CPU 核心。

prefer-align-cpus-by-uncorecache

如果指定了 `prefer-align-cpus-by-uncorecache` 策略，靜態策略將為單個容器分配 CPU 資源，使得分配給容器的所有 CPU 共享相同的非核心快取塊（也稱為末級快取或 LLC）。 預設情況下，`CPUManager` 將緊密打包 CPU 分配，這可能導致容器從多個非核心快取中分配 CPU。 此選項使 `CPUManager` 能夠以最大化非核心快取有效利用率的方式分配 CPU。 分配是盡力而為的，旨在在相同的非核心快取內關聯儘可能多的 CPU。 如果容器的 CPU 需求超過單個非核心快取的 CPU 容量，`CPUManager` 將最小化使用的非核心快取數量，以保持最佳的非核心快取對齊。 特定的工作負載可以從快取級別的快取間延遲和“吵鬧的鄰居”減少中受益。 如果 `CPUManager` 無法在節點資源充足的情況下進行最佳對齊，容器仍將使用預設的打包行為進行准入。

記憶體管理策略

特性狀態： Kubernetes v1.32 [stable] （預設啟用：true）

Kubernetes **記憶體管理器（Memory Manager）**支援為 Guaranteed QoS 等級 中的 Pod 提供記憶體（和大頁）保證分配的功能。

記憶體管理器採用提示生成協議來為 Pod 生成最合適的 NUMA 親和性。 記憶體管理器將這些親和性提示提供給中央管理器（**拓撲管理器（Topology Manager）**）。根據提示和拓撲管理器策略，Pod 被拒絕或准入到節點。

此外，記憶體管理器確保 Pod 請求的記憶體是從最少數量的 NUMA 節點分配的。

其他資源管理器

各個管理器的配置在專用文件中詳細說明：

最後修改於 2025 年 7 月 2 日太平洋標準時間上午 11:16：node: 將 cpumanager prefer-align-cpus-by-uncorecache 升級到 Beta 版 (ed3d39a2ff)