KUBERNETES資源管理之–資源預(yù)留
Kubernetes 的節(jié)點(diǎn)可以按照 Capacity 調(diào)度。node節(jié)點(diǎn)本身除了運(yùn)行不少驅(qū)動(dòng) OS 和 Kubernetes 的系統(tǒng)守護(hù)進(jìn)程，默認(rèn)情況下 pod 能夠使用節(jié)點(diǎn)全部可用容量， 除非為這些系統(tǒng)守護(hù)進(jìn)程留出資源，否則它們將與 pod 爭(zhēng)奪資源并導(dǎo)致節(jié)點(diǎn)資源短缺問題。由于某些Pod沒有對(duì)內(nèi)存及CPU進(jìn)行限制，導(dǎo)致Pod在運(yùn)行過程中所需的內(nèi)存超過了節(jié)點(diǎn)本身的內(nèi)存（OOM），導(dǎo)致某些進(jìn)程被Linux系統(tǒng)的OOM killer機(jī)制殺掉，假如被殺掉的進(jìn)程是系統(tǒng)進(jìn)程或K8S組件，會(huì)導(dǎo)致比較嚴(yán)重的問題，例如導(dǎo)致節(jié)點(diǎn)崩潰，使得運(yùn)行在該節(jié)點(diǎn)上的所有Pod狀態(tài)出現(xiàn)異常。

為了解決上述問題，可以采取如下方法

• 每個(gè)節(jié)點(diǎn)為系統(tǒng)守護(hù)進(jìn)程預(yù)留計(jì)算資源(CPU、內(nèi)存、磁盤空間)
• Pod驅(qū)逐：節(jié)點(diǎn)資源到達(dá)一定使用量，開始驅(qū)逐 pod，減輕本節(jié)點(diǎn)的壓力
• 每個(gè)Pod需指定所需資源，限制其可使用的資源上限。

一、資源問題概述

系統(tǒng)資源可分為兩類：可壓縮資源（CPU）和不可壓縮資源（memory、storage）?？蓧嚎s資源比如CPU超配后，在系統(tǒng)滿負(fù)荷時(shí)會(huì)劃分時(shí)間片分時(shí)運(yùn)行進(jìn)程，系統(tǒng)整體會(huì)變慢（一般不會(huì)導(dǎo)致太大的問題）。但不可壓縮資源如Memory，當(dāng)系統(tǒng)內(nèi)存不足時(shí)，就有可能觸發(fā)系統(tǒng) OOM；這時(shí)候根據(jù) oom score 來確定優(yōu)先殺死哪個(gè)進(jìn)程，而 oom_score_adj 又是影響 oom score 的重要參數(shù)，其值越低，表示 oom 的優(yōu)先級(jí)越低。在worker節(jié)點(diǎn)中，進(jìn)程的 oom_score_adj 如下：

所以，OOM 的優(yōu)先級(jí)如下：

BestEffort Pod > Burstable Pod > 其它進(jìn)程 > Guaranteed Pod > kubelet/docker 等 > sshd 等

二、資源預(yù)留

kubelet的啟動(dòng)配置中有一個(gè)Node Allocatable特性，來為系統(tǒng)守護(hù)進(jìn)程和k8s組件預(yù)留計(jì)算資源，使得即使節(jié)點(diǎn)滿負(fù)載運(yùn)行時(shí)，也不至于出現(xiàn)pod去和系統(tǒng)守護(hù)進(jìn)程以及k8s組件爭(zhēng)搶資源，導(dǎo)致節(jié)點(diǎn)掛掉的情況。目前支持對(duì)CPU, memory, ephemeral-storage三種資源進(jìn)行預(yù)留。

可分配的節(jié)點(diǎn)暴露為 API 中 v1.Node 對(duì)象的一部分，也是 CLI 中 kubectl describe node 的一部分。

在 kubelet 中，可以為兩類系統(tǒng)守護(hù)進(jìn)程預(yù)留資源。

節(jié)點(diǎn)可供Pod使用資源總量的計(jì)算公式如下：

allocatable = NodeCapacity - [kube-reserved] - [system-reserved] - [eviction-threshold]

參考目前真實(shí)的物理環(huán)境,如下：

[root@node1 ~]# kubectl describe node node1
Capacity:
  cpu:                                        128
  ephemeral-storage:                          256378368Ki
  hugepages-1Gi:                              36Gi
  intel.com/intel_sriov_switchdev_xxv710_vf:  64
  memory:                                     527832708Ki
  pods:                                       110
