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