kubernetes中node心跳处理逻辑分析
gaorong404 人气:1最近在查看一个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, 如果NodeReady
condition为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安全地迁移。
加载全部内容