Allocatable:
  cpu:                                        112
  ephemeral-storage:                          236278303558
  hugepages-1Gi:                              36Gi
  intel.com/intel_sriov_switchdev_xxv710_vf:  64
  memory:                                     448140932Ki
  pods:                                       110
  
這是我真實(shí)環(huán)境中的物理總量，cpu120C，內(nèi)存504G，容器使用存儲(chǔ)資源單獨(dú)在/var目錄下，未對(duì)存儲(chǔ)資源進(jìn)行限制，使用的默認(rèn)值。系統(tǒng)中還開啟了大頁內(nèi)存以及使用的sriov等資源（此處不做具體講解，只說cpu，內(nèi)存的限制使用）

三、kubelet常用配置參數(shù)

• kube預(yù)留值

Kubelet 標(biāo)志: --kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]
Kubelet 標(biāo)志: --kube-reserved-cgroup=

#################
kube-reserved 用來給諸如 kubelet、容器運(yùn)行時(shí)、節(jié)點(diǎn)問題監(jiān)測(cè)器等 Kubernetes 系統(tǒng)守護(hù)進(jìn)程記述其資源預(yù)留值。 該配置并非用來給以 Pod 形式運(yùn)行的系統(tǒng)守護(hù)進(jìn)程預(yù)留資源。假如組件要是以static pod形式啟動(dòng)的，那并不在這個(gè)kube-reserved管理并限制的cgroup中，而是在kubepod這個(gè)cgroup中。除了 cpu、內(nèi)存 和 ephemeral-storage之外，pid 可用來指定為 kubernetes 系統(tǒng)守護(hù)進(jìn)程預(yù)留指定數(shù)量的進(jìn)程 ID。

kube-reserved-cgroup這個(gè)參數(shù)用來指定k8s系統(tǒng)組件所使用的cgroup。注意，從 Kubernetes 1.18 版本開始，默認(rèn)情況下，Kubernetes 已經(jīng)為每個(gè)組件自動(dòng)分配了一個(gè)保留的 cgroup。如果你的版本小于1.18，需要提前把指定的cgroup及其子系統(tǒng)需要預(yù)先創(chuàng)建好，kubelet并不會(huì)為你自動(dòng)創(chuàng)建好。

• system預(yù)留值

Kubelet 標(biāo)志: --system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]
Kubelet 標(biāo)志: --system-reserved-cgroup=

########################
system-reserved用于為系統(tǒng)守護(hù)進(jìn)程記述其資源預(yù)留值例如sshd等服務(wù)。system-reserved也應(yīng)該為kernel 預(yù)留內(nèi)存，因?yàn)槟壳発ernel使用的內(nèi)存并不記在 Kubernetes 的 Pod 上。同時(shí)還推薦為用戶登錄會(huì)話預(yù)留資源（systemd 體系中的user.slice）。除了cpu、內(nèi)存和ephemeral-storage之外，pid可用來指定為系統(tǒng)守護(hù)進(jìn)程預(yù)留指定數(shù)量的進(jìn)程 ID。

如果你的版本小于1.18，需要提前創(chuàng)建system cgroup，否則kubelet啟動(dòng)失敗。

• 驅(qū)逐閾值

Kubelet 標(biāo)志：--eviction-hard=[memory.available<500Mi]

######################################
kubelet 的 --eviction-hard 標(biāo)志用于設(shè)置 Kubernetes 節(jié)點(diǎn)上的資源耗盡情況下的強(qiáng)制驅(qū)逐策略。它支持以下資源閾值：

1：memory.available：可用內(nèi)存的百分比。例如，--eviction-hard=memory.available<100Mi 表示當(dāng)可用內(nèi)存小于 100 MiB 時(shí)觸發(fā)驅(qū)逐。
2：nodefs.available：可用節(jié)點(diǎn)文件系統(tǒng)的百分比。例如，--eviction-hard=nodefs.available<10% 表示當(dāng)可用節(jié)點(diǎn)文件系統(tǒng)空間小于 10% 時(shí)觸發(fā)驅(qū)逐。
3：imagefs.available：可用容器鏡像文件系統(tǒng)的百分比。例如，--eviction-hard=imagefs.available<15% 表示當(dāng)可用容器鏡像文件系統(tǒng)空間小于 15% 時(shí)觸發(fā)驅(qū)逐。
可以使用 <、<=、>、>= 符號(hào)來設(shè)置不同的閾值條件。

