Kubernetes-22：kubelet 驱逐策略详解

为什么要驱逐pod？

在可用计算资源较少时，kubelet为保证节点稳定性，会主动地结束一个或多个pod以回收短缺地资源，这在处理内存和磁盘这种不可压缩资源时，驱逐pod回收资源的策略，显得尤为重要。

可压缩资源 —— cpu，可压缩资源不会导致pod驱逐，因为在资源紧缺时系统内核会重新分配权重

不可压缩资源 —— 内存磁盘

Kubelet Eviction 策略的工作机制

kubelet预先监控本节点的资源使用，防止资源被耗尽，保证节点稳定性。
kubelet会预先Fail N(>=1)个Pod，以回收出现紧缺的资源。
kubelet在Fail一个pod时，kill掉pod内所有container，并设置pod.status.phase = Failed。
kubelet按照事先设定好的Eviction Threshold来触发驱逐动作，实现资源回收。

驱逐信号

pkg/kubelet/eviction/api/types.go源码中定义了以下几种驱逐信号：

Eviction Signal	Description
memory.available	node.status.capacity[memory] - node.stats.memory.workingSet
nodefs.available	node.stats.fs.available
nodefs.inodesFree	node.stats.fs.inodesFree
imagefs.available	node.stats.runtime.imagefs.available
imagefs.inodesFree	node.stats.runtime.imagefs.inodesFree
allocatableMemory.available	pod.allocatable - pod.workingSet
pid.available	node.MaxPID - node.NumOfRunningProcesses

上表主要涉及三个方面，memory、file system和pid。

其中kubelet支持2种file system类型的驱逐：

nodefs：kubelet 用来存储 pods 或 volume 和 daemon logs 的信息等
Imagesfs：用来存储 docker 镜像层或容器层数据的路径(read only layer and write layer)

驱逐策略

k8s中定义了两种驱逐策略，一种为软驱逐，一种为硬驱逐。

软驱逐(Soft Eviction Thresholds)

软驱逐机制表示，当node的内存/磁盘空间达到一定的阈值后，我要观察一段时间，如果改善到低于阈值就不进行驱逐，若这段时间一直高于阈值就进行驱逐。

一般由三个参数配合使用：

eviction-soft：触发软驱逐策略的阀值
eviction-soft-grace-period：触发软驱逐策略的阀值后等待的时间，如果在此时间内还未恢复到阀值以下，则会开始驱逐pod
eviction-max-pod-grace-period：达到软阈值之后，到驱逐一个 Pod 之前的最大宽限时间(单位 s )

硬驱逐(Hard Eviction Thresholds)

硬驱逐简单粗暴，没有宽限期，一旦达到阈值配置，kubelet立马回收关联的短缺资源，将pod kill掉，而不是优雅终止。

源码pkg/kubelet/apis/config/v1beta1/defaults_linux.go给出了默认的硬驱逐配置：

memory.available < 100Mi
nodefs.available < 10%
nodefs.inodesFree < 5%
imagefs.available < 15%

Pod驱逐流程

当资源使用情况触发了驱逐条件时，kubelet会启动一个任务去轮流停止运行中的pod，直到资源使用状况恢复到阈值以下。以硬驱逐为例，整体流程是：

每隔一段时间从cadvisor中获取资源使用情况，和定义的阀值进行对比，在 kubelet 中 --node-status-update-frequency 参数来定义获取上报的频率，默认为10s。
- 首先从运行中的pod里找到QoS策略最开放的类型 pod ；
- 然后根据 Pod 调度请求的被耗尽资源的消耗量来结合进行驱逐。
检查资源是否到达阀值以内，若还未满足，则再进行第二步。

Qos驱逐等级

当一个pod被创建,kubernetes会赋予它们以下类型的值之一

Guaranteed
Burstable
BestEffor

三种Qos类型优先级（由高到低）：Guaranteed > Burstable > BestEffort

从上到下,它们的质量会越来越低，质量越高，该pod就会尽量被保护，不被驱逐

满足以下条件的pod将会被赋予 Guaranteed QoS类型

pod中每个容器都必须包含内存请求和限制,并且值相等
pod中每个容器都必须包含cpu请求和限制,并且值相等

当符合以下条件时,一个pod会被赋予Burstable类型的QoS

Pod不符合 Guaranteed 类型的QoS要求
pod至少设置了内存或者cpu请任一

一个pod即没有内存限制或请求也没有cpu限制或请求,则会被赋予BestEffort

查看某pod的qos等级：

kubectl get pod -n kube-system  kube-apiserver-yq01 -o yaml | grep qos

  qosClass: Burstable

资源紧缺时，驱逐pod的优先级规则：

当 pod qos=BestEffort 时，消耗最多紧缺资源的 Pod 最先驱逐。
当 pod qos=Burstable 时，请求（request的值）最多紧缺资源的 Pod 会被驱逐，如果没有 Pod 超出他们的请求(比如说mem request的值为1G,但实际使用量并没有超过1G)，会驱逐资源消耗量最大的 Pod。
当 pod qos=Guaranteed 时，请求（request的值）最多紧缺资源的 Pod 被驱逐，如果没有 Pod 超出他们的请求，会驱逐资源消耗量最大的 Pod。
如果当磁盘空间/inodes紧缺时，就会通过 QoS 的等级基础上，选择消耗最多磁盘空间inodes的 Pod 进行驱逐。

问题拓展

1、如何更改kubelet的默认驱逐阀值呢？

硬阀值的设置：

将以下策略加入到/etc/kubernetes/kubelet.env即kublet启动参数即可

--eviction-hard=memory.available<256Mi,nodefs.available<1Gi,imagefs.available<1Gi \

--eviction-minimum-reclaim=memory.available=512Mi,nodefs.available=1Gi,imagefs.available=1Gi \

--eviction-pressure-transition-period=30s

第一行表示当memory<256Mi，nodefs<1G，imagesfs<1G，时才会触发硬驱逐策略

第二行表示最小驱逐回收策略，就是一旦驱逐策略被触发，则要一直驱逐直到低于此行策略的阀值为止，为了就是防止刚刚触发硬驱逐策略，驱逐完之后没一会资源又涨上来了，导致要反复驱逐的现象

第三行是为了防止node节点状态振荡

软阀值的设置：

--eviction-soft=memory.available<10%,nodefs.available<15%,imagefs.available<15% \

--eviction-soft-grace-period=memory.available=2m,nodefs.available=2m,imagefs.available=2m \

--eviction-max-pod-grace-period=30

第一行表示软驱逐阀值，使用百分比代替

第二行表示触发软驱逐后，等待执行的时间，若此时间内低于阀值，则不再进行驱逐

第三行为pod宽限时间

2、当资源不够或发生争夺有pod被驱逐后，pod的状态会变为Eviction，如果资源一直无法协调过来，或者资源真的不够用了，那么会产生大量的Eviction状态的Pod，会影响整个集群的使用，如何限制Eviction的Pod的数量呢？

此配置其实是由 kube-contoller-manager 来管理的，所以想要修改要修改kube-contoller-manager.yaml的参数，一般在/etc/kubernetes/manifests/kube-contoller-manager.yaml添加：

--terminated-pod-gc-threshold=1

此值设定了Eviction pod最大的产生个数，默认为12500，最小改为1，若为0，则表示没有限制。