Kubernetes中的电平触发和调节

Kubernetes如何使用系统编程概念来管理您的集群

披露： 开发人员市场 Manifold 之前曾赞助过Hacker Noon。 使用代码HACKERNOON2018可获得10美元的任何服务折扣。

到目前为止，Kubernetes是最受欢迎的容器协调器。 其成功的大部分源于其可靠性。 所有软件都有错误。 在运行您的容器时，Kubernetes在某种程度上比其他方式的错误少。

Kubernetes最终会及时达到您期望的运行容器数量。 它不懈地保持着这个数字的运转。 Kubernetes文档将此称为Kubernetes具有自我修复功能。 这种行为来自Kubernetes设计的核心理念。

“控制回路的目标搜索行为非常稳定。 这已经在Kubernetes中得到了证明，在这里我们发现了一些未被发现的错误，因为控制循环从根本上是稳定的，并且会随着时间的流逝而自行纠正。

如果您被边缘触发，则有可能危及您的状态并且永远无法重新创建状态。 如果您是水平触发的，则该模式非常宽容，并为不正常的组件留出了空间，应予以纠正。 这就是使Kubernetes如此出色地工作的原因。”

― Heptio的CTO Joe Beda（在Cloud Native Infrastructure中引用，Justin Garrison和Kris Nova）

中断：边沿和电平触发相同信号的边沿和电平触发。

边缘和电平触发是来自电子和系统编程的概念。 它们指的是系统随着时间应如何响应电信号（或数字逻辑）的形状。 应该了解，当信号从低到高转变和高到低，还是应该关心如果信号是在高系统护理？

给出以下简单补充，以另一种方式进行解释：

> let a = 3 ;
> ;
> ;
> a += 4 ;
< ;
< ;
< 7

在操作的边缘触发视图中，我们将看到：

add 4 to a

在添加时，这种情况只会发生一次。

在操作的级别触发视图中，我们将看到：

a is 7

从添加开始到下一个事件发生，我们将不断看到这种情况。

分布式系统中的边缘和水平触发

在摘要中，边沿触发和电平触发没有明显区别。 在现实世界中，即使在系统编程级别，我们也必须应对实际的限制。 一个常见的限制是采样率 。 如果系统未对信号进行足够频繁的采样，则可能会因为沿跳变或电平短暂变化而错过触发。

在整个计算机和大型网络的更大规模上，还有更多的问题需要解决。 网络不可靠。 人们笨拙 。 松鼠不屈不挠 。 从某种意义上说，这些问题就像采样率不好或不一致一样。 他们掩盖了我们对信号的看法。

颠覆改变感知

让我们看一下信号中断如何影响在边沿和电平触发系统中观察到的信号：

理想条件

边沿和电平触发系统如何解释信号。

在理想条件下，边沿触发和电平触发系统都可以观察到信号的正确视图。 信号从打开变为关闭后，他们都立即将信号视为关闭状态。

两次破坏

中断上升和下降会丢失边沿触发系统的高信号，但会到达正确的结束状态。

通过在信号状态的前两个变化周围放置两个中断，可以清楚地看到边缘和电平触发系统之间的差异。 信号的边沿触发视图未达到第一个上升。 电平触发系统假定信号处于其最后观察到的状态，直到看到其他状态为止。 这会导致观察到的信号大部分是正确的，但会延迟到中断之后。

一次破坏

单个位置适当的中断可能会对边缘触发系统产生重大影响。

更少的干扰并不一定总能带来更好的结果。 一次干扰遮盖了从高回落到低点的跌落，因此触发水平的系统在大多数情况下仍是正确的。 边沿触发系统仅看到两次上升，导致原始信号从未进入的状态。

为了再次表达这一点，信号表示：

> let a = 1 ;
> ;
> ;
> a += 1 ;
> ;
> ;
> a -= 1 ;
> ;
> ;
> a += 1 ;
< ;
< ;
< 2

但是观察到边缘触发系统：

> let a = 1 ;
> ;
> ;
> a += 1 ;
> ;
> ;
> a += 1 ;
< ;
< ;
< 3

协调期望状态和实际状态

Kubernetes不仅观察一个信号，而且观察两个信号：集群的期望状态和实际状态。 所需状态是使用群集的人员希望其处于的状态（ “运行应用程序容器的两个实例” ）。 理想状态下，实际状态与所需状态相匹配，但是它会遭受许多硬件故障和恶意啮齿动物的攻击。 这些可以使它远离所需的状态。 时间是一个因素，因为不可能立即使实际状态与所需状态匹配。 容器映像必须从注册表中下载，应用程序需要时间才能正常关闭，依此类推。

Kubernetes必须采用实际状态，并将其与所需状态进行协调 。 它连续进行，获取两种状态，确定它们之间的差异，并应用必须进行的任何更改以使实际状态达到所需状态。

在Kubernetes中扩展部署

在边缘触发系统中，我们可能与期望的结果大相径庭。

即使没有中断网络，尝试协调两种状态的边缘触发系统也可能导致错误的结果。

如果我们从单个容器副本开始，并希望扩展到5个副本，然后减少到两个副本，则边缘触发的系统将针对所需状态看到以下内容：

> let replicas = 1 ;
> ;
> ;
> replicas += 4 ;
> ;
> ;
> replicas -= 3 ;

系统的实际状态不能立即对这些命令做出反应。 如图所示，当只有3个正在运行时，它可以终止3个副本。 这使我们拥有0个副本，而不是所需的2个副本。

在水平触发系统中，我们总是比较完整的期望状态和实际状态。 这减少了状态不同步（错误）的机会。

升级

边缘触发并不是天生的坏事。 它确实比电平触发更具优势。 边缘触发仅在发生更改时才发送更改的内容。

与边缘触发系统中断有关的问题可以缓解。 这通常是通过与完整状态进行定期对帐来完成的，例如级别触发系统的工作方式。 中断也可以通过事件的显式排序和版本控制来减轻。

对于Kubernetes而言，将问题视为级别触发系统已经导致了一种干净，简单且可以满足用户要求的架构，尽管分布式计算存在固有的问题。

特别感谢 Meg Smith 提供本文中包含的图表。

From: https://hackernoon.com/level-triggering-and-reconciliation-in-kubernetes-1f17fe30333d