############################
請(qǐng)注意，--eviction-hard 的設(shè)置可能因 Kubernetes 版本而有所不同。確保參考您所使用的具體版本的文檔來了解更多關(guān)于資源閾值以及其他相關(guān)設(shè)置和選項(xiàng)的詳細(xì)信息。

• 顯示保留的cpu列表

Kubelet 標(biāo)志：--reserved-cpus=0-3

############################33
reserved-cpus旨在為操作系統(tǒng)守護(hù)程序和 kubernetes 系統(tǒng)守護(hù)程序保留一組明確指定編號(hào)的 CPU。

除了上述參數(shù)之外還有其他的一些參數(shù)可供參考

1：配置 cgroup 驅(qū)動(dòng) ，驅(qū)動(dòng)通過--cgroup-driver標(biāo)志配置。
   cgroupfs是默認(rèn)的驅(qū)動(dòng)，在主機(jī)上直接操作 cgroup 文件系統(tǒng)以對(duì) cgroup 沙箱進(jìn)行管理。
   systemd是可選的驅(qū)動(dòng)，使用 init 系統(tǒng)支持的資源的瞬時(shí)切片管理 cgroup 沙箱。
   
2：實(shí)施節(jié)點(diǎn)可分配約束 --enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]標(biāo)志配置，調(diào)度器將 'Allocatable' 視為 Pod 可用的 capacity（資源容量）。kubelet 默認(rèn)對(duì) Pod 執(zhí)行 'Allocatable' 約束。 無論何時(shí)，如果所有 Pod 的總用量超過了 'Allocatable'，驅(qū)逐 Pod 的措施將被執(zhí)行?？赏ㄟ^設(shè)置 kubelet --enforce-node-allocatable 標(biāo)志值為 pods 控制這個(gè)措施。

四、cpu管理策略

默認(rèn)情況下，kubelet 使用 CFS 配額 來執(zhí)行 Pod 的 CPU 約束。 當(dāng)節(jié)點(diǎn)上運(yùn)行了很多 CPU 密集的 Pod 時(shí)，工作負(fù)載可能會(huì)遷移到不同的 CPU 核， 這取決于調(diào)度時(shí) Pod 是否被扼制，以及哪些 CPU 核是可用的。 許多工作負(fù)載對(duì)這種遷移不敏感，因此無需任何干預(yù)即可正常工作。

然而，有些工作負(fù)載的性能明顯地受到 CPU 緩存親和性以及調(diào)度延遲的影響。 對(duì)此，kubelet 提供了可選的 CPU 管理策略，來確定節(jié)點(diǎn)上的一些分配偏好。

CPU 管理策略通過 kubelet 參數(shù) --cpu-manager-policy來指定，有以下兩種策略可供使用

• none: 默認(rèn)策略，表示現(xiàn)有的調(diào)度行為。

none策略為默認(rèn)的CPU親和方案，不提供操作系統(tǒng)調(diào)度器默認(rèn)行為之外的親和性策略。 通過 CFS 配額來實(shí)現(xiàn) Guaranteed Pods 和 Burstable Pods 的 CPU 使用限制。

• static: 允許為節(jié)點(diǎn)上具有某些資源特征的 Pod 賦予增強(qiáng)的 CPU 親和性和獨(dú)占性。

static策略針對(duì)具有整數(shù)型 CPU requests的 Guaranteed Pod ，它允許該P(yáng)od中的容器獨(dú)占物理機(jī)的CPU資源。這種獨(dú)占性是使用cpuset cgroup控制器來實(shí)現(xiàn)的。

####################
注意: CPU管理器不支持運(yùn)行時(shí)下線和上線 CPUs。如果節(jié)點(diǎn)上的在線CPUs集合發(fā)生變化，則必須驅(qū)逐節(jié)點(diǎn)上的Pod，并通過刪除kubelet根目錄中的狀態(tài)文件cpu_manager_state來手動(dòng)重置CPU管理器。

