kubernetes中node心跳处理逻辑分析

最近在查看一个kubernetes集群中node not ready的奇怪现象，顺便阅读了一下kubernetes kube-controller-manager中管理node健康状态的组件node lifecycle controller。我们知道kubernetes是典型的master-slave架构，master node负责整个集群元数据的管理，然后将具体的启动执行pod的任务分发给各个salve node执行，各个salve node会定期与master通过心跳信息来告知自己的存活状态。其中slave node上负责心跳的是kubelet程序, 他会定期更新apiserver中node lease或者node status数据，然后kube-controller-manager会监听这些信息变化，如果一个node很长时间都没有进行状态更新，那么我们就可以认为该node发生了异常，需要进行一些容错处理，将该node上面的pod进行安全的驱逐，使这些pod到其他node上面进行重建。这部分工作是由node lifecycel controller模块负责。

在目前的版本(v1.16)中，默认开启了TaintBasedEvictions, TaintNodesByCondition这两个feature gate，则所有node生命周期管理都是通过condition + taint的方式进行管理。其主要逻辑由三部分组成:

不断地检查所有node状态，设置对应的condition
不断地根据node condition 设置对应的taint
不断地根据taint驱逐node上面的pod

一. 检查node状态

检查node状态其实就是循环调用monitorNodeHealth函数，该函数首先调用tryUpdateNodeHealth检查每个node是否还有心跳，然后判断如果没有心跳则设置对应的condtion。

node lifecycle controller内部会维护一个nodeHealthMap 数据结构来保存所有node的心跳信息，每次心跳之后都会更新这个结构体，其中最重要的信息就是每个node上次心跳时间probeTimestamp，如果该timestamp很长时间都没有更新(超过--node-monitor-grace-period参数指定的值)，则认为该node可能已经挂了，设置node的所有condition为unknown状态。

    gracePeriod, observedReadyCondition, currentReadyCondition, err = nc.tryUpdateNodeHealth(node)

tryUpdateNodeHealth传入的参数为每个要检查的node, 返回值中observedReadyCondition为当前从apiserver中获取到的数据，也就是kubelet上报上来的最新的node信息，　currentReadyCondition为修正过的数据。举个例子，如果node很长时间没有心跳的话，observedReadyCondition中nodeReadyCondion为true, 但是currentReadyCondion中所有的conditon已经被修正的实际状态unknown了。

如果observedReadyCondition 状态为true, 而currentReadyCondition状态不为true, 则说明node状态状态发生变化，由ready变为not-ready。此时不光会更新node condition，还会将该node上所有的pod状态设置为not ready，这样的话，如果有对应的service资源选中该pod, 流量就可以从service上摘除了，但是此时并不会直接删除pod。

node lifecycle controller会根据currentReadyCondition的状态将该node加入到zoneNoExecuteTainter的队列中，等待后面设置taint。如果此时已经有了taint的话则会直接更新。zoneNoExecuteTainter队列的出队速度是根据node所处zone状态决定的，主要是为了防止出现集群级别的故障时，node lifecycle controller进行误判，例如交换机，loadbalancer等故障时，防止node lifecycle controller错误地认为所有node都不健康而大规模的设置taint进而导致错误地驱逐很多pod，造成更大的故障。

设置出队速率由handleDisruption函数中来处理，首先会选择出来各个zone中不健康的node, 并确定当前zone所处的状态。分为以下几种情况：

Initial:　zone刚加入到集群中，初始化完成。
Normal: zone处于正常状态
FullDisruption: 该zone中所有的node都notReady了
PartialDisruption: 该zone中部分node notReady，此时已经超过了unhealthyZoneThreshold设置的阈值

对于上述不同状态所设置不同的rate limiter,　从而决定出队速度。该速率由函数setLimiterInZone决定具体数值，具体规则是:

当所有zone都处于FullDisruption时，此时limiter为0
当只有部分zone处于FullDisruption时，此时limiter为正常速率: --node-eviction-rate
如果某个zone处于PartialDisruption时，则此时limiter为二级速率：--secondary-node-eviction-rate

二. 设置node taint

根据node condition设置taint主要由两个循环来负责, 这两个循环在程序启动后会不断执行：

doNodeProcessingPassWorker中主要的逻辑就是： doNoScheduleTaintingPass, 该函数会根据node当前的condition设置unschedulable的taint，便于调度器根据该值进行调度决策，不再调度新pod至该node。
doNoExecuteTaintingPass 会不断地从上面提到的zoneNoExecuteTainter队列中获取元素进行处理，根据node condition设置对应的NotReady或Unreachable的taint, 如果NodeReadycondition为false则taint为NotReady, 如果为unknown，则taint为Unreachable, 这两种状态只能同时存在一种！

上面提到从zoneNoExecuteTainter队列中出队时是有一定的速率限制，防止大规模快速驱逐pod。该元素是由RateLimitedTimedQueue数据结构来实现:

// RateLimitedTimedQueue is a unique item priority queue ordered by

// the expected next time of execution. It is also rate limited.

type RateLimitedTimedQueue struct {

	queue       UniqueQueue

	limiterLock sync.Mutex

	limiter     flowcontrol.RateLimiter

}

从其定义就可以说明了这是一个　去重的优先级队列，　对于每个加入到其中的node根据执行时间(此处即为加入时间)进行排序，优先级队列肯定是通过heap数据结构来实现，而去重则通过set数据结构来实现。在每次doNoExecuteTaintingPass执行的时候，首先尽力从TokenBucketRateLimiter中获取token，然后从队头获取元素进行处理，这样就能控制速度地依次处理最先加入的node了。

三. 驱逐pod

在node lifecycle controller启动的时候，会启动一个NoExecuteTaintManager。　该模块负责不断获取node taint信息，然后删除其上的pod。

首先会利用informer会监听pod和node的各种事件，每个变化都会出发对应的update事件。分为两类: 1.优先处理nodeUpdate事件; 2.然后是podUpdate事件

对于nodeUpdate事件，会首先获取该node的taint，然后获取该node上面所有的pod，依次对每个pod调用processPodOnNode：判断是否有对应的toleration，如果没有则将其加入到对应的taintEvictionQueue中，该queue是个定时器队列，对于队列中的每个元素会有一个定时器来来执行，该定时器执行时间由toleration中的tolerationSecond进行设置。对于一些在退出时需要进行清理的程序，toleration必不可少，可以保证给容器退出时留下足够的时间进行清理或者恢复。出队时调用的是回调函数deletePodHandler来删除pod。
对于podUpdate事件则相对简单，首先获取所在的node，然后从taintNode map中获取该node的taint, 最后调用processPodOnNode，后面的处理逻辑就同nodeUpdate事件一样了。

为了加快处理速度，提高性能，上述处理会根据nodename hash之后交给多个worker进行处理。

上述就是controller-manager中心跳处理逻辑，三个模块层层递进，依次处理，最后将一个异常node上的pod安全地迁移。