边缘云原生的技术探索

近年来，“物联网”“云计算”等技术得到广泛应用，但是随着万物互联以及 5G 高带宽、低时延时代的到来，各类业务如车联网、工业控制、4K/8K、虚拟现实 / 增强现实（VR/AR）等所产生的数据量爆炸式增长，对计算设施带来了实时性、网络依赖性和安全性等方面的要求，为了解决这些问题，国内外学者们提出了边缘计算的概念。
边缘计算的基本原理就是在靠近数据源的地方进行计算，其定义是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力，就近提供边缘智能服务的开放平台。与云计算相比较，边缘计算就近布置，因而可以理解为云计算的下沉。

1边缘计算面临的挑战
边缘计算可以作为联接物理和数字世界的桥梁。作为云计算的延伸和下沉概念，目前边缘计算仍处于产业起步阶段，在存储、网络、安全性以及异构等诸多方面面临很多挑战。
存储：随着大量物联网设备的接入，产生的数据接入边缘节点进行初步的分析、处理，而这会对资源有限的边缘节点产生巨大的存储压力。
网络：边缘节点一般部署网络及其不稳定的环境中，同时需要对产生的数据上报云计算中心，这对网络的带宽也有一定的要求。
安全性：边缘计算的分布式架构增加了攻击向量的维度，边缘节点越智能，越容易受到恶意软件感染和安全漏洞攻击。
异构：针对不同的边缘计算场景，设计不同架构的边缘节点，而灵活的管理异构边缘节点尚未有有效的解决方案。
针对以上这些挑战，目前似乎还没有找到完全有效的解决方案。但是纵观云计算的整个发展历程，我们发现云原生技术容器、服务网格、微服务、不可变基础设施和声明式 API，似乎可以解决边缘计算面临的网络、安全、异构的问题，将云原生的能力拓展到边缘计算成为针对边缘计算挑战最有潜力的解决方案。这就诞生出了边缘云原生的概念。
2边缘云原生
众所周知，K8s 是云原生的事实标准，因此边缘云原生也就是在边缘计算中使用类似 K8s 这样的解决方案。当然，业界也关注到了边缘云原生的潜力，针对边缘计算场景推出了各自的 K8s 发行版，例如 K3s、microK8s、K0s 等等。

其中，K3s 是一个轻量级的 Kubernetes 发行版，针对边缘计算、物联网等场景进行了高度优化。K3s 将所有 Kubernetes control-plane 组件的操作都封装在单个二进制文件和进程中，通过环境变量指定启动 server 或者 agent，最大程度减轻了外部依赖性，K3s 仅需要 kernel 和 cgroup 就可运行。但 K3s 仍依赖 containerd，flannel 等组件。同时 k3s 资源消耗低， 根据 k3s 官方文档 1 核 512M 内存的机器就可以运行 k3s, 而且还支持 arm 架构。虽然 K3s 将云原生的能力拓展到边缘计算，但是边缘计算是以云计算为中心的分布式架构，K3s 缺少了与云计算中心的协同。
边缘云原生面临的挑战
目前，边缘云原生发展还处于初级阶段，因此不可避免地面临挑战。根据业界对话和社区反馈，边缘云原生通常面临以下挑战：
云边协同：边缘计算节点需要纳入云计算中心的管理，并上报自己的状态，云计算中心把业务从中心下沉到边缘是很自然的事情，但是还不够。通常都需要让边缘和云协同工作起来，比如把边缘的有用数据收集到中心进行分析处理，然后继续反馈到边缘。以 AI 场景为例，我们可以把推理放到边缘进行，然后从边缘收集数据在中心进行训练，训练好的模型又下发到边缘，形成一个负反馈的闭环。
调度管理：云计算中心对边缘节点的应用进行调度，需要为边缘节点决定合适的应用。
边缘自治：在边缘节点和云计算中心断网的情况下，需要边缘节点能够完全自治，甚至需要将部分云计算中心的能力下放到边缘节点，比如创建应用的能力。运维管理：需要对大量无人值守的边缘节点提供统一的远程运维支持。
边缘云原生的开源技术方案对比
接下来，我们来对比一下目前边缘云原生领域主流的开源技术方案。

KubeEdge
KubeEdge 是将一个边缘计算节点以 K8s 工作节点的身份接入 K8s 集群中，主要适用于数量多、资源少，功能单一的物联网终端设备。

