导语

边缘场景下网络经常不牢靠，容易误触发 Kubernetes 驱赶机制，引起不合乎预期的 Pod 驱赶动作，TKE Edge 独创分布式节点状态断定机制，该机制能够更好地辨认驱赶机会，保障系统在弱网络下失常运行，防止服务中断和稳定。

边缘计算情境下，边缘节点与云端的网络环境十分复杂，网络品质无奈保障，容易呈现 APIServer 和节点连贯中断的场景。如果不加革新间接应用原生 Kubernetes，节点状态会常常出现异常，进而引起 Kubernetes 驱赶机制失效，导致 Pod 的驱赶和 Endpoint 的缺失，最终造成服务的中断和稳定。为了解决这个问题，TKE 边缘容器团队在边缘集群弱网环境下提出了边缘节点分布式节点状态断定机制，能够更好地辨认驱赶机会。

背景

不同于核心云，边缘场景下，首先要面对云边弱网络的环境，边缘设施经常位于边缘云机房、挪动边缘站点，与云端连贯的网络环境十分复杂，不像核心云那么牢靠。这其中既蕴含云端 (管制端) 和边缘端的网络环境不牢靠，也蕴含边缘节点之间的网络环境不牢靠，即便是同一区域不同机房之间也无奈假如节点之间网络品质良好。

以智慧工厂为例，边缘节点位于厂房仓库和车间，管制端 Master 节点在腾讯云的核心机房内。

仓库和车间内的边缘设施同云端集群之间的网络较简单，因特网、5G、WIFI 等状态均有可能，网络品质差次不齐没有保障；然而，相比于和云端的网络环境，因为仓库和车间内的边缘设施之间是本地网络，因而网络品质必定要优于同云端集群之间的连贯，相对而言更加牢靠。

造成的挑战

原生 Kubernetes 解决形式

云边弱网络带来的问题是影响运行在边缘节点上的 kubelet 与云端 APIServer 之间通信，云端 APIServer 无奈收到 kubelet 的心跳或者续租，无奈精确获取该节点和节点上 pod 的运行状况，如果持续时间超过设置的阈值，APIServer 会认为该节点不可用，并做出如下一些动作：

• 失联的节点状态被置为 NotReady 或者 Unknown 状态，并被增加 NoSchedule 和 NoExecute 的 taints
• 失联的节点上的 Pod 被驱赶，并在其余节点上进行重建
• 失联的节点上的 Pod 从 Service 的 Endpoint 列表中移除

需要场景

再看一个音视频拉流场景，音视频服务是边缘计算的一个重要利用场景，如图所示：

思考到用户体验及公司老本，音视频拉流常常须要进步边缘缓存命中率缩小回源，将用户申请的同一文件调度到同一个服务实例以及服务实例缓存文件均是常见的做法。

然而，在原生 Kubernetes 的状况下，如果 Pod 因为网络稳定而频繁重建，一方面会影响服务实例缓存成果，另一方面会引起调度零碎将用户申请调度到其余服务实例。无疑，这两点都会对 CDN 成果造成极大的影响，甚至不能承受。

事实上，边缘节点齐全运行失常，Pod 驱赶或重建其实是齐全不必要的。为了克服这个问题，放弃服务的继续可用，TKE 边缘容器团队提出了分布式节点状态断定机制。

解决方案

设计准则

显然，在边缘计算场景中，仅仅依赖边缘端和 APIServer 的连贯状况来判断节点是否失常并不合理，为了让零碎更强壮，须要引入额定的判断机制。

相较于云端和边缘端，边缘端节点之间的网络更稳固，如何利用更稳固的基础设施来进步准确性呢？咱们独创了边缘衰弱分布式节点状态断定机制，除了思考节点与 APIServer 的连贯状况，还引入了边缘节点作为评估因子，以便对节点进行更全面的状态判断。通过测试及大量的实践证明，该机制在云边弱网络状况下大大提高零碎在节点状态判断上的准确性，为服务稳固运行保驾护航。

该机制的次要原理：

• 每个节点定期探测其余节点衰弱状态
• 集群内所有节点定期投票决定各节点的状态
• 云端和边缘端节点独特决定节点状态

首先，节点外部之间进行探测和投票，独特决定具体某个节点是否存在状态异样，保障大多数节点的统一判断能力决定节点的具体状态；另外，虽说节点之间的网络状态个别状况下要优于云边网络，但同时应该留神到，边缘节点之间网络状况也十分复杂，它们之间的网络也不是 100% 牢靠。

因而，也不能齐全信赖节点之间的网络，节点的状态不能只由节点自行决定，云边独特决定才更为牢靠。基于这个思考，咱们做出了如下的设计：

计划个性

须要留神的是，当云端断定节点异样，然而其余节点认为节点失常的时候，尽管不会驱赶已有 Pod，然而为了确保增量服务的稳定性，不会再将新的 Pod 调度到该节点上，存量的失常运行也得益于边缘集群的边缘自治能力；

另外，因为边缘网络和拓扑的特殊性，经常会存在节点组之间网络单点故障的问题，比方厂房的例子中，仓库和车间尽管都属于厂房这个地区内，然而可能二者之间的网络连接依附一条要害链路，一旦这条链路产生中断，就会造成节点组之间的决裂，咱们的计划可能确保两个决裂的节点组失联后相互断定时始终保持少数的一方节点不会被断定为异样，防止被断定为异样造成 Pod 只能被调度到少部分的节点上，造成节点负载过高的状况。

除此之外，边缘设施很有可能位于不同的地区、互相不通，让网络不通的节点之间互相查看显然就不适合了。为了应答这种状况，咱们的计划也反对对节点进行分组，各个分组内的节点之间互相检测状态。思考到有可能对节点从新分组，机制也反对实时对节点变更分组而无需重新部署检测组件或从新初始化。

检测机制默认敞开，如果须要操作可进入根本信息 - 开启 Edge Health（默认敞开），如果须要为节点分组，能够持续关上“开启多地区”，而后给节点分组，分组形式为编辑和增加节点相应的标签；如果开启多地区查看后未给节点分组，默认是各个节点本人是一个组，不会查看其余节点。

在此个性开发过程中，咱们也发现了一个 node taint 相干的 Kubernetes 社区 bug 并提出了 修复计划。

将来瞻望

将来咱们会反对更多的查看形式，加强在各种场景下的稳定性；此外，以后开源的一些去核心的集群状态探测治理我的项目在一些场景下还不能齐全满足边缘的场景，如集群决裂状况，前期咱们会尝试交融借鉴满足咱们的需要。

开源我的项目 SuperEdge

以后该组件作为边缘容器我的项目 SuperEdge 的一部分曾经对外开源(https://github.com/superedge/…，欢送大家 star，下方是微信群，微信企业微信都能够退出

私有云产品 TKE Edge

目前该产品曾经全量凋谢，欢送返回 边缘容器服务控制台 进行体验~

边缘系列往期精彩举荐

• 【从 0 到 1 学习边缘容器系列 -1】之 边缘计算与边缘容器的起源
• 【从 0 到 1 学习边缘容器系列 -2】之 边缘利用治理
• 【从 0 到 1 学习边缘容器系列 -3】利用容灾之边缘自治
• 完爆！用边缘容器，竟能秒级实现团队七八人一周的工作量
• 腾讯云联结多家生态搭档，重磅开源 SuperEdge 边缘容器我的项目
• 云上视频业务基于边缘容器的技术实际
• 一文读懂 SuperEdge 边缘容器架构与原理

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！