一文读懂 SuperEdge 边缘容器架构与原理 (4)

通过lite-apiserver可以实现边缘节点断网情况下重启后pod可以被正常拉起,但是根据原生Kubernetes原理,拉起后的pod ip会发生改变,这在某些情况下是不能允许的,为此superedge设计了网络快照机制保障边缘节点重启,pod拉起后ip保存不变。具体来说就是将节点上组件的网络信息定期快照,并在节点重启后进行恢复

本地DNS解决方案

通过lite-apiserver以及网络快照机制可以保障边缘节点断网情况下重启后,Pod会被重新拉起并正常运行,同时微服务也运行正常。而服务之间相互访问就会涉及一个域名解析的问题:通常来说在集群内部我们使用coredns来做域名解析,且一般部署为Deployment形式,但是在边缘计算情况下,节点之间可能是不在一个局域网,很可能是跨可用区的,这个时候coredns服务就可能访问不通。为了保障dns访问始终正常,superedge设计了专门的本地dns解决方案,如下:

一文读懂 SuperEdge 边缘容器架构与原理

本地dns采用DaemonSet方式部署coredns,保证每个节点都有可用的coredns,同时修改每个节点上kubelet的启动参数--cluster-dns,将其指向本机私有IP(每个节点都相同)。这样就保证了即使在断网的情况下也能进行域名解析。

总的来说,superedge是以lite-apiserver机制为基础,并结合分布式健康检查机制、网络快照以及本地coredns,保证了边缘容器集群在弱网环境下的网络可靠性。另外随着边缘自治的级别越高,所需要的组件会越来越多

云边隧道

最后介绍一下superedge的云边隧道,云边隧道主要用于:代理云端访问边缘节点组件的请求,解决云端无法直接访问边缘节点的问题(边缘节点没有暴露在公网中)

架构图如下所示:

一文读懂 SuperEdge 边缘容器架构与原理

实现原理为:

边缘节点上tunnel-edge主动连接云端tunnel-cloud service,tunnel-cloud service根据负载均衡策略将请求转到tunnel-cloud的具体pod上

tunnel-edge与tunnel-cloud建立grpc连接后,tunnel-cloud会把自身的podIp和tunnel-edge所在节点的nodeName的映射写入DNS(tunnel dns)。grpc连接断开之后,tunnel-cloud会删除相关podIp和节点名的映射

而整个请求的代理转发流程如下:

apiserver或者其它云端的应用访问边缘节点上的kubelet或者其它应用时,tunnel-dns通过DNS劫持(将host中的节点名解析为tunnel-cloud的podIp)把请求转发到tunnel-cloud的pod上

tunnel-cloud根据节点名把请求信息转发到节点名对应的与tunnel-edge建立的grpc连接上

tunnel-edge根据接收的请求信息请求边缘节点上的应用

总结

本文依次介绍了开源边缘计算框架SuperEdge的特性,整体架构以及主要功能和原理。其中分布式健康检查以及边缘集群服务访问控制ServiceGroup是SuperEdge独有的特性功能。分布式健康检查很大程度避免了由于云边网络不可靠造成的大量pod迁移和重建,保证了服务的稳定;而ServiceGroup则极大地方便了用户在共属同一个集群的不同机房或区域中各自部署一组服务,并且使得各个服务间的请求在本机房或本地域内部即可完成(闭环),避免了服务跨地域访问。除此之外还有边缘自治以及云边隧道等功能。

整体来说,SuperEdge采用无侵入的方式构建边缘集群,在原有Kubernetes组件保留不变的基础上新增了一些组件完成边缘计算的功能,既保留了Kubernetes强大的编排系统,同时也具备完善的边缘计算能力。

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

一文读懂 SuperEdge 边缘容器架构与原理

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wsxwjf.html