#########################
此策略管理一個(gè)CPU共享池，該共享池最初包含節(jié)點(diǎn)上所有的CPU資源?？瑟?dú)占性CPU資源數(shù)量等于節(jié)點(diǎn)的CPU總量減去通過kubelet --kube-reserved和--system-reserved參數(shù)中預(yù)留的CPU資源。從1.17版本開始，可以通過 kubelet --reserved-cpus參數(shù)顯式地指定CPU預(yù)留列表。由--reserved-cpus指定的顯式CPU列表優(yōu)先于由 --kube-reserved和--system-reserved指定的CPU預(yù)留。通過這些參數(shù)預(yù)留的CPU是以'整數(shù)'方式，按物理核心 ID升序從初始共享池獲取的。 共享池是BestEffort和Burstable Pod運(yùn)行的CPU集合。 Guaranteed Pod 中的容器，如果聲明了'非整數(shù)值'的CPU requests，也將運(yùn)行在共享池的CPU上。只有Guaranteed Pod中，指定了整數(shù)型CPU requests 的容器，才會(huì)被分配獨(dú)占CPU資源。

########################################
spec:
  containers:
  - name: nginx
    image: nginx
    
該P(yáng)od屬于BestEffort QoS類型，因?yàn)槠湮粗付╮equests或limits值。所以該容器運(yùn)行在共享CPU池中。

###################################
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
該P(yáng)od屬于Burstable QoS類型，因?yàn)槠滟Y源requests不等于limits，且未指定cpu數(shù)量。所以該容器運(yùn)行在共享CPU池中。

###################################
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"
該P(yáng)od屬于Burstable QoS類型，因?yàn)槠滟Y源requests 不等于limits。所以該容器運(yùn)行在共享 CPU池中。

#######################################
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"
該P(yáng)od屬于Guaranteed QoS類型，因?yàn)槠鋜equests值與limits相等。同時(shí)容器對(duì)CPU資源的限制值是一個(gè)大于或等于1的整數(shù)值。所以該nginx容器被賦予2個(gè)獨(dú)占CPU。

#################################
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "1.5"
      requests:
        memory: "200Mi"
        cpu: "1.5"
該P(yáng)od屬于Guaranteed QoS類型，因?yàn)槠鋜equests值與limits相等。但是容器對(duì)CPU資源的限制值是一個(gè)小數(shù)。所以該容器運(yùn)行在共享CPU池中。

#####################################
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        
該P(yáng)od屬于Guaranteed QoS類型，因其指定了limits值，同時(shí)當(dāng)未顯式指定時(shí)，requests值被設(shè)置為與limits值相等。同時(shí)容器對(duì)CPU資源的限制值是一個(gè)大于或等于1的整數(shù)值。所以該 nginx容器被賦予2個(gè)獨(dú)占CPU。

CPU 管理器定期通過 CRI 寫入資源更新，以保證內(nèi)存中 CPU 分配與 cgroupfs 一致。 同步頻率通過新增的 Kubelet 配置參數(shù) --cpu-manager-reconcile-period 來設(shè)置。 如果不指定，默認(rèn)與 --node-status-update-frequency 的周期相同。

更改 CPU 管理器策略

CPU 管理器策略只能在 kubelet 生成新 Pod 時(shí)應(yīng)用，所以簡(jiǎn)單地從 “none” 更改為 “static” 將不會(huì)對(duì)現(xiàn)有的 Pod 起作用。更改節(jié)點(diǎn)上的 CPU 管理器策略步驟如下：

1：刪除舊的CPU管理器狀態(tài)文件。文件的路徑默認(rèn)為/var/lib/kubelet/cpu_manager_state。這將清除CPUManager維護(hù)的狀態(tài)，以便新策略設(shè)置的 cpu-sets 不會(huì)與之沖突。
2：修改kubelet的啟動(dòng)參數(shù)
3：重啟kubelet

五、NUMA 感知的內(nèi)存管理器

Kubernetes 內(nèi)存管理器（Memory Manager）為 Guaranteed QoS 類 的 Pods 提供可保證的內(nèi)存（或者內(nèi)存大頁）分配能力。內(nèi)存管理器使用提示生成協(xié)議來為 Pod 生成最合適的 NUMA 親和性配置。 內(nèi)存管理器將這類親和性提示輸入給中央管理器（即 Topology Manager）。 基于所給的提示和 Topology Manager（拓?fù)涔芾砥鳎┑牟呗栽O(shè)置，Pod 或者會(huì)被某節(jié)點(diǎn)接受，或者被該節(jié)點(diǎn)拒絕。此外，內(nèi)存管理器還確保 Pod 所請(qǐng)求的內(nèi)存是從盡量少的 NUMA 節(jié)點(diǎn)分配而來。

