[[422195]]

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

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

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

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

Node Allocatable

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

我們可以通過 kubectl describe node 命令查看節點可分配資源的數據：

➜  ~ 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 兩項內容，其中的 Allocatable 就是節點可被分配的資源，我們這里沒有配置資源預留，所以默認情況下 Capacity 與 Allocatable 的值基本上是一致的。下圖顯示了可分配資源和資源預留之間的關系：

Node Allocatable

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

節點可分配資源的計算方式為：

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

調度到某個節點上的 Pod 的 requests 總和不能超過該節點的 allocatable。

配置資源預留

比如我們現在需要為系統預留一定的資源，我們可以使用如下的幾個 kubelet 參數來進行配置：

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

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

apiVersion: kubelet.config.k8s.io/v1beta1 
...... 
enforceNodeAllocatable: 
- pods 
kubeReserved:  # 配置 kube 資源預留 
  cpu: 500m 
  memory: 1Gi 
  ephemeral-storage: 1Gi 
systemReserved:  # 配置系統資源預留 
  memory: 1Gi 
evictionHard:  # 配置硬驅逐閾值 
  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 

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

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

再通過查看 kubepods.slice(systemd 驅動是以 .slice 結尾)cgroup 中對節點上所有 Pod 內存的限制，該值決定了 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 對該節點上的 Pod 進行驅逐，OOM 是指 cgroup 對進程進行 kill

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

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

• 首先驅逐沒有設置資源限制的 Pod
• 然后驅逐資源上限和資源下限不一樣的 Pod
• 最后驅逐資源上限等資源下限的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 執行 Allocatable 可分配約束，如果所有 Pod 的總用量超過了 Allocatable，那么驅逐 Pod 的措施將被執行，我們可以可通過設置 kubelet --enforce-node-allocatable 標志值為 pods 控制這個措施。

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

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

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

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