为什么要驱逐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 镜像层或容器层数据的路径(readOnly 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,则表示没有限制。