控制節點上的 CPU 管理策略

Kubernetes 將 Pod 在節點上執行的許多方面對使用者進行了抽象。這是有意為之的。然而，一些工作負載需要更強的延遲和/或效能保證才能正常執行。kubelet 提供了啟用更復雜的工作負載放置策略的方法，同時保持抽象不受顯式放置指令的影響。

有關資源管理的詳細資訊，請參閱 Pod 和容器的資源管理文件。

有關 kubelet 如何實現資源管理的詳細資訊，請參閱 節點資源管理器文件。

準備工作

你需要擁有一個 Kubernetes 叢集，並且 kubectl 命令列工具已配置為與你的叢集通訊。建議在至少有兩個不是控制平面主機的節點上執行本教程。如果你還沒有叢集，可以使用 minikube 建立一個，或者使用這些 Kubernetes 遊樂場之一

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

要檢查版本，請輸入 kubectl version。

如果你執行的是舊版本的 Kubernetes，請查閱你實際執行的版本的文件。

配置 CPU 管理策略

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

然而，在 CPU 快取親和性和排程延遲顯著影響工作負載效能的工作負載中，kubelet 允許使用替代的 CPU 管理策略來確定節點上的一些放置偏好。

Windows 支援

CPU 管理器支援可以在 Windows 上透過使用 WindowsCPUAndMemoryAffinity 功能門啟用，並且它需要容器執行時中的支援。一旦功能門啟用，請按照以下步驟配置 CPU 管理器策略。

配置

CPU 管理器策略透過 --cpu-manager-policy kubelet 標誌或 KubeletConfiguration 中的 cpuManagerPolicy 欄位設定。有兩種支援的策略

• none：預設策略。
• static：允許具有特定資源特徵的 Pod 在節點上獲得更高的 CPU 親和性和獨佔性。

CPU 管理器透過 CRI 定期寫入資源更新，以協調記憶體中的 CPU 分配與 cgroupfs。協調頻率透過新的 Kubelet 配置值 --cpu-manager-reconcile-period 設定。如果未指定，則預設為與 --node-status-update-frequency 相同的持續時間。

可以透過 --cpu-manager-policy-options 標誌對靜態策略的行為進行微調。該標誌接受逗號分隔的 key=value 策略選項列表。如果停用 CPUManagerPolicyOptions 功能門，則無法微調 CPU 管理器策略。在這種情況下，CPU 管理器僅使用其預設設定執行。

除了頂級 CPUManagerPolicyOptions 功能門之外，策略選項分為兩組：alpha 質量（預設隱藏）和 beta 質量（預設可見）。這些組分別由 CPUManagerPolicyAlphaOptions 和 CPUManagerPolicyBetaOptions 功能門守護。與 Kubernetes 標準不同，這些功能門守護著選項組，因為為每個單獨的選項新增功能門會過於繁瑣。

更改 CPU 管理器策略

由於 CPU 管理器策略只能在 kubelet 啟動新 Pod 時應用，因此簡單地從“none”更改為“static”不會應用於現有 Pod。因此，為了正確更改節點上的 CPU 管理器策略，請執行以下步驟

1. 排空節點。
2. 停止 kubelet。
3. 刪除舊的 CPU 管理器狀態檔案。此檔案的路徑預設為 /var/lib/kubelet/cpu_manager_state。這會清除 CPUManager 維護的狀態，以便新策略設定的 cpu-sets 不會與它衝突。
4. 編輯 kubelet 配置以將 CPU 管理器策略更改為所需值。
5. 啟動 kubelet。

對所有需要更改 CPU 管理器策略的節點重複此過程。跳過此過程將導致 kubelet 因以下錯誤而崩潰

could not restore state from checkpoint: configured policy "static" differs from state checkpoint policy "none", please drain this node and delete the CPU manager checkpoint file "/var/lib/kubelet/cpu_manager_state" before restarting Kubelet

none 策略配置

此策略沒有額外的配置項。

static 策略配置

此策略管理一個共享的 CPU 池，該池最初包含節點中的所有 CPU。獨佔可分配的 CPU 數量等於節點中的 CPU 總數減去 kubelet --kube-reserved 或 --system-reserved 選項保留的任何 CPU。從 1.17 開始，CPU 保留列表可以透過 kubelet --reserved-cpus 選項顯式指定。由 --reserved-cpus 指定的顯式 CPU 列表優先於由 --kube-reserved 和 --system-reserved 指定的 CPU 保留。這些選項保留的 CPU 將以整數形式從初始共享池中按物理核心 ID 升序獲取。此共享池是任何 BestEffort 和 Burstable Pod 中的容器執行的 CPU 集。Guaranteed Pod 中具有分數 CPU requests 的容器也在共享池中的 CPU 上執行。只有同時屬於 Guaranteed Pod 且具有整數 CPU requests 的容器才被分配獨佔 CPU。

靜態策略選項

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

• CPUManagerPolicyBetaOptions 預設啟用。停用以隱藏 Beta 級選項。
• CPUManagerPolicyAlphaOptions 預設停用。啟用以顯示 Alpha 級選項。你仍然需要使用 CPUManagerPolicyOptions kubelet 選項啟用每個選項。

靜態 CPUManager 策略存在以下策略選項

• full-pcpus-only (GA，預設可見) (1.33 或更高版本)
• distribute-cpus-across-numa (beta，預設可見) (1.33 或更高版本)
• align-by-socket (alpha，預設隱藏) (1.25 或更高版本)
• distribute-cpus-across-cores (alpha，預設隱藏) (1.31 或更高版本)
• strict-cpu-reservation (beta，預設可見) (1.32 或更高版本)
• prefer-align-cpus-by-uncorecache (beta，預設可見) (1.34 或更高版本)

可以透過在 CPUManager 策略選項中新增 full-pcpus-only=true 來啟用 full-pcpus-only 選項。同樣，可以透過在 CPUManager 策略選項中新增 distribute-cpus-across-numa=true 來啟用 distribute-cpus-across-numa 選項。當兩者都設定時，它們是“累加的”，這意味著 CPU 將以完整的物理 CPU 塊而非單個核心的方式在 NUMA 節點之間分佈。align-by-socket 策略選項可以透過向 CPUManager 策略選項中新增 align-by-socket=true 來啟用。它也與 full-pcpus-only 和 distribute-cpus-across-numa 策略選項累加。

可以透過將 distribute-cpus-across-cores=true 新增到 CPUManager 策略選項來啟用 distribute-cpus-across-cores 選項。目前，它不能與 full-pcpus-only 或 distribute-cpus-across-numa 策略選項一起使用。

可以透過在 CPUManager 策略選項中新增 strict-cpu-reservation=true 來啟用 strict-cpu-reservation 選項，然後刪除 /var/lib/kubelet/cpu_manager_state 檔案並重新啟動 kubelet。

可以透過將 prefer-align-cpus-by-uncorecache 新增到 CPUManager 策略選項來啟用 prefer-align-cpus-by-uncorecache 選項。如果使用了不相容的選項，kubelet 將因日誌中解釋的錯誤而無法啟動。

有關你可以配置的各個選項行為的更多詳細資訊，請參閱 節點資源管理器文件。