kubernets eviction策略

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

如上图，当软驱逐或者硬驱逐触发时，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也不会恢复。