Kubernetes

kubernetes源码学习之list/watch设计理念

本文主要是介绍kubernetes源码学习之list/watch设计理念,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

overview

kubernetes的设计里面大致上分为3部分:

  • API驱动型的特点 (API-driven)
  • 控制循环(control loops)与 条件触发 (Level Trigger
  • API的可延伸性

而正因为这些设计特性,才使得kubernetes工作非常稳定。

什么是Level Trigger与 Edge trigger

看到网上有资料是这么解释两个属于的:

  • 条件触发(level-trigger,也被称为水平触发)LT指: 只要满足条件,就触发一个事件(只要有数据没有被获取,就不断通知)。

  • 边缘触发(edge-trigger)ET: 每当状态变化时,触发一个事件。

通过查询了一些资料,实际上也不明白这些究竟属于哪门科学中的理论,但是具体解释起来看的很明白。

LEVEL TRIGGERING:当电流有两个级别,VHVL。代表了两个触发事件的级别。如果将VH 设置为LED在正时钟。当电压为VH时,LED可以在该时间线任何时刻点亮。这称为LEVEL TRIGGERING,每当遇到VH 时间线就会触发事件。事件是在时间内的任何时刻开始,直到满足条件。

在这里插入图片描述

Edge TRIGGERING:

如图所示,会看到上升线与下降线,当事件在上升/下降边缘触发时(两个状态的交点),称为边缘触发(Edge TRIGGERING:)。

如果需要打开LED灯,则当时钟从VL转换到VH时才会亮起,而不是一家处在对应的时钟线上,仅仅是在过渡时亮起。

在这里插入图片描述

为什么kubernetes使用Level Trigger而不使用Edge trigger

如图所述,两种不同的设计模式,随着时间形状进行相应,当系统在由高转低,或由低转高时,系统处在关闭或者不可控的异常状态下,应如何触发对应的事件呢。


换一种方式来来解释,比如说通过 加法运算,如下,i=3,当给I+4作为一个操作触发事件。

# let i=3
# let i+=4
# let i
# echo $i
7

当为Edge trigger时操作的情况下,将看到 i+4 ,而在 level trigger 时看到的是 i=7。这里将会从``i+4` 一直到下一个信号的触发。

信号的干扰

通常情况下,两者是没有区别的,但在大规模分布式网络环境中,有很多因素的影响下,任何都是不可靠的,在这种情况下会改变了我们对事件信号的感知。

如图所示,图为Level TriggerEdge trigger 的信号发生模拟,在理想情况下,两者间并没有什么不同。

在这里插入图片描述

一次中断场景

在这里插入图片描述

由图可知,Edge trigger当在恰当的时间点发生信号中断,会对整个流产生很大的影响,甚至改变了整个状态,对于较少的干扰并不会对有更好的结果,而单次的中断,使Edge trigger错过了从高到低的变化,而 level trigger 基本上保证了整个信号量的所有改变状态。

两次中断的场景下

在这里插入图片描述
由图可看到,信号的上升和下降中如果存在了中断,Edge trigger 丢失了上升的信号,但最终状态是正确的。

在信号状态的两次变化时发生了两次中断,Level TriggerEdge trigger 之间的区别很明显,Edge trigger 的信号错过了第一次上升,而Level Trigger 保持了最后观察到的状态,知道拿到了其他状态,这种模式保证了得到的信号基本的正确性,但是发生延迟到中断恢复后。

通过运算来表示两种模式的变化情况

完整的信号

# let i=2

# let i+1
# let i-=1
# let i+1

# echo $i
3

Edge trigger

# let i=2

# let i+1  
(# let i-=1) miss this
# let i+1

# echo $i
4

如何使理想状态和实际状态一样呢?

在Kubernetes中,不仅仅是观察对象的一个信号,还观察了其他两个信号,集群的期待状态与实际状态,期望的状态是用户期望集群所处的状态,如我运行了2个实例(pod)。在最理想的场景下,集群的实际状态与期待状态是相同的,但这个过程会受到任意的外界因素干扰被影响下,实际状态与理想状态发生偏差。

Kubernetes必须接受实际状态,并将其与所需状态调和。不断地这样做,采取两种状态,确定其之间的差异,并纠正其不断的更改,以使实际状态达到理想状态。

在这里插入图片描述
如图所示,在一个Edge trigger 中,最终的结果很可能会与理想中的结果发生偏差。

当初始实例为1时,并希望扩展为5个副本,然后再向下缩容到2个副本,则Edge trigger环境下将看到以下状态:系统的实际状态不能立即对这些命令作出反应。正如图所述,当只有3个副本在运行时,它可能会终止3个副本。这就给我们留下了0个副本,而不是所需的2个副本。

# let replicas=1
# let replicas += 4 # 此时副本数为5,但是这个过程需要时间而不是立即完成至理想状态
# let replicas -= 3 # 当未完成时又接到信号的变化,此时副本数为3,减去3,很可能实际状态为0,与理想状态2发生了偏差

而使用Level Trigger时,会总是比较完整的期望状态和实际状态,直到实际状态与期望状态相同。这大大减少了状态同步间(错误)的产生。

summary

每一种触发器的产生一定有其道理,Edge trigger本身并不是很差,只是应用场景的不同,而使用的模式也不同,比如nginx的高性能就是使用了Edge trigger模型,如nginx使用了 Level trigger在大并发下,当发生了变更信号等待返回时,发生大量客户端连接在侦听队列,而Edge trigger模型则不会出现这种情况。

综上所述,kubernetes在设计时,各个组件需要感知数据的最终理想状态,无需担心错过数据变化的过程。而设计kubernentes系统消息通知机制(或数据实时通知机制),也应满足以下要求:

  • 实时性(即数据变化时,相关组件感觉越快越好)。消息必须是实时的。在list/watch机制下,每当apiserver资源有状态变化事件时,都会及时将事件推送到客户端,以保证消息的实时性。

  • 消息序列:消息的顺序也很重要。在并发场景下,客户端可能会在短时间内收到同一资源的多个事件。对于关注最终一致性的kubernetes来说,它需要知道哪个是最新的事件,并保证资源的最终状态与最新事件所表达的一致。kubernetes在每个资源事件中都携带一个resourceVersion标签,这个标签是递增的。因此,客户端在并发处理同一资源的事件时,可以比较resourceVersion,以确保最终状态与最新事件的预期状态一致。

  • 消息的可靠性,保证消息不丢失或者有可靠的重新获取的机制(比如 kubeletkube-apisever之间的网络波动(network flashover )需要保证kubelet在网络恢复后可以接收到网络故障时产生的消息)。

正是因为Kubernetes使用了 Level trigger才让集群更加可靠。

Reference

nginx-event-driven-architecture

What-is-meant-by-edge-triggering-and-level-triggering

这篇关于kubernetes源码学习之list/watch设计理念的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!