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 約束，除非操作人員對系統非常了解。