和oom的对比
首先对比一下 evictionManager 和 oom
* System OOM events本来就是对资源敏感的，它会stall这个Node直到完成了OOM Killing Process。
* 当OOM Killer干掉某些containers之后，kubernetes Scheduler可能很快又会调度一个新的Pod到该Node上或者container 直接在node上restart，马上又会触发该Node上的OOM Killer启动OOM Killing Process，事情可能会没完没了的进行。
接下来看看 evictionManager
* Kubelet通过pro-actively监控并阻止Node上资源的耗尽，一旦触发Eviction Signals，就会直接Fail一个或者多个Pod以回收资源，而不是通过Linux OOM Killer这样本身耗资源的组件进行回收。
* 这样的Eviction Signals的可配置的，可以做到Pro-actively。
* 另外，被Evicted Pods会在其他Node上重新调度，而不会再次触发本Node上的再次Eviction。
工作机制
* kubelet预先监控本节点的资源使用，并且阻止资源被耗尽，这样保证node的稳定性。
kubelet会通过监控Eviction Signal的值，当达到配置的阈值时，就会触发Evict Pods。 kubelet对应的监控周期，就通过cAdvisor的 evictionMonitoringPeriod 配置的，默认10s。
如果一个Node上监控到的Soft Eviction Signals的值，一直在eviction-soft水平线上下波动，那么为了避免 Node Condition 在true和false频繁切换，配置了 EvictionPressureTransitionPeriod 的值。一旦 MemoryPressure Or DiskPressure为True的前提下， 发生了Soft Evction Singal低于Soft Eviction Thresholds的情况，则需要等待配置时间（默认5m）才会切回 false。
* kubelet会预先Fail N(>= 1)个Pod以回收出现紧缺的资源。
如果 eviction pods 回收了一小部分资源就满足了要求，可能随着资源使用的波动或者新的调度Pod使得在该Node上很快又会触发evict pods的动作，这个是非常不划算的。所以在回收资源的时候，不仅要保证比 Eviction Thresholds 低，还要比它低 EvictionMinimumReclaim 所配置的数量。
* kubelet会Fail一个Pod时，会将Pod内所有Containners都kill掉，并把PodPhase设为Failed。
在每一个监控周期内，如果Eviction Thresholds被触及，则：
获取候选Pod
Fail the Pod
等待该Pod被Terminated 如果该Pod由于种种原因没有被成功Terminated，Kubelet将会再选一个Pod进行Fail Operation。其中，Fail Pod的时候，Kubelet是通过调用容器运行时的KillPod接口，如果接口返回True，则认为Fail Pod成功，否则视为失败。
* kubelet通过事先人为设定Eviction Thresholds来触发Eviction动作以回收资源。
Eviction Thresholds 支持绝对值和相对百分比两种形式
* memory.available<10%
* memory.available<1Gi
Soft Eviction Thresholds 指的是，当Eviction Signal中值达到配置的值时，并不会马上触发Kubelet去Evict Pods，而是会等待一个用户配置的grace period之后，再触发。
Hard Eviction Thresholds 就是， 当Eviction Signal中值达到Hard Eviction Thresholds配置的值时，会立刻触发Kubelet去Evict Pods 。 这个值，要设置的比eviction-soft更低才有意义。
代码学习
1. evictionManager 的创建
首先，Kubelet 在初始化的时候，初始化一个 evictionManager 对象；
然后，在初始化 runtime 的时候启动这个 evictionManager；
接下来，看一下 manager 的定义；
managerImpl struct {
clock clock.Clock
config Config // 配置，包括
PressureTransitionPeriod( –eviction-pressure-transition-period)
MaxPodGracePeriodSeconds(–eviction-max-pod-grace-period)
Thresholds(–eviction-hard, –eviction-soft)
KernelMemcgNotification(–experimental-kernel-memcg-notification)
killPodFunc KillPodFunc // evict pod时kill pod的接口，kubelet NewManager的时候，赋值为killPodNow方法
imageGC ImageGC // 当node出现diskPressure condition时，imageGC进行unused images删除操作以回收disk space
containerGC ContainerGC // 使用 containerGC 来对容器进行删除操作
sync.RWMutex
nodeConditions []v1.NodeConditionType
nodeConditionsLastObservedAt nodeConditionsObservedAt
nodeRef *v1.ObjectReference // 记录有关节点的事件
recorder record.EventRecorder // used to measure usage stats on system
summaryProvider stats.SummaryProvider // 提供node和node上所有pods的最新status数据汇总，既NodeStats and []PodStats。
thresholdsFirstObservedAt thresholdsObservedAt // 记录threshold第一次观察到的时间
thresholdsMet []evictionapi.Threshold // 保存已经触发但还没解决的Thresholds，包括那些处于grace period等待阶段的Thresholds。
resourceToRankFunc map[v1.ResourceName]rankFunc // 定义各种Resource进行evict 挑选时的排名方法。
resourceToNodeReclaimFuncs map[v1.ResourceName]nodeReclaimFuncs // 定义各种Resource进行回收时调用的方法。
lastObservations signalObservations // 上一次获取的eviction signal的记录，确保每次更新thresholds时都是按照正确的时间序列进行。
notifiersInitialized bool // 表示threshold notifier是否已经初始化，以确定是否可以利用kernel memcg notification功能来提高evict的响应速度。目前创建manager时该值为false，是否要利用kernel memcg notification，完全取决于kubelet的--experimental-kernel-memcg-notification参数。
dedicatedImageFs *bool
}
NewManager不但返回evictionManager对象，还返回了一个lifecycle.PodAdmitHandler实例evictionAdmitHandler，它其实和evictionManager的内容相同，但是不同的两个实例。evictionAdmitHandler用来kubelet创建Pod前进行准入检查，满足条件后才会继续创建Pod，通过 Admit 方法来检查
这里EvictionManager就影响了 Pod调度的逻辑，在机器有压力的时候，禁止了新的pod产生。
2. evictionManager 的运行
start 方法，启动了一个goroutine，来调用 synchronize 方法，获取已经被驱逐的pods，并等待清理操作完成。
在 synchronize 方法中
注册Evict Pod时各种Resource的排名函数 (对于内存，硬盘的使用量进行排序)
m.resourceToRankFunc = buildResourceToRankFunc(hasImageFs)
注册回收Node Resource的Reclaim函数 (清理所有没有用到的容器和镜像)
m.resourceToNodeReclaimFuncs = buildResourceToNodeReclaimFuncs(m.imageGC, m.containerGC, hasImageFs)
通过makeSignalObservations从cAdvisor中获取Eviction Signal Observation和Pod的StatsFunc(后续对Pods进行Rank时需要用)
observations, statsFunc, err := makeSignalObservations(m.summaryProvider, capacityProvider, activePods)
如果kubelet配置了--experimental-kernel-memcg-notification且为true
if m.config.KernelMemcgNotification && !m.notifiersInitialized {
通过startMemoryThresholdNotifier启动soft & hard memory notification 当system usage第一时间达到soft & hard memory thresholds时，会立刻通知kubelet，并触发evictionManager.synchronize进行资源回收的流程。这样提高了eviction的实时性。（下面调用时候的最后一个参数即handler）
err = startMemoryThresholdNotifier(m.config.Thresholds, observations, false, func(desc string) { m.synchronize(diskInfoProvider, podFunc, capacityProvider)})
err = startMemoryThresholdNotifier(m.config.Thresholds, observations, true, func(desc string) { m.synchronize(diskInfoProvider, podFunc, capacityProvider)})
}
根据从cAdvisor数据计算得到的Observation（observasions）和配置的thresholds通过thresholdsMet计算得到此次Met的thresholds
thresholds = thresholdsMet(thresholds, observations, false)
再根据从cAdvisor数据计算得到的Observation（observasions）和thresholdsMet通过thresholdsMet计算得到已记录但还没解决的thresholds，然后与上一步中的thresholds进行合并。
thresholdsNotYetResolved := thresholdsMet(m.thresholdsMet, observations, true)
根据lastObservations中Signal的时间，对比observasions的中Signal中的时间，过滤thresholds。
thresholds = mergeThresholds(thresholds, thresholdsNotYetResolved)
更新thresholdsFirstObservedAt, nodeConditions
nodeConditionsLastObservedAt := nodeConditionsLastObservedAt(nodeConditions, m.nodeConditionsLastObservedAt, now)
nodeConditions = nodeConditionsObservedSince(nodeConditionsLastObservedAt, m.config.PressureTransitionPeriod, now)
过滤出那些从observed time到now，已经历过grace period时间的thresholds。
thresholds = thresholdsMetGracePeriod(thresholdsFirstObservedAt, now)
更新evictionManager对象的内部数据: nodeConditions，thresholdsFirstObservedAt，nodeConditionsLastObservedAt，thresholds，observations。
m.nodeConditions = nodeConditions
m.thresholdsFirstObservedAt = thresholdsFirstObservedAt
m.nodeConditionsLastObservedAt = nodeConditionsLastObservedAt
m.thresholdsMet = thresholds
m.lastObservations = observations
根据thresholds得到starvedResources
starvedResources := getStarvedResources(thresholds)
进行排序，如果memory属于starvedResources，则memory排序第一
sort.Sort(byEvictionPriority(starvedResources))
取starvedResources排第一的Resource，调用reclaimNodeLevelResources对Node上这种Resource进行资源回收。如果回收完后，available满足thresholdValue+evictionMinimumReclaim,则流程结束，不再evict user-pods
resourceToReclaim := starvedResources[0]
m.reclaimNodeLevelResources(resourceToReclaim, observations)
如果reclaimNodeLevelResources后，还不足以达到要求，则会继续evict user-pods，首先根据前面buildResourceToRankFunc注册的方法对所有active Pods进行排序
rank, ok := m.resourceToRankFunc[resourceToReclaim]
rank(activePods, statsFunc)
按照前面的排序，顺序的调用killPodNow将选出的pod干掉。如果kill某个pod失败，则会跳过这个pod，再按顺序挑下一个pod进行kill。只要某个pod kill成功，就返回结束，也就是说这个流程中，最多只会kill最多一个Pod
for i := range activePods {
m.killPodFunc(pod, status, &gracePeriodOverride)
return []*v1.Pod{pod}
}
其中，资源回收 reclaimNodeLevelResources 就是调用 GC 的方法进行资源的回收。
killPodNow 则调用了 podWorkers.UpdatePod 方法进行pod的驱逐。
一些总结
Kubelet通过Eviction Signal来记录监控到的Node节点使用情况。
Eviction Signal支持：memory.available, nodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree。
通过设置Hard Eviction Thresholds和Soft 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。
