Kubernetes-23:詳解如何將CPU Manager做到遊刃有餘

vfanCloud發表於2022-06-21

k8s中為什麼要用CPU Manager?

預設情況下,kubelet 使用CFS配額來執行 Pod 的 CPU 約束。Kubernetes的Node節點會執行多個Pod,其中會有部分的Pod屬於CPU密集型的工作負載。在這種情況下,Pod之間會爭搶節點的CPU資源。當爭搶劇烈的時候,Pod會在不同的CPU Core之間進行頻繁的切換,更糟糕的是在NUMA Node之間的切換。這種大量的上下文切換,會影響程式執行的效能。

什麼是cpu密集型?
通俗來講就是對cpu依賴很高,操作cpu的頻率非常高,充分的使用cpu資源來實現本地計算任務。
另外還有io密集型:
io密集型就是講磁碟/記憶體的io操作會非常頻繁,檔案讀寫、網路請求等,這種一般cpu利用率會非常低

CPU Manager有什麼缺點?

CPU Manager特性是節點級別的CPU排程選擇,所以無法在叢集維度中選擇最優的CPU Core組合。同時CPU Manager特性要求Pod是Guaranteed時(Pod中的每個容器必須指定CPU Request和CPU Limit,並且兩者要相等)才能生效,且無法適用於所有型別的Pod。

如何開啟CPU Manager

cpu Manager 在 Kubernetes v1.12 引用為 [beta],故想要更好的使用它,版本需>=v1.12。
CPU 管理策略通過 kubelet 引數 --cpu-manager-policy 或 KubeletConfiguration 中的 cpuManagerPolicy 欄位來指定。支援兩種策略:

  • none: 預設策略,表示現有的排程行為。可以理解為不開啟cpu manager。
  • static: 允許為節點上具有某些資源特徵的 Pod 賦予增強的 CPU 親和性和獨佔性。

none 策略

none 策略顯式地啟用現有的預設 CPU 親和方案,不提供作業系統排程器預設行為之外的親和性策略。通過 CFS 配額來實現 Guaranteed Pods和 Burstable Pods的 CPU 使用限制。

static 策略

static 策略針對具有整數型 CPU requests 的 Guaranteed Pod ,它允許該類 Pod中的容器訪問節點上的獨佔 CPU 資源。這種獨佔性是使用cpuset cgroup 控制器來實現的。

CPU 管理器定期通過 CRI 寫入資源更新,以保證記憶體中 CPU 分配與 cgroupfs 一致。同步頻率通過新增的 Kubelet 配置引數 --cpu-manager-reconcile-period 來設定。如果不指定,預設與 --node-status-update-frequency 的週期(預設10s)相同。
Static 策略的行為可以使用 --cpu-manager-policy-options 引數來微調。該引數採用一個逗號分隔的 key=value 策略選項列表。此特性可以通過 CPUManagerPolicyOptions 特性門控來完全禁用。

更改CPU Manager策略

由於 CPU 管理器策略只能在 kubelet 生成新 Pod 時應用,所以簡單地從 "none" 更改為 "static"將不會對現有的 Pod 起作用。因此,為了正確更改節點上的 CPU 管理器策略,請執行以下步驟:

  1. 騰空節點。就是將pod都在此節點驅逐,或者索性stop container。
  2. 停止 kubelet。
  3. 刪除舊的 CPU 管理器狀態檔案。該檔案的路徑預設為 /var/lib/kubelet/cpu_manager_state。這將清除CPUManager 維護的狀態,以便新策略設定的 cpu-sets 不會與之衝突。
  4. 編輯 kubelet 配置以將 CPU 管理器策略更改為所需的值。
  5. 啟動 kubelet。
    對需要更改其 CPU 管理器策略的每個節點重複此過程。

說明: CPU 管理器不支援執行時下線和上線 CPUs。此外,如果節點上的 CPUs 集合發生變化,則必須驅逐節點上的 Pod,並通過刪除 kubelet 根目錄中的狀態檔案cpu_manager_state來手動重置 CPU Manager。

CPU Manager使用注意事項

