曾国藩:一勤天下无难事

K8S的 QoS策略

2019.02.27

QoS

k8s中对容器的资源分配有三种策略:

  • Guaranteed 。该策略下,pod.spec.containers[].resources中会存在cpu或memory的request和limit。顾名思义是该容器对资源的最低要求和最高使用量限制。如果我们配置了limit,没有配置request,默认会以limit的值来定义request。具体的配置可以参考以前的这篇笔记。
  • BestEffort。当pod的描述文件中没有resource.limit、resource.request相关的配置时,意味着这个容器想跑多少资源就跑多少资源,其资源使用上限实际上即所在node的capacity。
  • Burstable。当resource.limit和resource.request以上述两种方式以外的形式配置的时候,就会采用本模式。 QoS目前只用cpu和memory来描述,其中cpu可压缩资源,当一个容器的cpu使用率超过limit时会被进行流控,而当内存超过limit时则会被oom_kill。这里kubelet是通过自己计算容器的oom_score,确认相应的linux进程的oom_adj,oom_adj最高的进程最先被oom_kill。 Guaranteed模式的容器oom_score最小:-998,对应的oom_adj为0或1,BestEffort模式则是1000,Burstable模式的oom_score随着其内存使用状况浮动,但会处在2-1000之间。

因此我们可以看出,当某个node内存被严重消耗时,BestEffort策略的pod会最先被kubelet杀死,其次Burstable(该策略的pods如有多个,也是按照内存使用率来由高到低地终止),再其次Guaranteed。

kubelet的eviction机制

完全依赖于oom_kill并不是一个很好的方案,一来对于cpu要求高的容器没有作用,二来单纯将pod杀死,并不能根本上解决困局,比如pod占用node绝大部分内存,加入pod被kill后再次调度到这个node上,oom的情况还会复现。所以kubelet增加了一套驱逐机制。 eviction机制适用于:

  • memory.available
  • nodefs.available
  • nodefs.inodesFree
  • imagefs.available
  • imagefs.inodesFree

分别对应于node目前可用内存、node上用于kubelet运行日志、容器挂载磁盘所使用的的文件系统的余量和inode余量、node上用于存放容器镜像和读写层的文件系统的余量、inode余量。

eviction中要设置触发驱逐的阈值Eviction Thresholds,这个阈值的配置可以是一个定值或一个百分比。如:

memory.available<10%
memory.available<1Gi

Soft Eviction Thresholds

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

这里阈值通过参数--eviction-soft配置,样例如上;观察时间通过参数--eviction-soft-grace-period进行配置,如1m30s。

另外还有一个参数eviction-max-pod-grace-period,该参数会影响到要被驱逐的pod的termination time,即终止该pod的容器要花费的时间。

Hard Eviction Thresholds

强制驱逐机制则简单的多,一旦达到阈值,立刻把pod从本地kill,驱逐eviction-hard参数配置,样例亦如上。

pod eviction

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

  • 每隔一段时间从cadvisor中获取资源使用情况,发现触发了阈值;
  • 从运行中的pod里找到QoS策略最开放的一个,比如策略为bestEffort的一个pod(即便这个pod没有吃多少内存,大部分内存是另一个策略为burstable,但内存使用率也很高的pod),kubelet停止该pod对应的所有容器,然后将pod状态更新为Failed。如果该pod长时间没有被成功kill掉,kubelet会再找一个pod进行驱逐。
  • 检查内存用量是否恢复到阈值以下,如果没有,则重复第二步(这里就要干掉那个罪魁祸首了)。一直到内存使用情况恢复到阈值以下为止。

有几个要注意的点是:

  • kubelet挑选pod进行驱逐的策略,就是按照QoS的策略开放度排序,而同一个QoS的多个pod中,kubelet会优先驱逐使用触发指标资源最多的一个。
  • 磁盘的使用不像memory有通过request和limit进行配置,磁盘用量可以认为是一种QoS策略为BestEffort的资源。当触发磁盘资源不足时,kubelet会做一些额外的工作,比如清理已经dead的pod的容器日志,清理没有被使用的容器镜像,当然kubelet也会挑磁盘使用量(包括挂载本地volume空间+容器log大小,若是imagefs指标超额,此处还要加上容器运行时读写层的文件大小)最大的一个pod进行驱逐。

node condition

Node Condition Eviction Signal Description
MemoryPressure memory.available Available memory on the node has satisfied an eviction threshold
DiskPressure nodefs.available, nodefs.inodesFree, imagefs.available, or imagefs.inodesFree Available disk space and inodes on either the node’s root filesystem or image filesystem has satisfied an eviction thresh

如上图,当软驱逐或者硬驱逐触发时,kubelet会尝试干掉一个pod,并且会将自身的状态从驱逐的指标信息中映射过来,比如内存使用超标触发驱逐,node的condtion就会变成memoryPressure,这个condition伴随的kubelet定时的心跳报文上传到master,记录在etcd中。在调度器进行调度时,会以这些condition作为调度条件的参考。比如,处于diskPressure的node,调度器就不会再将任何pod调度上去。否则一旦磁盘空间用满,node上的容器可能会严重崩溃。

但如果node的内存在阈值上下波动,condition被反复更新为pressure或正常,那么pod被误调度到node上也会很耽误事,所以用eviction-pressure-transition-period参数指定触发eviction后condition更新一次后要保留改状态的最小时长。在这个时长范围内即便资源使用下降到阈值以下,condition也不会恢复。

其他

Minimum eviction reclaim 我们担心node可能驱逐了一个小pod后,指标就只是稍低于阈值,那么一旦其他pod的指标稍一上来,该node就又要进行eviction。所以用这个参数: --eviction-minimum-reclaim(值如"memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi")进行限定,一旦发生了eviction,必须要保证node的某指标用量低于(该指标阈值-本参数指定的该指标值)才认为node恢复正常,否则还要接着驱逐pod。 简单的说,该参数表示的是node进行驱逐工作后要达到的效果是低于阈值多少。