Kubernetes Eviction Manager工作机制是什么

这篇文章主要讲解了“Kubernetes Eviction Manager工作机制是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Kubernetes Eviction Manager工作机制是什么”吧！

首先，我们来谈一下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:

• 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 Thresholds或Soft Eviction Thresholds被触及后，Kubelet会将对应的Eviction Signals映射到对应的Node Conditions，其映射关系如下：

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，整理如下：

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。

感谢各位的阅读，以上就是“Kubernetes Eviction Manager工作机制是什么”的内容了，经过本文的学习后，相信大家对Kubernetes Eviction Manager工作机制是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！