使用內(nèi)存管理器的前提條件

• CPU 管理器應(yīng)該被啟用，并且在節(jié)點(diǎn)（Node）上要配置合適的 CPU 管理器策略。
• 拓?fù)涔芾砥饕粏⒂茫⑶乙诠?jié)點(diǎn)上配置合適的拓?fù)涔芾砥鞑呗浴?/li>

我的環(huán)境是1.23.6。默認(rèn)開啟MemoryManager

內(nèi)存管理策略

內(nèi)存管理器支持兩種策略。通過 kubelet 參數(shù) --memory-manager-policy 來選擇哪種策略，如下：

• none(默認(rèn))

默認(rèn)的策略，并且不會(huì)以任何方式影響內(nèi)存分配。None策略返回默認(rèn)的拓?fù)涮崾拘畔?

• static

對(duì)Guaranteed Pod而言，Static內(nèi)存管理器策略會(huì)返回拓?fù)涮崾拘畔?，該信息與內(nèi)存分配有保障的NUMA節(jié)點(diǎn)集合有關(guān)，并且內(nèi)存管理器還通過更新內(nèi)部的'節(jié)點(diǎn)映射'對(duì)象來完成內(nèi)存預(yù)留。

對(duì)BestEffort或Burstable Pod而言，因?yàn)椴淮嬖趯?duì)有保障的內(nèi)存資源的請(qǐng)求，Static內(nèi)存管理器策略會(huì)返回默認(rèn)的拓?fù)涮崾?，并且不?huì)通過內(nèi)部的'節(jié)點(diǎn)映射對(duì)象'來預(yù)留內(nèi)存。

內(nèi)存管理策略配置

前面提到的參數(shù)包括 --kube-reserved、--system-reserved 和 --eviction-threshold。 這些參數(shù)值的綜合計(jì)作預(yù)留內(nèi)存的總量。為內(nèi)存管理器而新增加的 --reserved-memory 參數(shù)可以將總的預(yù)留內(nèi)存進(jìn)行劃分， 并完成跨 NUMA 節(jié)點(diǎn)的預(yù)留操作。

標(biāo)志設(shè)置的值是一個(gè)按 NUMA 節(jié)點(diǎn)的不同內(nèi)存類型所給的內(nèi)存預(yù)留的值的列表，用逗號(hào)分開。內(nèi)存管理器不會(huì)使用這些預(yù)留的內(nèi)存來為容器負(fù)載分配內(nèi)存。

配置方式如下：
--reserved-memory N:memory-type1=value1,memory-type2=value2,...
1：N（整數(shù)）- NUMA 節(jié)點(diǎn)索引，例如，0，1，2,3,4
2：memory-type(字符串)- 代表內(nèi)存類型：
   memory 表示常規(guī)內(nèi)存
   hugepages-2Mi或hugepages-1Gi 表示內(nèi)存大頁
3：value（字符串） 表示預(yù)留內(nèi)存的量，例如 1Gi

######################
舉例如下：
--reserved-memory 0:memory=1Gi,hugepages-1Gi=2Gi 在numa0上預(yù)留了1G的普通內(nèi)存和2G的內(nèi)存大頁

如果有多個(gè)numa，可以寫成如下配置
--reserved-memory 0:memory=1Gi --reserved-memory 1:memory=2Gi

#########################
在設(shè)置--reserved-memory時(shí)，必須遵守如下公式
sum(reserved-memory(i)) = kube-reserved + system-reserved + eviction-threshold
也就是reserved-memory的值等于kube預(yù)留、系統(tǒng)預(yù)留以及閾值條件(默認(rèn)的硬性驅(qū)逐閾值是 100MiB)的總和

#########################
當(dāng)系統(tǒng)中有以下設(shè)置時(shí)
--kube-reserved=cpu=4,memory=16Gi 
--system-reserved=cpu=12,memory=16Gi 
--eviction-hard=memory.available<8Gi  ##如果此值沒有設(shè)置，則reserved-memory需要加上默認(rèn)的100Mi
--memory-manager-policy=Static

那么reserved-memory的值就是kube-reserved + system-reserved + eviction-hard
正確設(shè)置為--reserved-memory 0:memory=20Gi --reserved-memory 1:memory=20Gi

