1. 概述

1.1 問題

系統資源可分為兩類：可壓縮資源（CPU）和不可壓縮資源（memory、storage）。可壓縮資源比如CPU超配後，在系統滿負荷時會劃分時間片分時執行程序，系統整體會變慢（一般不會導致太大的問題）。但不可壓縮資源如Memory，當系統記憶體不足時，就有可能觸發系統 OOM；這時候根據 oom score 來確定優先殺死哪個程序，而 oom_score_adj 又是影響 oom score 的重要引數，其值越低，表示 oom 的優先順序越低。在計算節點中，程序的 oom_score_adj 如下：

Name	Score
sshd等（sshd／dmevented / systemd-udevd）	-1000
K8S 管理程序（kubelet / docker / journalctl）	-999
Guaranteed Pod	-998
其它程序（核心 init 程序等）	0
Burstable Pod	min(max(2, 1000 – (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
BestEffort Pod	1000

所以，OOM 的優先順序如下：

BestEffort Pod > Burstable Pod > 其它程序 > Guaranteed Pod > kubelet/docker 等 > sshd 等

在Kubernetes平臺，預設情況下Pod能夠使用節點全部可用資源。如果節點上的Pod負載較大，那麼這些Pod可能會與節點上的系統守護程序和k8s元件爭奪資源並導致節點資源短缺，甚至引發系統OOM，導致某些程序被Linux系統的OOM killer機制殺掉，假如被殺掉的程序是系統程序或K8S元件，會導致比較嚴重的問題。

1.2 解決方案

針對這種問題，主要有兩種解決方案(兩種也可以結合使用)：

本篇文章主要介紹如何正確配置資源預留，Pod的驅逐以後介紹。

2. 資源預留簡介

2.1 Node Allocatable簡介

kubelet的啟動配置中有一個Node Allocatable

特性，來為系統守護程序和k8s元件預留計算資源，使得即使節點滿負載執行時，也不至於出現pod去和系統守護程序以及k8s元件爭搶資源，導致節點掛掉的情況。目前支援對CPU, memory, ephemeral-storage三種資源進行預留。kubernetes官方建議根據各個節點的負載情況來具體配置相關引數。

節點計算資源的分配如下圖所示：

 Node Capacity
---------------------------
|     kube-reserved       |
|-------------------------|
|     system-reserved     |
|-------------------------|
|    eviction-threshold   |
|-------------------------|
|                         |
|      allocatable        |
|   (available for pods)  |
|                         |
|                         |
---------------------------

其中各個部分的含義如下：
- Node Capacity：Node的硬體資源總量
- kube-reserved：給k8s系統程序預留的資源(包括kubelet、container runtime、node problem detector等，但不會給以pod形式起的k8s系統程序預留資源)
- system-reserved：給linux系統守護程序預留的資源
- eviction-threshold：通過--eviction-hard引數為節點預留記憶體，當節點可用記憶體值低於此值時，kubelet會進行pod的驅逐
- allocatable：是真正可供節點上Pod使用的容量，kube-scheduler排程Pod時的參考此值(kubectl describe node可以看到，Node上所有Pods的request量不超過Allocatable)

節點可供Pod使用資源總量的計算公式如下：

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

從公式可以看出，預設情況下（不設定kube-reserved、system-reserved、eviction-threshold）節點上預設可以讓Pod使用的資源總量等於節點的總容量，會導致Pod與系統程序和k8s元件爭搶資源的情況發生。

2.2 配置引數

kubelet的啟動引數中涉及資源預留的主要有如下幾個：

• --cgroups-per-qos
• --cgroup-driver
• --cgroup-root
• --enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]
• --kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi]
• --kube-reserved-cgroup
• --system-reserved=[cpu=100mi][,][memory=100Mi][,][ephemeral-storage=1Gi]
• --system-reserved-cgroup
• --eviction-hard

2.2.1 引數詳解

--cgroups-per-qos

可選，預設開啟。開啟這個引數後，kubelet會將所有的pod建立在kubelet管理的cgroup層次結構下（這樣才有了限制所有Pod使用資源總量的基礎）。要想啟用Node Allocatable特性，這個引數必須開啟。

--cgroup-driver

可選。指定kubelet使用的cgroup driver。預設為cgroupfs，還可以是systemd，但是這個值需要和docker runtime所使用的cgroup driver保持一致。

--cgroup-root

可選。指定給pod使用的根cgroup，容器執行時會盡量將pod的資源限制在這個根cgroup下面。預設為空，即使用容器執行時作為根cgroup。

--enforce-node-allocatable

指定kubelet為哪些程序做硬限制，可選的值有：pods,kube-reserved,system-reserve。

這個引數開啟並指定pods後kubelet會為所有pod的總cgroup做資源限制(通過cgroup中的kubepods.limit_in_bytes)，限制為公式計算出的allocatable的大小。

之所以排程器可以限制節點上所有建立的pod的request量不會超過allocatable，已可以保證不會有超過allocatable的pod跑在該節點上，這裡還要用cgroup再做硬限制的意義可能是：pod可使用的資源是可以大於request的，所以，雖然在排程階段限制了所有request的總量不會超過allocatable的值，但不能保證真正執行起來後所有pod的資源使用量不會超過allocatable；而用cgroup做了硬限制後，當所有pod使用量達到allocatable後，會有pod被OOM killer機制殺掉，以保證實際使用量不會超過allocatable。（後面會有實驗驗證）

假如想為系統程序和k8s程序也做cgroup級別的硬限制，還可以在限制列表中再加system-reserved和kube-reserved，同時還要分別加上--kube-reserved-cgroup和--system-reserved-cgroup以指定分別限制在哪個cgroup裡。

--kube-reserved

指定為k8s系統元件（kubelet、kube-proxy、dockerd等）預留的資源量，如：--kube-reserved=cpu=1,memory=2Gi,ephemeral-storage=1Gi。

這裡需要注意一點的是這裡的kube-reserved只為非pod形式啟動的kube元件預留資源，假如元件要是以static pod形式啟動的，那並不在這個kube-reserved管理並限制的cgroup中，而是在kubepod這個cgroup中。

--kube-reserved-cgroup

這個引數用來指定k8s系統元件所使用的cgroup。注意，這裡指定的cgroup及其子系統需要預先建立好，kubelet並不會為你自動建立好。

--system-reserved

為系統守護程序(sshd, udev等)預留的資源量，如：--system-reserved=cpu=500m,memory=1Gi,ephemeral-storage=1Gi。注意，除了考慮為系統程序預留的量之外，還應該為kernel和使用者登入會話預留一些記憶體。

--system-reserved-cgroup

這個引數用來指定系統守護程序所使用的cgroup。注意，這裡指定的cgroup及其子系統需要預先建立好，kubelet並不會為你自動建立好。

--eviction-hard

設定進行pod驅逐的閾值，這個引數只支援記憶體和磁碟。通過--eviction-hard標誌預留一些記憶體後，當節點上的可用記憶體降至保留值以下時，kubelet 將會對pod進行驅逐。

3 實踐

根據是否對system和kube做cgroup上的硬限制進行劃分，資源預留主要有兩種方式：
- 只對所有pod使用的資源總量做cgroup級別的限制，對system和kube不做cgroup級別限制
- 對pod、system、kube均分別做cgroup級別限制

3.1 方式1—只限制pod資源總量

3.1.1 配置

1.將以下內容新增到kubelet的啟動引數中：

--enforce-node-allocatable=pods \
--cgroup-driver=cgroupfs \
--kube-reserved=cpu=1,memory=1Gi,ephemeral-storage=10Gi \
--system-reserved=cpu=1,memory=2Gi,ephemeral-storage=10Gi \
--eviction-hard=memory.available<500Mi,nodefs.available<10%

按以上設定，

• 節點上可供Pod所request的資源總和allocatable計算如下：
  allocatable = capacity - kube-reserved - system-reserved - eviction-hard

• 節點上所有Pod實際使用的資源總和不會超過：
  capacity - kube-reserved - system-reserved

2.重啟kubelet

3.1.2 驗證

1.驗證公式計算的allocatable與實際一致

通過kubectl describe node檢視節點實際capacity及allocatable的值

Capacity:
 cpu:     8
 memory:  32930152Ki（約31.4G）
 pods:    110
Allocatable:
 cpu:     6
 memory:  29272424Ki（約27.9G）
 pods:    110

根據公式capacity - kube-reserved - system-reserved - eviction-hard，memory的allocatable的值為31.4G - 1G - 2G - 0.5G = 27.9G，與Allocatable的值一致。

2.驗證公式計算的總使用量限制與實際值一致

檢視kubepods控制組中對記憶體的限制值memory.limit_in_bytes（memory.limit_in_bytes值決定了Node上所有的Pod實際能使用的記憶體上限）

$ cat /sys/fs/cgroup/memory/kubepods/memory.limit_in_bytes 
30499250176(約28.4G)

根據公式capacity - kube-reserved - system-reserved，Node上Pod能實際使用的資源上限值為：31.4G - 1G -2G = 28.4G，與實際一致。

3.2 方式2—同時限制pod、k8s系統元件、linux系統守護程序資源

3.2.1 配置

1.將以下內容新增到kubelet的啟動引數中：

--enforce-node-allocatable=pods,kube-reserved,system-reserved \
--cgroup-driver=cgroupfs \
--kube-reserved=cpu=1,memory=1Gi,ephemeral-storage=10Gi \
--kube-reserved-cgroup=/system.slice/kubelet.service \
--system-reserved cpu=1,memory=2Gi,ephemeral-storage=10Gi \
--system-reserved-cgroup=/system.slice \
--eviction-hard=memory.available<500Mi,nodefs.available<10%

至於如何設定cgroup結構，請參考官方建議。

2.為system.slice建立cpuset子系統:

$ sudo mkdir -p /sys/fs/cgroup/cpuset/system.slice

備註：
可以看到未建立前system.slice這個cgroup是沒有cpuset子系統的:

find /sys/fs/cgroup -name system.slice
    /sys/fs/cgroup/devices/system.slice
    /sys/fs/cgroup/memory/system.slice
    /sys/fs/cgroup/blkio/system.slice
    /sys/fs/cgroup/cpu,cpuacct/system.slice
    /sys/fs/cgroup/systemd/system.slice

而kubelet(1.11)啟動時會去檢視如下圖所示這些cgroup子系統是否存在，會報找不到相應cgroup的錯誤。

所以這一步需要手工建立相應cpuset子系統。

3.同樣的也需要為kubelet.service建立cpuset子系統:

$ sudo mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service

4.重啟kubelet

3.2.2 驗證

這種情況下pod可分配的資源和實際可使用資源理論上與方法一的計算方式和結果是一樣的，實際實驗中也是一樣的，在這裡不做贅述。重點驗證此情況下是否對k8s系統元件和linux系統守護程序做了cgroup硬限制。

檢視system.slice控制組中對記憶體的限制值memory.limit_in_bytes:

$ cat /sys/fs/cgroup/memory/system.slice/memory.limit_in_bytes
2147483648(2G)

檢視kubelet.service控制組中對記憶體的限制值memory.limit_in_bytes:

$ cat /sys/fs/cgroup/memory/system.slice/kubelet.service/memory.limit_in_bytes
1073741824(1G)

可以看到，方法2這種預留方式，對k8s元件和系統程序也做了cgroup硬限制，當k8s元件和系統元件資源使用量超過這個限制時，會出現這些程序被殺掉的情況。

更多精彩內容，請訂閱本人微信公眾號：K8SPractice

如果覺得我的文章對您有用，請隨意打賞。您的支援將鼓勵我繼續創作！

支付寶：                                                      微信：