節點資源管理器

為了支援延遲關鍵和高輸送量的工作負載，Kubernetes 提供了一套資源管理器。這些管理器旨在協調和最佳化節點的資源對齊，以用於配置了對 CPU、裝置和記憶體（巨頁）資源有特定需求的 Pod。

硬體拓撲對齊原則

拓撲管理器 是 kubelet 元件，旨在協調負責這些最佳化的一組元件。整體資源管理流程是使用您指定的原則來管理的。若要瞭解更多資訊，請閱讀 控制節點上的拓撲管理原則。

用於將 CPU 指派給 Pod 的原則

功能狀態： Kubernetes v1.26 [stable] (預設啟用：true)

一旦 Pod 繫結到節點，該節點上的 kubelet 可能需要多工現有硬體（例如，跨多個 Pod 共用 CPU）或透過專用某些資源來配置硬體（例如，指派一個或多個 CPU 以供 Pod 獨佔使用）。

預設情況下，kubelet 使用 CFS 配額 來強制執行 Pod CPU 限制。 當節點執行許多 CPU 繫結的 Pod 時，工作負載可能會移動到不同的 CPU 核心，具體取決於 Pod 是否受到節流以及排程時可用的 CPU 核心。許多工作負載對此移轉不敏感，因此無需任何干預即可正常運作。

但是，在 CPU 快取親和性和排程延遲顯著影響工作負載效能的工作負載中，kubelet 允許替代的 CPU 管理原則來決定節點上的一些放置偏好設定。這是使用CPU 管理器及其原則實作的。有兩種可用的原則

  • 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 集。具有小數 CPU requests 的 Guaranteed Pod 中的容器也在共用集區中的 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

上面的 Pod 在 BestEffort QoS 類別中執行，因為未指定任何資源 requests 或 limits。它在共用集區中執行。

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

上面的 Pod 在 Burstable QoS 類別中執行，因為資源 requests 不等於 limits 且未指定 cpu 數量。它在共用集區中執行。

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

上方的 Pod 在 Burstable QoS 類別中執行，因為資源 requests 不等於 limits。它在共用池中執行。

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

上方的 Pod 在 Guaranteed QoS 類別中執行，因為 requests 等於 limits。而且容器的 CPU 資源限制是大於或等於一的整數。nginx 容器被授予 2 個獨佔 CPU。

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

上方的 Pod 在 Guaranteed QoS 類別中執行，因為 requests 等於 limits。但是容器的 CPU 資源限制是分數。它在共用池中執行。

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

上方的 Pod 在 Guaranteed QoS 類別中執行，因為僅指定了 limits，且當未明確指定時，requests 會被設定為等於 limits。而且容器的 CPU 資源限制是大於或等於一的整數。nginx 容器被授予 2 個獨佔 CPU。

靜態策略選項

靜態策略的行為可以使用 CPU 管理器策略選項進行微調。以下是靜態 CPU 管理策略的可用策略選項： {{/* options in alphabetical order */}}

align-by-socket (alpha, 預設隱藏)
依實體封裝 / socket 邊界而非邏輯 NUMA 邊界對齊 CPU (自 Kubernetes v1.25 起可用) distribute-cpus-across-cores (alpha, 預設隱藏)
跨不同的實體核心分配虛擬核心，有時稱為硬體執行緒 (自 Kubernetes v1.31 起可用) distribute-cpus-across-numa (alpha, 預設隱藏)
將 CPU 分散到不同的 NUMA 網域，目標是在選定的網域之間達到均勻平衡 (自 Kubernetes v1.23 起可用) full-pcpus-only (beta, 預設可見)
始終分配完整的實體核心 (自 Kubernetes v1.22 起可用) strict-cpu-reservation (alpha, 預設隱藏)
防止所有 Pod 無論其服務品質類別為何，都在保留的 CPU 上執行 (自 Kubernetes v1.32 起可用) prefer-align-cpus-by-uncorecache (alpha, 預設隱藏)
盡力而為地依 uncore (末級) 快取邊界對齊 CPU (自 Kubernetes v1.32 起可用)

您可以使用以下功能閘道，根據選項的成熟度級別來切換選項群組的開啟和關閉

  • CPUManagerPolicyBetaOptions (預設啟用)。停用以隱藏 Beta 級別選項。
  • CPUManagerPolicyAlphaOptions (預設停用)。啟用以顯示 Alpha 級別選項。您仍然必須使用 kubelet 設定檔中的 cpuManagerPolicyOptions 欄位來啟用每個選項。

有關您可以設定的個別選項的更多詳細資訊，請繼續閱讀。

full-pcpus-only