此策略管理一個 CPU 共享池,該共享池最初包含節點上所有的 CPU 資源。可獨佔性 CPU 資源數量等於節點的 CPU 總量減去通過 kubelet --kube-reserved 或 --system-reserved引數保留的 CPU 資源。從 1.17 版本開始,可以通過 kubelet --reserved-cpus 引數顯式地指定 CPU 預留列表。由 --reserved-cpus 指定的顯式 CPU 列表優先於由 --kube-reserved 和 --system-reserved指定的 CPU 預留。通過這些引數預留的 CPU 是以整數方式,按物理核心 ID 升序從初始共享池獲取的。共享池是 BestEffort 和 Burstable Pod 執行的 CPU 集合。Guaranteed Pod 中的容器,如果宣告瞭非整數值的 CPU requests,也將執行在共享池的 CPU 上。只有 Guaranteed Pod 中,指定了整數型 CPU requests 的容器,才會被分配獨佔 CPU 資源。

說明: 當啟用 static 策略時,要求使用 --kube-reserved 和/或 --system-reserved 或--reserved-cpus 來保證預留的 CPU 值大於零。這是因為零預留 CPU 值可能使得共享池變空。
例如:--kube-reserved=cpu=1,memory=0

當 Guaranteed Pod 排程到節點上時,如果其容器符合靜態分配要求,相應的 CPU 會被從共享池中移除,並放置到容器的 cpuset 中。因為這些容器所使用的 CPU 受到排程域本身的限制,所以不需要使用 CFS 配額來進行 CPU 的繫結。換言之,容器 cpuset 中的 CPU 數量與 Pod 規約中指定的整數型 CPU limit 相等。這種靜態分配增強了 CPU 親和性,減少了 CPU 密集的工作負載在節流時引起的上下文切換。

CPU Manager yaml模板

正確模板:

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

該 Pod 屬於 Guaranteed QoS 型別,因為其 requests 值與 limits相等。同時,容器對 CPU 資源的限制值是一個大於或等於 1 的整數值。所以,該 nginx 容器被賦予 2 個獨佔 CPU。

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

該 Pod 屬於 Guaranteed QoS 型別,因其指定了 limits 值,同未指定requests,requests 值被設定為與 limits 值相等。同時,容器對 CPU 資源的限制值是一個大於或等於 1 的整數值。所以,該 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 資源的限制值是一個小數。所以該容器執行在共享 CPU 池中。

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

該 Pod 屬於 Burstable QoS 型別,因為其資源 requests 不等於 limits。所以該容器執行在共享 CPU 池中。

Static 策略選項

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

  • CPUManagerPolicyBetaOptions 預設啟用。禁用以隱藏 beta 級選項。
  • CPUManagerPolicyAlphaOptions 預設禁用。啟用以顯示 alpha 級選項。

必須使用CPUManagerPolicyOptions kubelet 選項啟用某個選項。

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

  • full-pcpus-only(beta,預設可見)
  • distribute-cpus-across-numa(alpha,預設隱藏)

如果使用 full-pcpus-only 策略選項,static 策略總是會分配完整的物理核心。預設情況下,如果不使用該選項,static 策略會使用拓撲感知最適合的分配方法來分配 CPU。在啟用了 SMT 的系統上,此策略所分配是與硬體執行緒對應的、獨立的虛擬核。這會導致不同的容器共享相同的物理核心,該行為進而會導致吵鬧的鄰居問題。
啟用該選項之後,只有當一個 Pod 裡所有容器的 CPU 請求都能夠分配到完整的物理核心時,kubelet 才會接受該 Pod。如果 Pod 沒有被准入,它會被置於 Failed 狀態,錯誤訊息是SMTAlignmentError。

如果使用 distribute-cpus-across-numa 策略選項,在需要多個 NUMA 節點來滿足分配的情況下,static 策略會在 NUMA 節點上平均分配 CPU。預設情況下,CPUManager 會將 CPU 分配到一個 NUMA 節點上,直到它被填滿,剩餘的 CPU 會簡單地溢位到下一個 NUMA 節點。這會導致依賴於同步屏障(以及類似的同步原語)的並行程式碼出現不期望的瓶頸,因為此類程式碼的執行速度往往取決於最慢的工作執行緒(由於至少一個 NUMA 節點存在可用 CPU 較少的情況,因此速度變慢)。通過在 NUMA 節點上平均分配 CPU,應用程式開發人員可以更輕鬆地確保沒有某個工作執行緒單獨受到 NUMA 影響,從而提高這些型別應用程式的整體效能。

可以通過將 full-pcups-only=true 新增到 CPUManager 策略選項來啟用 full-pcpus-only 選項。同樣地,可以通過將 distribute-cpus-across-numa=true新增到 CPUManager 策略選項來啟用 distribute-cpus-across-numa 選項。當兩者都設定時,它們是“累加的”,因為 CPU 將分佈在 NUMA 節點的 full-pcpus 塊中,而不是單個核心。

相關文章