kubernetes/k8s驱逐机制总结篇
概述
k8s的驱逐机制是指在某些场景下，如node节点notReady、node节点压力较大等，将pod从某个node节点驱逐掉，让pod的上层控制器重新创建出新的pod来重新调度到其他node节点。这里也将kube-scheduler的抢占调度纳入到了驱逐的讨论范围内，因为当调度高优先级的pod时发现资源不足，会驱逐掉node节点上原有的低优先级的pod。
根据发起驱逐的组件，驱逐可以分为3类：
（1）由kubelet发起的驱逐：节点压力驱逐；kubelet周期性检查自身节点资源压力，当节点压力较大时，会驱逐自身node节点上的pod，以回收资源，降低节点资源压力；
（2）由kube-controller-manager发起的驱逐：当开启了污点驱逐时，node上有NoExecute污点后，立马驱逐不能容忍污点的pod，对于能容忍该污点的pod，则等待pod上配置的污点容忍时间里的最小值后，pod会被驱逐；当未开启污点驱逐时，node的ready Condition值为false或unknown且已经持续了一段时间（通过kcm启动参数--pod-eviction-timeout配置，默认5分钟）后，对该node上的pod做驱逐操作；
（3）由kube-scheduler发起的驱逐：抢占调度驱逐；当一个高优先级的pod调度失败后，kube-scheduler会驱逐走（删除）某个Node 上的一些低优先级的pod，这样一来就可以保证高优先级pod的调度。
1.kubelet发起的驱逐
kubelet发起的驱逐为kubelet节点压力驱逐；
kubelet监控集群节点的 CPU、内存、磁盘空间和文件系统的inode 等资源，根据kubelet启动参数中的驱逐策略配置，当这些资源中的一个或者多个达到特定的消耗水平，kubelet 可以主动地驱逐节点上一个或者多个pod，以回收资源，降低节点资源压力。
驱逐信号
节点上的memory、nodefs、pid等资源都有驱逐信号，kubelet通过将驱逐信号与驱逐策略进行比较来做出驱逐决定；
驱逐策略
kubelet节点压力驱逐包括了两种，软驱逐和硬驱逐；
软驱逐
软驱逐机制表示，当node节点的memory、nodefs等资源达到一定的阈值后，需要持续观察一段时间（宽限期），如果期间该资源又恢复到低于阈值，则不进行pod的驱逐，若高于阈值持续了一段时间（宽限期），则触发pod的驱逐。
硬驱逐
硬驱逐策略没有宽限期，当达到硬驱逐条件时，kubelet会立即触发pod的驱逐，而不是优雅终止。
pod驱逐流程
（1）根据kubelet启动参数配置，获取驱逐策略配置；
（2）从cAdvisor、CRIRuntimes获取各种统计信息，如节点上各个资源的总量以及使用量情况、容器的资源声明及使用量情况等；
（3）比对驱逐策略配置以及上述的各种资源统计信息，筛选出会触发驱逐的驱逐信号；
（4）将上面筛选出来的驱逐信号做排序，将内存驱逐信号排在所有其他信号之前，并从排序后的结果中取出第一个驱逐信号；
（5）主动尝试回收fs、inode资源，如果回收的资源足够，则直接return，不需要往下执行驱逐pod的逻辑；
（6）根据最终筛选出来的那一个驱逐信号，使用对应的排序函数给pod列表进行排序；
（7）遍历排序后的pod列表，尝试驱逐pod；
几个注意点：
（1）每次的驱逐流程，最多只驱逐一个pod；
（2）一次驱逐流程完成后，如果本次流程有驱逐pod，则马上继续循环执行pod驱逐流程，如果本次驱逐流程没有驱逐pod，则等待10s后再循环执行pod驱逐流程；
（3）驱逐pod，只是将pod.status.phase值更新为Failed，并附上驱逐reason：Evicted以及触发驱逐的详细信息，不会删除pod；而pod.status.phase值被更新为Failed后，replicaset controller会再次创建出新的pod调用到其他节点上，达到驱逐pod的效果；
2.kube-controller-manager发起的驱逐
kube-controller-manager驱逐主要依靠NodeLifecycleController以及其中的TaintManager；
kube-controller-manager驱逐分类
（1）开启了污点驱逐：node上有NoExecute污点后，立马驱逐不能容忍污点的pod，对于能容忍该污点的pod，则等待pod上配置的污点容忍时间里的最小值后，pod会被驱逐；
（2）未开启污点驱逐：当node的ready Condition值为false或unknown且已经持续了一段时间（通过kcm启动参数--pod-eviction-timeout配置，默认5分钟）时，对该node上的pod做驱逐操作；
NodeLifecycleController
NodeLifecycleController主要负责以下工作：
（1）定期检查node的心跳上报，某个node间隔一定时间都没有心跳上报时，更新node的ready condition值为false或unknown，开启了污点驱逐的情况下，给该node添加NoExecute的污点；
（2）未开启污点驱逐时的pod驱逐工作；
（3）根据kcm启动参数配置，决定是否启动TaintManager；
TaintManager
TaintManager负责pod的污点驱逐工作，当node上有NoExecute污点后，立马驱逐不能容忍污点的pod，对于能容忍该污点的pod，则等待pod上配置的污点容忍时间里的最小值后，pod会被驱逐；
3.kube-scheduler发起的驱逐
kube-scheduler发起的驱逐为抢占调度驱逐；
当一个高优先级的pod调度失败后，kube-scheduler会驱逐走（删除）某个Node 上的一些低优先级的pod，这样一来就可以保证高优先级pod的调度。
关于pod优先级，具体请参考：https://kubernetes.io/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/
抢占发生的原因，一定是一个高优先级的pod调度失败。
kube-scheduler抢占调度功能可通过配置控制是否开启。
kube-scheduler抢占调度驱逐流程
优先级和抢占机制，解决的是 Pod 调度失败时该怎么办的问题。
正常情况下，当一个 pod 调度失败后，就会被暂时 “搁置” 处于 pending 状态，直到 pod 被更新或者集群状态发生变化，调度器才会对这个 pod 进行重新调度。
但是有的时候，我们希望给pod分等级，即分优先级。当一个高优先级的 Pod 调度失败后，该 Pod 并不会被“搁置”，而是会“挤走”某个 Node 上的一些低优先级的 Pod，这样一来就可以保证高优先级 Pod 会优先调度成功。
关于pod优先级，具体请参考：https://kubernetes.io/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/
抢占发生的原因，一定是一个高优先级的 pod 调度失败，我们称这个 pod 为“抢占者”，称被抢占的 pod 为“牺牲者”(victims)。
抢占调度驱逐的核心处理流程
下方处理流程图展示了kube-scheduler抢占调度驱逐的核心处理步骤，在开始抢占逻辑处理之前，会先进行抢占调度功能是否开启的判断。
k8s驱逐机制详细分析
k8s驱逐篇博客
目录
（1）k8s QoS与pod驱逐；
（2）kubelet节点压力驱逐分析；
（3）kube-scheduler抢占调度驱逐分析；
（4）kube-controller-manager驱逐分析；
（5）kube-scheduler抢占调度源码分析；
（6）kube-controller-manager驱逐源码分析；
（7）kube-controller-manager TaintManager源码分析；