Kubernetes Eviction Manager工作机制分析

摘要:为了极限的压榨资源,很多时候Kubernetes集群会运行一些Best-Effort Task,这样就会存在资源超配的情况,Kubernetes是如何控制Node上资源的使用,在压榨资源使用的同时又能保证Node的稳定性?本文就为你介绍其背后运行机制。我的下一篇博文,会对Kubelet Eviction Manager进行源码分析,感兴趣的同学可以关注。

研究过Kubernetes Resource QoS的同学,肯定会有一个疑问:QoS中会通过Pod QoS和OOM Killer进行资源的回收,当发生资源紧缺的时候。那为什么Kubernetes会再搞一个Kubelet Eviction机制,来做几乎同样的事呢?

首先,我们来谈一下kubelet通过OOM Killer来回收资源的缺点:

  • System OOM events本来就是对资源敏感的,它会stall这个Node直到完成了OOM Killing Process。
  • 当OOM Killer干掉某些containers之后,kubernetes Scheduler可能很快又会调度一个新的Pod到该Node上或者container 直接在node上restart,马上又会触发该Node上的OOM Killer启动OOM Killing Process,事情可能会没完没了的进行,这可不妙啊。

我们再来看看Kubelet Eviction有何不同:

  • Kubelet通过pro-actively监控并阻止Node上资源的耗尽,一旦触发Eviction Signals,就会直接Fail一个或者多个Pod以回收资源,而不是通过Linux OOM Killer这样本身耗资源的组件进行回收。
  • 这样的Eviction Signals的可配置的,可以做到Pro-actively。
  • 另外,被Evicted Pods会在其他Node上重新调度,而不会再次触发本Node上的再次Eviction。

下面,我们具体来研究一下Kubelet Eviction Policy的工作机制。

  • kubelet预先监控本节点的资源使用,并且阻止资源被耗尽,这样保证node的稳定性。
  • kubelet会预先Fail N(>= 1)个Pod以回收出现紧缺的资源。
  • kubelet会Fail一个Node时,会将Pod内所有Containners都kill掉,并把PodPhase设为Failed。
  • kubelet通过事先人为设定Eviction Thresholds来触发Eviction动作以回收资源。

Eviction Signals

支持如下Eviction Signals:

Eviction Signal Description
memory.available memory.available := node.status.capacity[memory] - node.stats.memory.workingSet
nodefs.available nodefs.available := node.stats.fs.available
nodefs.inodesFree nodefs.inodesFree := node.stats.fs.inodesFree
imagefs.available imagefs.available := node.stats.runtime.imagefs.available
imagefs.inodesFree imagefs.inodesFree := node.stats.runtime.imagefs.inodesFree

- kubelet目前支持一下两种filesystem,其中imagefs为可选的。Kubelet通过cAdvisor来自动发现这些filesystem。
- nodefs - Kubelet用来存储volume,logs等数据。
- imagefs - 容器运行时(dockerd/rkt等)用来存放镜像和容器的Writable Layer。

Eviction Thresholds

前面也提到,kubelet通过事先人为设定Eviction Thresholds来触发Eviction动作以回收资源。

  • Eviction Thresholds的形式为:<eviction-signal><operator><quantity>
  • quantity支持绝对值和相对百分比两种形式,比如:
    • memory.available<10%
    • memory.available<1Gi

Soft Eviction Thresholds

Soft Eviction Thresholds是什么意思?
它指的是,当Eviction Signal中值达到Soft Eviction Thresholds配置的值时,并不会马上触发Kubelet去Evict Pods,而是会等待一个用户配置的grace period之后,再触发。相关的配置有三个,如下:

  • eviction-soft - (e.g. memory.available<1.5Gi) 触发Soft Eviction的Evication Signal阈值。
  • eviction-soft-grace-period - (e.g. memory.available=1m30s) 当Eviction Signal的值达到配置eviction-soft值后,需要等待grace period,注意这期间,每10s会重新获取监控数据并维护Threshold的值。如果grace period最后一次监控数据仍然触发了阈值,才会再触发Evict Pods。这个参数就是配置这个grace period的。
  • eviction-max-pod-grace-period - (e.g. memory.available=30s) 这个是配置Evict Pods时,Pod Termination的Max Grace Period。如果待Evict的Pod指定了pod.Spec.TerminationGracePeriodSeconds,则取min(eviction-max-pod-grace-period, pod.Spec.TerminationGracePeriodSeconds)作为Pod Termination真正的Grace Period。

因此,从kubelet监控到的Eviction Signal达到指定的Soft Eviction Thresholds开始,到Pod真正被Kill,总共所需要的时间为:
sum(eviction-soft-grace-period + min(eviction-max-pod-grace-period, pod.Spec.TerminationGracePeriodSeconds))

Hard Eviction Thresholds

理解了Soft Eviction Thresholds,那么Hard Eviction Thresholds就很简单了,它是指:当Eviction Signal中值达到Hard Eviction Thresholds配置的值时,会立刻触发Kubelet去Evict Pods,并且也不会有Pod Termination Grace Period,而是立刻kill Pods,即使待Evict的Pod指定了pod.Spec.TerminationGracePeriodSeconds

总之,Hard Eviction Thresholds就是来硬的,一旦触发,kubelet立刻马上kill相关的pods。

因此,kubelet关于Hard Eviction Thresholds的配置也只有一个:

  • eviction-hard - (e.g. memory.available<1Gi) 这个值,要设置的比eviction-soft更低才有意义。

Eviction Monitoring Interval

kubelet会通过监控Eviction Signal的值,当达到配置的阈值时,就会触发Evict Pods。
kubelet对应的监控周期,就通过cAdvisor的housekeeping-interval配置的,默认10s。

Node Conditions

