如何实现边缘计算中的节点自治

边缘计算场景下的边缘自治

为什么需要边缘自治

在边缘计算场景中，由于云端与边缘计算节点存在物理上的距离，那么很有可能存在边缘节点通过公网连接云端的场景；从公网的不稳定性以及成本等因素考虑，边缘要求断网状态或者弱网状态下边缘业务可以持续运行。

那么传统 K8s 的集群中，架构如下：

因此在传统 K8s 下，在云边网络异常时，存在如下问题：

问题 1：节点数据由 kubelet 从集群获取，节点异常或重启时，内存数据丢失，网络断连时容器无法恢复；

问题 2：网络长时间断连时，云端控制器认为主机故障而对业务容器进行驱逐；在驱逐后，恢复网络连接后，业务容器将不在预期边缘节点部署；

边缘业务恢复

kubeedge

kubeedge 对 kubelet 进行了功能的裁剪和修改，为 kubeedge 中的 Edged 组件；

边缘节点通过 MetaManager 进行元数据存取，过程如下：
Edged 获取元数据，判断是否可以连接云端，如果可以，则从云端拉取元数据，并更新到本地存储 NodeLevel DataStore，如果无法连接到云端，则直接从本地存储获取元数据；当主机故障或重启，不会由于拿不到云端数据而影响业务恢复。

openyurt

openyurt 没有侵入 K8s，在 kubelet 上加了 YurtHub 层；

kubelet 和云端通信将经由 YurtHub 组件，相当于具有数据缓存功能的"透明网关"；同样，在云端网络断连状态下，节点重启，将从本地获取业务相关数据，解决边缘自治问题。

业务数据恢复问题

这里不对方案的优点进行比较，仅看解决业务数据恢复问题的方案和思路相差无几，都是通过 kubelet(edged) 连接 k8s-apiserver 获取数据时进行本地缓存，在云边网络失连时都可以通过拿取本地元数据来进行业务恢复，可以恢复到断网时的业务状态。

边缘功能恢复

边缘不止有计算功能：

Pod 需要对内或对外提供服务，边缘节点网络恢复则是不容忽视的一个问题，例如原生 k8s 中节点重启后：

• Pod IP 发生变化，云边数据不同的问题
• 路由数据丢失，无法访问相同集群内 pod
• IPVS 丢失，导致 Service 无法访问

Pod 需要集群管理的 Configmap 和 Secrets 资源，当节点重启时：

• Pod 启动时，获取不到资源，启动失败

openyurt

openyurt 考虑此类资源同样通过 Yurthub 保存到本地存储，通过从本地获取来实现功能恢复。

kubeedge

待补充 kubeedge 方案

总结

综上，在边缘场景下，我们需要将集群元数据保存到边缘节点本地；云边网络失连时，当边缘节点出现故障时，可以通过获取本地元数据恢复到断网时的状态，实现边缘节点的自治。