边缘计算场景下的边缘自治
为什么需要边缘自治
在边缘计算场景中,由于云端与边缘计算节点存在物理上的距离,那么很有可能存在边缘节点通过公网连接云端的场景;从公网的不稳定性以及成本等因素考虑,边缘要求断网状态或者弱网状态下边缘业务可以持续运行。
那么传统 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 方案
总结
综上,在边缘场景下,我们需要将集群元数据保存到边缘节点本地;云边网络失连时,当边缘节点出现故障时,可以通过获取本地元数据恢复到断网时的状态,实现边缘节点的自治。