如果指定了 full-pcpus-only 策略選項，則靜態策略將始終分配完整的實體核心。預設情況下，如果沒有此選項，靜態策略會使用拓樸感知的最佳擬合分配來分配 CPU。在啟用 SMT 的系統上，策略可以分配個別的虛擬核心，這些核心對應於硬體執行緒。這可能導致不同的容器共享相同的實體核心；這種行為反過來助長了吵雜鄰居問題。啟用此選項後，僅當可以通過分配完整實體核心來滿足其所有容器的 CPU 請求時，kubelet 才會允許 Pod 進入。如果 Pod 未通過允許，它將進入失敗狀態，並顯示訊息 SMTAlignmentError。

distribute-cpus-across-numa

如果指定了 distribute-cpus-across-numa 策略選項，則當需要多個 NUMA 節點來滿足分配時，靜態策略將在 NUMA 節點之間均勻分配 CPU。預設情況下，CPUManager 會將 CPU 打包到一個 NUMA 節點上，直到填滿為止，任何剩餘的 CPU 只會溢出到下一個 NUMA 節點。這可能會導致依賴障礙 (和類似的同步原語) 的並行程式碼中出現不必要的瓶頸，因為這種類型的程式碼往往只能以其最慢的工作者 (由於至少在一個 NUMA 節點上可用的 CPU 較少而減速) 的速度執行。通過在 NUMA 節點之間均勻分配 CPU，應用程式開發人員可以更輕鬆地確保沒有單個工作者比其他工作者遭受更多 NUMA 效應的影響，從而提高這些類型應用程式的整體效能。

align-by-socket

如果指定了 align-by-socket 策略選項，則在決定如何將 CPU 分配給容器時，將考慮在 socket 邊界對齊 CPU。預設情況下，CPUManager 會在 NUMA 邊界對齊 CPU 分配，如果需要從多個 NUMA 節點提取 CPU 才能滿足分配，則可能會導致效能下降。儘管它嘗試確保所有 CPU 都從最少數量的 NUMA 節點分配，但不能保證這些 NUMA 節點將在同一個 socket 上。通過指示 CPUManager 明確地在 socket 邊界而不是 NUMA 邊界對齊 CPU，我們可以避免此類問題。請注意，此策略選項與 TopologyManager single-numa-node 策略不相容，並且不適用於 socket 數量大於 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 和 Best-Effort Pod (以及具有分數 CPU 請求的 Guaranteed Pod)。允許僅將 CPU 請求與可分配的 CPU 進行比較。由於 CPU 限制高於請求，因此預設行為允許 Burstable 和 Best-Effort Pod 佔用 reservedSystemCPUs 的容量，並導致主機作業系統服務在真實部署中處於飢餓狀態。如果啟用 strict-cpu-reservation 策略選項，則靜態策略將不允許任何工作負載使用 reservedSystemCPUs 中指定的 CPU 核心。

prefer-align-cpus-by-uncorecache

如果指定了 prefer-align-cpus-by-uncorecache 策略，則靜態策略將為個別容器分配 CPU 資源，以便分配給容器的所有 CPU 共享相同的 uncore 快取區塊 (也稱為末級快取或 LLC)。預設情況下，CPUManager 將緊密打包 CPU 分配，這可能導致容器被分配來自多個 uncore 快取的 CPU。此選項使 CPUManager 能夠以最大化 uncore 快取的有效使用率的方式分配 CPU。分配以盡力而為為基礎執行，目標是在同一個 uncore 快取中仿射盡可能多的 CPU。如果容器的 CPU 需求超過單個 uncore 快取的 CPU 容量，則 CPUManager 會最小化使用的 uncore 快取數量，以保持最佳的 uncore 快取對齊。特定的工作負載可以從快取層級的快取間延遲和吵雜鄰居的減少中受益，從而提高效能。如果 CPUManager 無法最佳對齊，但節點具有充足的資源，則容器仍將使用預設的打包行為被允許進入。

記憶體管理策略

功能狀態： Kubernetes v1.32 [stable] (預設啟用：true)

Kubernetes 記憶體管理器 啟用了為 Guaranteed QoS 類別中的 Pod 保證記憶體 (和巨頁) 分配的功能。

記憶體管理器採用提示生成協議，為 Pod 產生最合適的 NUMA 親和性。記憶體管理器將這些親和性提示饋送到中央管理器 (拓樸管理器)。根據提示和拓樸管理器策略，Pod 會被節點拒絕或允許進入。

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

其他資源管理器

個別管理器的配置在專門文件中詳細說明

上次修改時間：2024 年 11 月 26 日下午 6:53 PST：update docs for prefer-align-cpus-by-uncorecache feature (ace1c3b93a)