(接上篇)
边缘存储和网络
本节将对KubeEdge中存储、网络的使用和管理流程进行梳理和分析。由于目前在KubeEdge中网络相关信息是随着存储一块下发的,因此所要梳理的网络和存储的管理流程其实是KubeEdge中存储的管理流程,如图5-8所示。
KubeEdge边缘存储和网络管理流程
由图5-8可知,该流程包括云和边缘两部分,具体功能如下。
1)在云部分,Provisioner/Attacher以List/Watch的方式监听Kubernetes Master中与边缘存储和网络的资源相关的资源对象,将监听到的资源对象交由CSI Driver处理,CSI Driver处理的结果通过UDS(Unix Domain Socket)的方式传给CloudHub,最后由CloudHub将与KubeEdge相关的存储和网络资源从云上下发到边缘。
2)在边缘部分,MetaManager从EdgeHub中取出与边缘存储和网络相关的资源,首先由MetaManager将这些资源对象在边缘做本地化存储,然后将这些资源对象传给Edged,最后由Edged以DaemonSet的形式将这些资源管理起来。
边缘节点管理
本节将梳理和分析KubeEdge中对边缘节点的管理,对边缘节点的管理有如下3种形式。
1)以节点的形式管理边缘计算资源:在云上部署整个系统的控制面,计算资源在边缘都以独立节点的形式来管理。
2)以独立集群的形式管理边缘计算资源:在边缘通过部署独立的Kubernetes集群的方式对边缘的计算资源进行管理。
3)以多集群的形式管理边缘计算资源:在边缘通过部署多种集群的方式对边缘的计算资源进行管理,即在云上有一个统一控制平面对边缘的多个集群进行统一管理。
1.以节点形式管理边缘计算资源
以节点形式管理边缘计算资源如图5-9所示。
图5-9 以节点形式管理边缘计算资源
由图5-9可知,在云上部署整个系统的控制面,计算资源在边缘都以独立节点的形式来管理。在该方式下,我们需要注意如下三点。
- 云边协同:因为在边缘上网络质量不可控,会经常出现云与边缘经常断网的情况,在这种情况下要保证已经在边缘节点上运行的相关应用负载也能正常运行。
- 适应边缘的网络模型:由于存在云与边缘经常断网的情况,在边缘上应用负载之间的相互访问应该与云有所区别。目前,云上应用负载之间的相互访问是以域名的形式进行的。域名解析通过运行在云上的DNS服务器来完成,将这种机制应用到边缘显然不合适。具体的边缘网络模型内容,读者可以参考KubeEdge官网的EdgeMesh部分。
- 适应边缘的网关:目前,云计算集群的网关是通过一个总的集群入口来实现的。由于云和边缘距离较远,而且存在云与边缘经常断网的情况,将这种网关机制应用到边缘显然也不合适,需要设计专门面向边缘的网关模型。目前,官方还没有提供该方面相关内容。
上述以节点形式管理边缘计算资源的方案是KubeEdge官方已经实现的方案,也是官方的推荐方案。
「未完待续……」
点击下方标题可阅读技术文章
「连载」边缘计算(一)01-16:边缘计算系统逻辑架构(原理篇)
「连载」边缘计算(二)01-17:边缘计算系统逻辑架构(原理篇)
「连载」边缘计算(三)01-18:边缘部分原理解析(原理篇)
「连载」边缘计算(四)01-19:边缘部分原理解析(原理篇)
「连载」边缘计算(五)01-22:边缘部分原理解析(原理篇)