[[422195]]

Kubernetes 的節(jié)點可以按照節(jié)點的資源容量進行調(diào)度，默認情況下 Pod 能夠使用節(jié)點全部可用容量。這樣就會造成一個問題，因為節(jié)點自己通常運行了不少驅(qū)動 OS 和 Kubernetes 的系統(tǒng)守護進程。除非為這些系統(tǒng)守護進程留出資源，否則它們將與 Pod 爭奪資源并導致節(jié)點資源短缺問題。

當我們在線上使用 Kubernetes 集群的時候，如果沒有對節(jié)點配置正確的資源預留，我們可以考慮一個場景，由于某個應用無限制的使用節(jié)點的 CPU 資源，導致節(jié)點上 CPU 使用持續(xù)100%運行，而且壓榨到了 kubelet 組件的 CPU 使用，這樣就會導致 kubelet 和 apiserver 的心跳出問題，節(jié)點就會出現(xiàn) Not Ready 狀況了。默認情況下節(jié)點 Not Ready 過后，5分鐘后會驅(qū)逐應用到其他節(jié)點，當這個應用跑到其他節(jié)點上的時候同樣100%的使用 CPU，是不是也會把這個節(jié)點搞掛掉，同樣的情況繼續(xù)下去，也就導致了整個集群的雪崩，集群內(nèi)的節(jié)點一個一個的 Not Ready 了，后果是非常嚴重的，或多或少的人遇到過 Kubernetes 集群雪崩的情況，這個問題也是面試的時候鏡像詢問的問題。

要解決這個問題就需要為 Kubernetes 集群配置資源預留，kubelet 暴露了一個名為 Node Allocatable 的特性，有助于為系統(tǒng)守護進程預留計算資源，Kubernetes 也是推薦集群管理員按照每個節(jié)點上的工作負載來配置 Node Allocatable。

本文的操作環(huán)境為 Kubernetes v1.22.1 版本，使用 Containerd 的容器運行時，Containerd 和 Kubelet 采用的 cgroup 驅(qū)動為 systemd。

Node Allocatable

Kubernetes 節(jié)點上的 Allocatable 被定義為 Pod 可用計算資源量，調(diào)度器不會超額申請 Allocatable，目前支持 CPU, memory 和 ephemeral-storage 這幾個參數(shù)。

我們可以通過 kubectl describe node 命令查看節(jié)點可分配資源的數(shù)據(jù)：

➜  ~ kubectl describe node node2 
...... 
Capacity: 
 cpu:                4 
 ephemeral-storage:  36678148Ki 
 hugepages-1Gi:      0 
 hugepages-2Mi:      0 
 memory:             7990056Ki 
 pods:               110 
Allocatable: 
 cpu:                4 
 ephemeral-storage:  33802581141 
 hugepages-1Gi:      0 
 hugepages-2Mi:      0 
 memory:             7887656Ki 
 pods:               110 
...... 

可以看到其中有 Capacity 與 Allocatable 兩項內(nèi)容，其中的 Allocatable 就是節(jié)點可被分配的資源，我們這里沒有配置資源預留，所以默認情況下 Capacity 與 Allocatable 的值基本上是一致的。下圖顯示了可分配資源和資源預留之間的關(guān)系：

Node Allocatable

• Kubelet Node Allocatable 用來為 Kube 組件和 System 進程預留資源，從而保證當節(jié)點出現(xiàn)滿負荷時也能保證 Kube 和 System 進程有足夠的資源。
• 目前支持 cpu, memory, ephemeral-storage 三種資源預留。
• Node Capacity 是節(jié)點的所有硬件資源，kube-reserved 是給 kube 組件預留的資源，system-reserved 是給系統(tǒng)進程預留的資源，eviction-threshold 是 kubelet 驅(qū)逐的閾值設定，allocatable 才是真正調(diào)度器調(diào)度 Pod 時的參考值(保證節(jié)點上所有 Pods 的 request 資源不超過 Allocatable)。

節(jié)點可分配資源的計算方式為：

Node Allocatable Resource = Node Capacity - Kube-reserved - system-reserved - eviction-threshold 

調(diào)度到某個節(jié)點上的 Pod 的 requests 總和不能超過該節(jié)點的 allocatable。

配置資源預留

比如我們現(xiàn)在需要為系統(tǒng)預留一定的資源，我們可以使用如下的幾個 kubelet 參數(shù)來進行配置：

--enforce-node-allocatable=pods 
--kube-reserved=memory=... 
--system-reserved=memory=... 
--eviction-hard=... 

這里我們暫時不設置對應的 cgroup，比如我們這里先只對 node2 節(jié)點添加資源預留，我們可以直接修改 /var/lib/kubelet/config.yaml 文件來動態(tài)配置 kubelet，添加如下所示的資源預留配置：

apiVersion: kubelet.config.k8s.io/v1beta1 
...... 
enforceNodeAllocatable: 
- pods 
kubeReserved:  # 配置 kube 資源預留 
  cpu: 500m 
  memory: 1Gi 
  ephemeral-storage: 1Gi 
systemReserved:  # 配置系統(tǒng)資源預留 
  memory: 1Gi 
evictionHard:  # 配置硬驅(qū)逐閾值 
  memory.available: "300Mi" 
  nodefs.available: "10%" 

修改完成后，重啟 kubelet，啟動完成后重新對比 Capacity 及 Allocatable 的值：