k8s中，內(nèi)存管理器文件位于/var/lib/kubelet/memory_manager_state中

六、實(shí)踐

上面講述了需要的知識(shí)點(diǎn)，接下來我們按照實(shí)際的物理環(huán)境來進(jìn)行配置文章來源地址http://www.zghlxwxcb.cn/news/detail-735155.html

• 檢查節(jié)點(diǎn)的cpu拓?fù)?/strong>

lscpu查看系統(tǒng)中cpu數(shù)量
[root@node1 ~]# lscpu 
架構(gòu)：           x86_64
CPU 運(yùn)行模式：   32-bit, 64-bit
字節(jié)序：         Little Endian
CPU:             128
在線 CPU 列表：  0-127      ###總共有128C，并開啟了超線程
每個(gè)核的線程數(shù)： 2
每個(gè)座的核數(shù)：   32
座：             2
NUMA 節(jié)點(diǎn)：      8
廠商 ID：        HygonGenuine
BIOS Vendor ID:  Chengdu Hygon
CPU 系列：       24
型號(hào)：           0
型號(hào)名稱：       Hygon C86 7285 32-core Processor
BIOS Model name: Hygon C86 7285 32-core Processor
步進(jìn)：           2
CPU MHz：        2461.008
CPU 最大 MHz：   2000.0000
CPU 最小 MHz：   1200.0000
BogoMIPS：       4000.07
虛擬化：         AMD-V
L1d 緩存：       32K
L1i 緩存：       64K
L2 緩存：        512K
L3 緩存：        8192K
NUMA 節(jié)點(diǎn)0 CPU： 0-7,64-71
NUMA 節(jié)點(diǎn)1 CPU： 8-15,72-79
NUMA 節(jié)點(diǎn)2 CPU： 16-23,80-87
NUMA 節(jié)點(diǎn)3 CPU： 24-31,88-95
NUMA 節(jié)點(diǎn)4 CPU： 32-39,96-103
NUMA 節(jié)點(diǎn)5 CPU： 40-47,104-111
NUMA 節(jié)點(diǎn)6 CPU： 48-55,112-119
NUMA 節(jié)點(diǎn)7 CPU： 56-63,120-127


###################
查看numa架構(gòu)
[root@node1 ~]# numactl -H
available: 8 nodes (0-7)
node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
node 0 size: 63973 MB
node 0 free: 1335 MB
node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
node 1 size: 64441 MB
node 1 free: 54748 MB
node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
node 2 size: 64507 MB
node 2 free: 50674 MB
node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
node 3 size: 64507 MB
node 3 free: 9211 MB
node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
node 4 size: 64507 MB
node 4 free: 28655 MB
node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109 110 111
node 5 size: 64507 MB
node 5 free: 26002 MB
node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117 118 119
node 6 size: 64507 MB
node 6 free: 4099 MB
node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125 126 127
node 7 size: 64507 MB
node 7 free: 53190 MB
node distances:
node   0   1   2   3   4   5   6   7 
  0:  10  16  16  16  28  28  22  28 
  1:  16  10  16  16  28  28  28  22 
  2:  16  16  10  16  22  28  28  28 
  3:  16  16  16  10  28  22  28  28 
  4:  28  28  22  28  10  16  16  16 
  5:  28  28  28  22  16  10  16  16 
  6:  22  28  28  28  16  16  10  16 
  7:  28  22  28  28  16  16  16  10 
[root@node1 ~]# 

配置方式有兩種，可以修改/var/lib/kubelet/config.yaml文件進(jìn)行修改，不過不建議采用
此處我們采用另外一種方式，修改kubelet啟動(dòng)服務(wù)文件，如下：
1：進(jìn)入kebelet服務(wù)配置目錄,有默認(rèn)的10-kubeadm.conf配置文件
[root@node1 ~]# cd /etc/systemd/system/kubelet.service.d/
[root@node1 kubelet.service.d]# ll
總用量 8
-rw-r--r-- 1 root root 1003 9月  10 14:33 10-kubeadm.conf

2：編輯新文件11-kubelet.conf，添加如下內(nèi)容
[Service]
Environment="KUBELET_ECS_ARGS=--kube-reserved=cpu=4,memory=16Gi --system-reserved=cpu=12,memory=16Gi --eviction-hard=memory.available<8Gi,nodefs.available<10% --cpu-manager-policy=static --reserved-cpus=0-3,64-67,32-35,96-99 --memory-manager-policy=Static --reserved-memory 0:memory=20Gi --reserved-memory 4:memory=20Gi"