KubeEdge 架构主要分为云、边两部分：
云侧：KubeEdge 的控制面，云上左边是一个 K8s 的 apiserver，是原生的 K8s 控制面板，后边是 KubeEdge 的云侧组件 CloudCore，CloudCore 中的 Controllers 主要负责通过 CloudHub 建立起来的网络通道同步 Node、Pod、ConfigMap、设备等资源的状态和事件。
边缘侧：就是边缘节点，主要做了一个应用管理和设备管理的能力，在架构图边缘侧左边有一个 Edged，主要用于容器管理。右边有 DeviceTwin、EventBus, 负责设备管理，最左边有个 DataStore，DataStore 会缓存当前节点和云侧 apiserver 交互的数据，保证云边网络断开或者边缘节点重启了以后，Edged 可以从 DataStore 中恢复业务状态。
当然，KubeEdge 并不是一个完美的解决方案，仍有需要优化的地方：
侵入式的设计，导致需要和每个 K8s 版本适配。
K8s 元数据和设备同步使用了同一条 websocket 通道，当有大量设备数据时可能会对元数据同步造成延迟。
边缘节点协同能力不足，临近的边缘节点无法对外提供统一的服务。
OpenYurt
OpenYurt 是将部分原生 K8s 节点标记为自治节点以接入 OpenYurt 管理。OpenYurt 架构也分为云和边两部分。

云侧主要在 K8s 原生集群中部署了一个 CloudController，其中包含了 YurtControllerManager。YurtControllerManager 主要替换掉原生的 nodelifecycle 控制器来保证在自治节点离线的情况下 pod 不会从自治节点中被驱逐。
YurtAppManger 主要负责管理自定义资源 NodePool、UnitedDeployment。NodePool 主要是对自治节点分组管理，NodePool 建议以相同的属性对边缘节点进行分组，例如地理位置，操作系统，CPU 体系结构等。而 UnitedDeployment 主要提供在 NodePool 中管理 pod 的机制。
边缘侧主要采用了 K8s 原生的节点组件 (kueblet、kubeproxy 等)，但是通过 YurtHub 代理了节点组件和 apiserver 的通信，并缓存了下来，保证自治节点在重启后能从缓存恢复状态。
相对于 KubeEdge 来说，openyurt 直接采用了原生的 K8s 组件，减少了适配压力，并提供了自治节点协同的能力，极大的整合了自治节点资源的利用率。但是原生 K8s 组件对边缘设备有一定的资源压力，并且没有对 IOT 设备的原生支持。
由于边缘节点代理无轻量化设计导致不太适合在终端低功耗设备上运行，OpenYurt 主要适合运行在离云计算距离较远，但又具有一定计算资源的场景，比如 CDN、边缘设备的区域网关等。
SuperEdge
大部分开源方案都是将边缘节点以 K8s 的节点身份接入 K8s 平台，SuperEdge 也不例外，但是在具体实现思路上有一些不一样的地方。

SuperEdge 架构也分为云侧和边缘侧两部分：在云侧 application-grid controller 主要负责自定义资源 DeploymentGrid、StatefulSetGrid、ServiceGrid 的管理，这三个自定义资源主要在 Deployment、StatefulSet、Service 的基础上增加了一个 gridUniqKey 字段，通过 gridUniqKey 决定将资源应用到哪些节点上 (通过为节点打上标签进行分组)。云侧的右边有一个 edge-health admission，它综合边缘节点的状态和 edge-health 的探测结果，影响边缘负载的驱逐，从而保证弱网环境下，断网节点 workload 的正常运行。
在边缘侧有 lite-apiserver，主要缓存 K8s 节点代理和 apiserver 通信的数据， 用于边缘自治。
在边缘侧最下面有一个 EdgeHealth, 在边缘节点互通的弱网环境下，互相探测，相互感知，从本边缘节点的角度判定其他边缘节点的健康状况；将探测结果上报并且会被准入控制 edge-health admission 处理，影响边缘服务的驱逐，从而保证断网节点 Workload 依旧正常运行。Application-Grid Warpper 主要是细化转发策略，保证流量在 Grid 内。
相对与 Openyurt 来说，SuperEdge 的优势是完全无侵入式的设计，但是在最坏情况下当所有边缘节点和云侧网络不同时，会导致边缘节点的 pod 会被驱逐。