边缘计算云原生技术探索
Posted 物合智众
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了边缘计算云原生技术探索相关的知识，希望对你有一定的参考价值。
边缘计算规模和业务复杂度已经发生了翻天覆地的变化，边缘智能、边缘实时计算、边缘分析等新型业务不断涌现。传统解决方案已经无法满足边缘设备对于可靠、时效、容量、算力的需求。将云原生的能力扩展到边缘计算成为了最有潜力的解决方案。而k8s是云原生的事实标准，基于一种可插拔、无侵入式的设计将边缘设备接入k8s云集群正是一种有效的解决方案。但是由于边缘场景的资源、环境等条件限制将云原生的能力扩展到边缘侧仍面临如下的挑战：
边缘的自治能力
云边网络的打通
云边数据的一致性
云边服务分发部署
海量边缘节点带来的运维管理复杂度
边缘节点的资源利用率
目前各大云厂商针对以上问题均基于k8s提供了自己的边缘计算解决方案。接下来将以技术的视角来分析几个主流的解决方案。以下是对比汇总，后文会详细展开
01
—
华为 KubeEdge
KubeEdge是华为云于2018年11月份开源的，已经成为CNCF孵化项目，其架构如下：
架构解析：
云侧：在k8s集群中部署了一个CloudCore，用于代理边缘节点和api-server通信。实现了用于同步资源到边缘节点的控制器，以及为apiserver提供了运维api。
边缘侧：重构了k8s的节点代理kubelet,实现了轻量化设计，并针对边缘计算场景实现了设备接入模块，在边缘侧离线的情况下实现了边缘自治。
能力扩展点：
轻量化设计了节点代理EdgeCore，相比原生kubelet组件，资源占用更小。
通过增加元数据缓存，实现了边缘自治。
集成了设备接入功能，减少了业务开发复杂度。
采用websocket打通云边网络。
可能带来的影响：
侵入式的设计，导致需要和每个k8s版本适配，与社区保持同步难度大。
k8s元数据和设备同步使用了同一条websocket通道，当有大量设备数据时可能会对元数据同步产生影响。
离线模式下，虽然边缘节点可以持续运行，但是无法再对边缘节点进行资源更新。
边缘节点协同能力不足，临近的边缘节点无法对外提供统一的服务。
适用场景：
基于kubeedge的设计方式，kubeedge主要适用于数量多、资源少，功能单一的物联网终端设备。
02
—
阿里 OpenYurt
OpenYurt是阿里云于2020年5月份开源的，已经成为CNCF沙箱项目。架构如下:
架构解析：
云侧：在k8s集群中部署了一个YurtController，修改了NodeController边缘节点的pod驱逐策略，建立了云边通信的隧道，基于UnitController实现了临近边缘节点的统一管理。
边缘侧：采用了原生Kubelet，在边缘侧实现了YurtHub代理Kubelet和ApiServer的通信，并缓冲元数据，用于实现在节点离线下边缘自治的功能。
能力扩展点：
采用了无侵入的设计，维护压力小。
基于YurtHub缓存数据实现了边缘自治。
基于UnitController将k8s的弹性服务能力扩展到边缘节点。
基于ANP（apiserver-network-proxy）隧道打通云边网络，提供安全的双向认证加密通道。
可能带来的影响：
边缘节点使用了原生Kubelet，对边缘节点资源产生一定压力。
自治场景下，边缘侧无运维能力，边缘侧的任何资源修改需要通过云端下达。
适用场景：
由于边缘节点代理无轻量化设计导致无法运行在终端设备，主要适合运行在离云计算距离较远，但又具有一定算力的场景比如CDN,边缘设备的区域网关等。
03
—
腾讯 SuperEdge
SuperEdge是腾讯2020年12月开源，其架构图如下：
架构解析：
云侧：部署了EdgeHealthAdmission,主要负责边缘节点的心跳收集以及根据边缘节点心跳修改pod的驱逐策略。部署了TunnelCloud,同时云端将通过此连接访问到边缘节点及其资源。
边缘侧：采用了原生Kubelet，在边缘侧实现了Lite-Apiserver代理Kubelet和ApiServer的通信，并缓冲元数据，用于实现在节点离线下边缘自治的功能。增加了Edge-Headlth,实现了一个网格内的节点之间相互心跳检测，
能力扩展点：
采用了无侵入的设计，维护压力小。
基于Lite-Apiserver缓存数据实现了边缘自治。
基于ApplicationGrid将k8s的弹性服务能力扩展到边缘节点。
grid中的节点之间有心跳检测，
可能带来的影响：
边缘节点使用了原生Kubelet，对边缘节点资源产生一定压力。
自治场景下，边缘侧无运维能力。
适用场景：
由于边缘节点代理无轻量化设计导致无法运行在终端设备，主要适合运行在离云计算距离较远，但又具有一定算力的场景比如CDN,边缘设备的区域网关等。
04
—
新想法：VirtualKubelet+轻量级k8s
分析完以上三个国内的解决方案，都是期望将边缘节点以普通节点的方式接入云端集群，而随着像k3s/micro-k8s/k0s等轻量级的k8s发行版的不断成熟，使得边缘节点/集群也能够使用k8s时，我们需要一种技术，将边缘集群以某种方式纳入云端管理之下，而这种技术就是我们接下来要讲的virtualkubelet（VK）。
VK顾名思义，就是将任何一种API翻译成kubelet，使其能被纳入k8s的管理之下，相比于联邦，以一种可插拔更灵活的方式伪装成一个kubelet节点接入k8s。VK最大的支持者是一些云计算平台或厂商，例如OpenStack，Azure，AWS，AliCloud都是通过实现VK的provider来完成伪装工作的。
于是，如果边缘是k3s集群，云端是k8s集群，通过VirtualNode（VK的一种边缘k8s provider实现）做中介将边缘集群伪装成一个节点，与普通节点（WorkNode）提供同样的接口参与云集群的调度，架构如下：
当然，VirtualNode作为一种边缘VKprovider实现，需要考虑云边网络防火墙以及断连的情况，所以需要额外设计一些隧道以及缓存，来保证边缘能够自治，详细架构如下：
架构解析：
云侧：在k8s集群中部署了一个Virtual-Node，代理整个边缘集群，实现资源控制器同步常用k8s资源（Pod,ConfigMap,Deployment,Statefulset等)。
边缘侧：根据业务需要部署轻量化k8s(k3s, microk8s等)。
能力扩展点：
完全无侵入的设计，云边都使用同一套维护工具kubectl。
轻量化k8s可以单节点部署，在边缘自治的场景下，具有原生的k8s能力。
边缘节点可以组成边缘集群，具有k8s的原生弹性服务能力。相比OpenYurt和SuperEdge使用NodePool或者NodeUnit的方式来将节点组成站点（一个边缘站点有多个计算节点）来实现站点级别的服务编排，将站点部署成集群看起来是更加简单高效的方式。
边缘侧作为独立集群，也可以独立自治，所做的任何资源改动，也会同步到云侧。
采用隧道打通云边网络。
可能带来的影响：
仅支持云侧部署Deployment和StatefulSet到边缘集群，某些场景无法覆盖。
云边资源的双向同步，复杂度提高，稳定性需要提高。
由于边缘侧是一个集群，云端无法指定服务到具体的边缘节点。
健康检查角度，边缘集群的资源抽象成一个节点的资源，所以云端无法了解具体边缘节点的资源占用情况。
云边证书轮换，边缘是个集群的情况下，实现证书过期轮换需要设计一套独立流程。
适用场景：
由于边缘侧支持多种轻量化k8s，可以根据业务场景进行选择，在资源受限的情况下，边缘侧可以部署k3s/k0s，在CDN场景下可以部署mico-k8s这类k8s原生能力支持更完善的工具。
混合云构建，公有云与私有云的打通。一般情况下，私有云在企业内部，完成算力需求有限的关键的实时计算任务以及最新的实时数据存储；而公有云在外部，满足弹性的不固定的非实时的计算需求以及逐渐增大的数据积累。云边任务虽然不同，但是数据以及服务管理是有统一管理统一规划的需求的。通过VK能够实现服务管理的统一，而数据管理的统一则需要额外的同步服务来实现。
05
—
总结
如上的几种解决方案将云计算的能力扩展到边缘的某些场景进行了探索，但仍有很多的问题亟待解决。云原生是一个庞大的体系，这个体系落地到边缘上，仍然有很大的挑战和机会；要做到真正的边缘原生，需要从理念、系统设计、架构设计等方面真正的去实践、实现，这样才能充分发挥边缘的优势。当然，边缘云平台也要具备和提供更多的开放能力，这样才能够形成整个正向的开发生态闭环。
参考文档
深度解读 OpenYurt：从边缘自治看 YurtHub 的扩展能力
https://baijiahao.baidu.com/s?id=1671801559376501653
一文读懂 SuperEdge 边缘容器架构与原理
https://www.cnblogs.com/tencent-cloud-native/p/14280629.html
华为KubeEdge在边缘计算的实践
https://blog.csdn.net/sikong00/article/details/100077449
边缘计算云原生开源方案选型比较
https://zhuanlan.zhihu.com/p/353429279
以上是关于边缘计算云原生技术探索的主要内容，如果未能解决你的问题，请参考以下文章