#####################
我們環(huán)境中為kube組件預(yù)留了4個(gè)cpu和16G內(nèi)存，為系統(tǒng)進(jìn)程預(yù)留12個(gè)cpu和16G內(nèi)存的資源，閾值條件是當(dāng)時(shí)系統(tǒng)內(nèi)存少于8G時(shí)，執(zhí)行pod疏散任務(wù)。

預(yù)留的cpu列表是0-3,64-67,32-35,96-99   ##共16個(gè)cpu，根據(jù)上面的numa架構(gòu)，位于numa0和numa4上，也別需要注意一點(diǎn)，預(yù)留cpu時(shí)，物理核一定要和其超線程對(duì)應(yīng)，例如cpu0的超線程是64

reserved-memory的值是16G + 16G + 8G = 40G ###因?yàn)轭A(yù)留的cpu位于兩個(gè)numa上，所以reserved-memory的numa也要與之對(duì)應(yīng)，否則共享池中的pod在訪問內(nèi)存時(shí)，會(huì)出現(xiàn)跨numa的問題，影響性能

1：首先要?jiǎng)h除系統(tǒng)的/var/lib/kubelet/cpu_manager_state和/var/lib/kubelet/memory_manager_state，避免與舊的策略產(chǎn)生沖突
2：加載服務(wù) systemctl daemon-reload
3：重啟kubelet服務(wù) systemctl restart kubelet 
新的策略文件會(huì)重新生成

1:編輯pod 啟動(dòng)yaml，如下；
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: docker.io/library/nginx:latest
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"
        
2:啟動(dòng)pod,如下：
[root@node1 ~]# kubectl apply -f  pod.yaml 
pod/nginx created
[root@node1 ~]# vim pod.yaml 
[root@node1 ~]# 
[root@node1 ~]# 
[root@node1 ~]# kubectl get po -o wide 
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          55s   172.10.30.91   node3   <none>           <none>

3:以上得知pod位于node3節(jié)點(diǎn)，查看該節(jié)點(diǎn)的cpu管理策略文件
[root@node3 ~]# cat /var/lib/kubelet/cpu_manager_state 
{"policyName":"static","defaultCpuSet":"0-3,21-23,32-67,85-87,96-127","entries":{"28e92e4f-958d-4f9d-8aae-e2f8557dee9d":{"nginx":"20,84"},"66ce7446-8e92-49d7-8c49-06c9ccf46e6a":{"loam-b":"13-14,77-78"},"9f223236-e84e-4169-8139-e103062d54ee":{"llb":"15-16,79-80"},"c25c6025-cfda-4c87-9413-0627187848c0":{"ipds":"7,19,24-31,71,83,88-95"},"c396c532-70d1-41b0-9993-30b2bd36d7b3":{"necc":"4,8-10,68,72-74"},"c4020329-6fc9-41a3-94c8-1d47a08e48e5":{"eems":"5,69"},"d82d23c7-b3a5-43cf-ba77-df4a2de5b225":{"alms":"6,70"},"e14ad8c9-a58c-4cad-a309-b0be2047c7cb":{"loam-a":"17-18,81-82"},"e4a6664a-d38e-4bcb-a5bd-65027645da14":{"llb":"11-12,75-76"}},"checksum":1874914806}

以上可以看到nginx使用的cpu是20,84，結(jié)合上面的cpu的拓?fù)?，位于numa2上。


4：查看node3節(jié)點(diǎn)的內(nèi)存管理文件
[root@node3 ~]# cat /var/lib/kubelet/memory_manager_state  | jq .
      "nginx": [
        {
          "numaAffinity": [
            0            ####nginx使用的內(nèi)存位于numa0上，和cpu不在一個(gè)numa上，如果這個(gè)是性能型pod，會(huì)影響業(yè)務(wù)的使用
          ],
          "type": "memory",
          "size": 2147483648
        }
      ]

############################################
如果要解決pod使用cpu和內(nèi)存numa不一致問題，有以下方法
1：關(guān)閉服務(wù)器numa功能，使節(jié)點(diǎn)只有一個(gè)numa0
2：在kubelet中添加配置參數(shù) --topology-manager-policy=single-numa-node 
3：重新加載服務(wù)配置，重啟kubelet。