Hard Eviction ThresholdsSoft Eviction Thresholds被触及后,Kubelet会将对应的Eviction Signals映射到对应的Node Conditions,其映射关系如下:

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 threshold

kubelet映射了Node Condition之后,会继续按照--node-status-update-frequency(default 10s)配置的时间间隔,周期性的与kube-apiserver进行node status updates。

Oscillation of node conditions

想象一下,如果一个Node上监控到的Soft Eviction Signals的值,一直在eviction-soft水平线上下波动,那么Kubelet就会将该Node对应的Node Condition在true和false频繁切换。这可不是什么好事,它可能会带来kube-scheduler做出错误的调度决定。kubelet是怎么处理这种情况的呢?

很简单,Kubelet通过添加参数eviction-pressure-transition-period(default 5m0s)配置,使Kubelet在解除由Evicion Signal映射的Node Pressure之前,必须等待这么长的时间。

因此,逻辑就变成这样了:

  • Soft Evction Singal高于Soft Eviction Thresholds时,Kubelet还是会立刻设置对应的MemoryPressure Or DiskPressure为True。
  • 当MemoryPressure Or DiskPressure为True的前提下,发生了Soft Evction Singal低于Soft Eviction Thresholds的情况,则需要等待eviction-pressure-transition-period(default 5m0s)配置的这么长时间,才会将condition pressure切换回False。

一句话总结:Node Condition Pressure成为True容易,切换回False则要等eviction-pressure-transition-period

Eviction of Pods

Kubelet的Eviction流程概括如下:

  • 在每一个监控周期内,如果Eviction Thresholds被触及,则:
    • 获取候选Pod
    • Fail the Pod
    • 等待该Pod被Terminated
      如果该Pod由于种种原因没有被成功Terminated,Kubelet将会再选一个Pod进行Fail Operation。其中,Fail Pod的时候,Kubelet是通过调用容器运行时的KillPod接口,如果接口返回True,则认为Fail Pod成功,否则视为失败。

Eviction Strategy

kubelet根据Pod的QoS Class实现了一套默认的Evication策略,内容见我的另外一篇博文Kubernetes Resource QoS机制解读中介绍的“如何根据不同的QoS回收Resource”,这里不再赘述。

下面给出Eviction Strategy的图解:

这里写图片描述

Minimum eviction reclaim

有些情况下,eviction pods可能只能回收一小部分的资源就能使得Evication Signal的值低于Thresholds。但是,可能随着资源使用的波动或者新的调度Pod使得在该Node上很快又会触发evict pods的动作,eviction毕竟是耗时的动作,所以应该尽量避免这种情况的发生。

Kubelet是通过--eviction-minimum-reclaim(e.g. memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi)来控制每次Evict Pods后,Node上对应的Resource不仅要比Eviction Thresholds低,还要保证最少比Eviction Thresholds低--eviction-minimum-reclaim中配置的数量。

Node OOM Behavior

正常情况下,但Node上资源利用率很高时,Node的资源回收是会通过Kubelet Eviction触发完成。但是存在这么一种情况,Kubelet配置的Soft/Hard memory.available还没触发,却先触发了Node上linux kernel oom_killer,这时回收内存资源的请求就被kernel oom_killer处理了,而不会经过Kubelet Eviction去完成。

我的博文Kubernetes Resource QoS机制解读中介绍过,Kubelet根据Pod QoS给每个container都设置了oom_score_adj,整理如下:

Quality of Service oom_score_adj
Guaranteed -998
BestEffort 1000
Burstable min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

oom_killer根据container使用的内存占Node总内存的百分比计算得到该container的oom_score,然后再将该oom_sore和前面对应的oom_score_adj相加作为最终的oom_score,Node上所有containers的最终oom_score进行排名,将oom_score得分最高的container kill掉。通过如此方式进行资源回收。

oom_killer这样做的目标就是干掉QoS低的又消耗最多内存(相对request值)的容器首先被kill掉,如此回收内存。

不同于Kubelet Evict Pods的是,Node OOM Behavior存在一个缺点:如果Pod中某个容器被oom_killer干掉之后,会根据该容器的RestartPolicy决定是否restart这个容器。如果这是个有问题的容器,restart之后,可能又很快消耗大量内存进而触发了再次Node OOM Behavior,如此循环反复,该Node没有真正的回收到内存资源。

Scheduler

前面提到,Kubelet会定期的将Node Condition传给kube-apiserver并存于etcd。kube-scheduler watch到Node Condition Pressure之后,会根据以下策略,阻止更多Pods Bind到该Node。

Node Condition Scheduler Behavior
MemoryPressure No new BestEffort pods are scheduled to the node.
DiskPressure No new pods are scheduled to the node.

总结

  • Kubelet通过Eviction Signal来记录监控到的Node节点使用情况。
  • Eviction Signal支持:memory.available, nodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree。
  • 通过设置Hard Eviction ThresholdsSoft Eviction Thresholds相关参数来触发Kubelet进行Evict Pods的操作。
  • Evict Pods的时候根据Pod QoS和资源使用情况挑选Pods进行Kill。
  • Kubelet通过eviction-pressure-transition-period防止Node Condition来回切换引起scheduler做出错误的调度决定。
  • Kubelet通过--eviction-minimum-reclaim来保证每次进行资源回收后,Node的最少可用资源,以避免频繁被触发Evict Pods操作。
  • 当Node Condition为MemoryPressure时,Scheduler不会调度新的QoS Class为BestEffort的Pods到该Node。
  • 当Node Condition为DiskPressure时,Scheduler不会调度任何新的Pods到该Node。
阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/WaltonWang/article/details/55804309
个人分类: kubernetes
上一篇kube-proxy源码分析
下一篇Kubernetes Eviction Manager源码分析
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