控制節點上的 CPU 管理策略

Kubernetes 將 Pod 如何在節點上執行的許多方面對使用者進行了抽象化。這是設計使然。 然而，有些工作負載需要更強大的延遲和/或效能保證，才能可接受地運作。 kubelet 提供了方法來啟用更複雜的工作負載放置策略，同時保持抽象化，避免明確的放置指令。

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

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

開始之前

您需要有一個 Kubernetes 叢集，並且必須將 kubectl 命令列工具設定為與您的叢集通訊。 建議在至少有兩個非作為控制平面主機的節點的叢集上執行本教學課程。 如果您還沒有叢集，可以使用 minikube 建立一個，或者您可以使用以下 Kubernetes Playground 之一

• Killercoda
• Play with Kubernetes

如果您執行的是舊版本的 Kubernetes，請查看您實際執行的版本的說明文件。

設定 CPU 管理策略

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

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

Windows 支援

可以在 Windows 上使用 WindowsCPUAndMemoryAffinity 功能閘道啟用 CPU 管理器支援，並且需要容器執行期的支援。 啟用功能閘道後，請按照以下步驟設定 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. 排空 (Drain) 節點。
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 集合。具有小數 CPU requests 的 Guaranteed Pod 中的容器也在此共用池中的 CPU 上運行。只有屬於 Guaranteed Pod 且具有整數 CPU requests 的容器才會被分配獨佔 CPU。

Static 策略選項

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

• CPUManagerPolicyBetaOptions 預設為啟用。停用以隱藏 Beta 級別選項。
• CPUManagerPolicyAlphaOptions 預設為停用。啟用以顯示 Alpha 級別選項。您仍然必須使用 CPUManagerPolicyOptions kubelet 選項來啟用每個選項。

static CPUManager 策略存在以下策略選項

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

可以透過將 full-pcpus-only=true 新增至 CPUManager 策略選項來啟用 full-pcpus-only 選項。同樣地，可以透過將 distribute-cpus-across-numa=true 新增至 CPUManager 策略選項來啟用 distribute-cpus-across-numa 選項。當兩者都設定時，它們是「累加」的，因為 CPU 將以 full-pcpus 而非個別核心的區塊分佈在 NUMA 節點之間。可以透過將 align-by-socket=true 新增至 CPUManager 策略選項來啟用 align-by-socket 策略選項。它也與 full-pcpus-only 和 distribute-cpus-across-numa 策略選項呈累加關係。

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

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

可以透過將 prefer-align-cpus-by-uncorecache 新增至 CPUManager 策略選項來啟用 prefer-align-cpus-by-uncorecache 選項。如果使用不相容的選項，kubelet 將無法啟動，並且會在日誌中說明錯誤原因。

有關您可以組態的個別選項行為的更多詳細資訊，請參閱 節點資源管理器 (Node ResourceManagers) 文件。