深究Kubernetes源码-Kubelet-5 节点压力驱逐Eviction流程分析

基于kubernetes1.26

1 功能和模块

https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

Node-Pressure Eviction是当Kubelet所管理的Node节点出现资源压力时，通过删除Pod/Image回收部分资源的功能，资源包括节点CPU，Memory，Filesystem Inode Free或Disk空间，当Kubelet执行Eviction时，将选中驱逐的Pod状态设置为Failed，并删除Pod。Kubelet Eviction不同于API Eviction，不受terminationGracePeriodSeconds和PDB影响，soft eviction会收到eviction-max-pod-grace-period配置项的影响。Pod被执行Eviction从节点上驱逐之后，如果Pod上级控制器是StatefulSet/ReplicaSet等，则会重新创建Pod取代被驱逐Pod。

Eviction共处理6类触发信号（eviction-signal）：

• memory.available：可用内存capacity - workingset ，默认100M

• nodefs.available：可用磁盘空间， 默认10%

• nodefs.inodesFree：可用文件系统inode，默认5%

• imagefs.available：可用镜像磁盘空间，默认15%

• imagefs.inodesFree：可用镜像文件系统inode

• pid.available：可用pid，rlimit.maxpid-rlimit.curproc

通过2个主要配置项控制：

--eviction-hard or --eviction-soft ：驱逐出发阈值，格式为 <eviction-signal> <operator> <quantity>，例如 memory.available < 1G

--eviction-minimum-reclaim：执行最少回收资源数，避免频繁触发Eviction

其他相关配置项：

--housekeeping-interval：evction触发间隔，默认10s

--node-status-update-frequency：Kubelet更新Node状态间隔

EvctionManager核心类图分析，Manager主要包含ImageGC，ContainerGC和ThresholdNotifier三个模块：

• ImageCG，执行镜像回收

• ContainerGC，执行容器回收

• ThresholdNotifitier，通过Memory CGroup反向触发执行Eviction，应对突发Memory使用量高。

2 流程分析

在Kubelet启动时以协程的方式运行，如果是Linux环境配置了KernelMemcgNotification，则额外启动MemoryTheasholdNotifier监听Linux的反响触发事件，如果没有配置则启动协程定期执行synchronzie。

synchronize是evction的核心流程，首先判断是否达到阈值触发条件，如果达到则先执行Node级别的资源回收reclaimNodeLevelResources，Node级别资源回收仍不满足，则继续执行Pod驱逐evictPod。

reclaimNodeLevelResources，调用注册的nodeReclaimFuncs，只能处理DiskPressure的情况，执行的是磁盘空间和inode的回收，并不能回收Memory。分为是否支持ImageFs：

• 支持ImageFs，若触发nodefs阈值，回收死亡的Pod和容器，若触发imagefs阈值，回收未使用的镜像

• 不支持imageFs，若触发nodefs阈值，首先回收死亡的Pod和容器，然后删除未使用的镜像

evictPod，根据Pod的eviction排名，调用killPodFunc，evictPod核心在于对Pod进行rank排序，rank函数也是通过调用buildSignalToRankFunc进行注册，主要是根据Pod优先级以及资源占用情况进行排序。

Pod回收排序参数如下：

1. Pod资源使用是否超过了Request值

2. Pod的Priority

3. Pod 相对于请求的资源使用情况

因此，kubelet 按以下顺序排列和驱逐 Pod：

1. 首先考虑资源使用量超过其请求的 BestEffort 或 Burstable Pod。 这些 Pod 会根据它们的优先级以及它们的资源使用级别超过其请求的程度被逐出。

2. 资源使用量少于请求量的 Guaranteed Pod 和 Burstable Pod 根据其优先级被最后驱逐。