k8s的资源管理

fzu_huang

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

clipboard.png
如上图,当软驱逐或者硬驱逐触发时,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进行驱逐工作后要达到的效果是低于阈值多少

阅读 6.4k

kubernetes_docker集群管理
我学到的关于k8s和docker的种种。 仅作学习笔记用,不会发布在别的地方
272 声望
105 粉丝
0 条评论
你知道吗?

272 声望
105 粉丝
文章目录
宣传栏