kubernetes中node心跳处理逻辑分析

2019/04/10 10:10
阅读数 28

最近在查看一个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的方式进行管理。其主要逻辑由三部分组成:

  1. 不断地检查所有node状态,设置对应的condition
  2. 不断地根据node condition 设置对应的taint
  3. 不断地根据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决定具体数值, 具体规则是:

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

二. 设置node taint

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

  1. doNodeProcessingPassWorker中主要的逻辑就是: doNoScheduleTaintingPass, 该函数会根据node当前的condition设置unschedulable的taint,便于调度器根据该值进行调度决策,不再调度新pod至该node。
  2. doNoExecuteTaintingPass 会不断地从上面提到的zoneNoExecuteTainter队列中获取元素进行处理,根据node condition设置对应的NotReadyUnreachable的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安全地迁移。

原文出处:https://www.cnblogs.com/gaorong/p/12312590.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部