➜  ~ kubectl describe node node2 
...... 
Capacity: 
  cpu:                4 
  ephemeral-storage:  36678148Ki 
  hugepages-1Gi:      0 
  hugepages-2Mi:      0 
  memory:             7990056Ki 
  pods:               110 
Allocatable: 
  cpu:                3500m 
  ephemeral-storage:  32728839317 
  hugepages-1Gi:      0 
  hugepages-2Mi:      0 
  memory:             5585704Ki 
  pods:               110 

仔細對比可以發(fā)現(xiàn)其中的 Allocatable的值恰好是 Capacity 減去上面我們配置的預留資源的值：

allocatale = capacity - kube_reserved - system_reserved - eviction_hard 
5585704Ki = 7990056Ki - 1*1024*1024Ki - 1*1024*1024Ki - 300*1024Ki 

再通過查看 kubepods.slice(systemd 驅(qū)動是以 .slice 結(jié)尾)cgroup 中對節(jié)點上所有 Pod 內(nèi)存的限制，該值決定了 Node 上所有的 Pod 能使用的資源上限：

➜  ~ cat /sys/fs/cgroup/memory/kubepods.slice/memory.limit_in_bytes 
6034333696 

得到的 Pod 資源使用上限為：

6034333696Bytes = 5892904Ki = Allocatable(5585704Ki) + eviction_hard(300*1024Ki) 

也可以通過計算驗證我們的配置是正確的：

kubepods.slice/memory.limit_in_bytes = capacity - kube_reserved - system_reserved 

Eviction 與 OOM

1、eviction 是指 kubelet 對該節(jié)點上的 Pod 進行驅(qū)逐，OOM 是指 cgroup 對進程進行 kill

2、kubelet 對 Pod 進行驅(qū)逐時，是根據(jù) --eviction-hard 參數(shù)，比如該參數(shù)如果設置了 memory.available<20%，那么當主機的內(nèi)存使用率達到80%時，kubelet 便會對Pod進行驅(qū)逐。但是，--eviction-hard=memory.available<20% 不會對 /sys/fs/cgroup/memory/kubepods.slice/memory.limit_in_bytes 的值產(chǎn)生影響，因為 kubepods.slice/memory.limit_in_bytes = capacity - kube-reserved - system-reserved，換句話說，Pod 的內(nèi)存使用量總和是可以超過80%的，且不會被 OOM-kill，只會被 eviction。

3、kubernetes 對 Pod 的驅(qū)逐機制如下(其實就是 QoS 章節(jié)的定義)：

• 首先驅(qū)逐沒有設置資源限制的 Pod
• 然后驅(qū)逐資源上限和資源下限不一樣的 Pod
• 最后驅(qū)逐資源上限等資源下限的Pod

可分配約束

前面我們在配置資源預留的時候其中有一個 enforceNodeAllocatable 配置項(--enforce-node-allocatable)，該配置項的幫助信息為：

--enforce-node-allocatable strings                         A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'none', 'pods', 'system-reserved', and 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' and '--kube-reserved-cgroup' must also be set, respectively. If 'none' is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (default [pods]) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) 

kubelet 默認對 Pod 執(zhí)行 Allocatable 可分配約束，如果所有 Pod 的總用量超過了 Allocatable，那么驅(qū)逐 Pod 的措施將被執(zhí)行，我們可以可通過設置 kubelet --enforce-node-allocatable 標志值為 pods 控制這個措施。

此外我們還可以通過該標志來同時指定 kube-reserved 和 system-reserved 值，可以讓 kubelet 強制實施 kube-reserved 和 system-reserved 約束，不過需要注意，如果配置了 kube-reserved 或者 system-reserved 約束，那么需要對應設置 --kube-reserved-cgroup 或者 --system-reserved-cgroup 參數(shù)。

如果設置了對應的 --system-reserved-cgroup 和 --kube-reserved-cgroup 參數(shù)，Pod 能實際使用的資源上限是不會改變，但系統(tǒng)進程與 kube 進程也會受到資源上限的限制，如果系統(tǒng)進程超過了預留資源，那么系統(tǒng)進程會被 cgroup 殺掉。但是如果不設這兩個參數(shù)，那么系統(tǒng)進程就可以使用超過預留的資源上限。

所以如果要為系統(tǒng)預留和 kube 預留配置 cgroup，則需要非常小心，如果執(zhí)行了 kube-reserved 約束，那么 kubelet 就不能出現(xiàn)突發(fā)負載用光所有可用資源，不然就會被殺掉。system-reserved 可以用于為諸如 sshd、udev 等系統(tǒng)守護進程爭取資源預留，但是如果執(zhí)行 system-reserved 約束，那么可能因為某些原因?qū)е鹿?jié)點上的關(guān)鍵系統(tǒng)服務 CPU 資源短缺或因為內(nèi)存不足而被終止，所以如果不是自己非常清楚如何配置，最好別配置 cgroup 約束，如果需要自行配置，可以參考第一期的資源預留文檔進行相關(guān)操作。

因此，我們強烈建議用戶使用 enforce-node-allocatable 默認配置的 pods 即可，并為系統(tǒng)和 kube 進程預留出適當?shù)馁Y源，以保持整體節(jié)點的可靠性，不需要進行 cgroup 約束，除非操作人員對系統(tǒng)非常了解。