边缘云原生的技术探索
整理 | 田晓旭
演讲嘉宾 | 范豪钧
近年来，“物联网”“云计算”等技术得到广泛应用，但是随着万物互联以及 5G 高带宽、低时延时代的到来，各类业务如车联网、工业控制、4K/8K、虚拟现实 / 增强现实（VR/AR）等所产生的数据量爆炸式增长，对计算设施带来了实时性、网络依赖性和安全性等方面的要求，为了解决这些问题，国内外学者们提出了边缘计算的概念。
边缘计算的基本原理就是在靠近数据源的地方进行计算，其定义是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力，就近提供边缘智能服务的开放平台。与云计算相比较，边缘计算就近布置，因而可以理解为云计算的下沉。
本次技术公开课，InfoQ 邀请到了星环科技研发经理范豪钧为大家分享边缘云原生的技术探索。以下为本次分享的重点内容。
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 会被驱逐。
3星环 Edge 解决方案 V1- 基于 VirtualKubelet
通过观察以上解决方案，我们不难发现边缘云原生主要的解决方案都是将 K8s 的节点直接拓展到边缘节点，并通过缓存 K8s 资源对象数据使边缘节点有自治能力。在云边离线的情况下，边缘节点即使重启也能通过缓存恢复服务状态，但不能新增服务。
但是在实际业务的实践中，我们发现这类解决方案并不能完全满足我们的需求。例如，当我们在客户现场部署了一个边缘节点，并在公用云上安装了云侧组件，客户在有些情况下需要禁网，边缘节点就无法与云侧通信，但客户可能会要求对边缘节点进行调整，包括但不限于调整之前部署的应用的配置、部署新的应用或者是进行服务器扩容。
这时，我们需要以下功能：
- 边缘节点之间的协同能力更强，临近的边缘节点组成集群。
- 在边缘自治的情况下，边缘集群也能部署应用和对云侧部署的应用配置进行修改。
- 在边缘集群中对云侧部署的应用配置进行修改需要同步到云侧。
针对这种需求，我们萌生这样的想法：将邻近的边缘节点通过 K3s 组成一个边缘集群，在云侧集群中为此边缘集群创建一个虚拟节点作为边缘集群在云集群中的代理，云集群中的对此虚拟节点的部分操作会同步到对应的边缘集群中。
为了实现这个功能，我们引入了开源项目 Virtual-Kubelet。Virtual-Kubelet 顾名思义就是实现一个虚拟 kubelet，并提供操作 pod 的接口供用户来实现达到和真实 kubelet 有相同行为的目的。
我们基于 Virtual-Kubelet 在云集群中实现了虚拟节点，在实现操作 pod 的接口时会把操作同步到边缘集群。在此基础上，还额外实现了对部分资源的同步控制器，比如 statefulset 控制器，当同步控制器检测到 statefulse 的 nodename 为当前虚拟节点时，会将此 statefulset 同步到对应的目标集群。
整体架构如上图所示，在云侧，每个边缘集群基于 VirtualKubelet 实现一个虚拟节点，使得云集群中的每个虚拟节点都对应一个边缘集群，同时针对部分 K8s 资源实现同步控制器。控制器会将云侧对资源的修改、创建和删除事件同步到边缘侧，同时也会将边缘侧对资源的修改同步到云侧。
但是这种方案仍然很多问题：
- 实现复杂，需要为每种资源实现一个同步控制器，同时边缘集群是以节点的角色接入，需要对大量的事件进行过滤、翻译。
- 语义不清晰，当要部署一个类似于 Statefulset 的资源到边缘集群时，需要指定 Statefulset 中的 nodename 为虚拟节点才会被同步到对应的边缘集群。
4星环 Edge 解决方案 V2- 基于 karmada
随着行业的蓬勃发展，针对多集群管理社区出现了许多优秀的解决方案，karmada 是一个多集群管理工具，基于 K8s 官方 federationV1 和 V2 演进开发，主要实现了在 karmada 的工作面板中对工作集群的管理。在边缘计算的场景下可以将 karmada 控制面板部署在云侧，而边缘工作集群 K3s 接入到 karmada 的管理。
Karmada 的架构主要是在云侧部署了一套 apiserver 和 etcd 用于存储联邦资源，它的核心功能是基于一种 PropagationPolicy 决定将 K8s 原生资源同步到具体的目标集群。在 PropagationPolicy 中可以指定某个 K8s 原生资源或者具有某些标签的 K8s 原生资源同步到某个目标集群或者带用特定标签的目标集群中，具有极大的灵活性。同时支持为特定集群的某些资源创建一个 overridepolicy，当 karmada 将资源同步到边缘集群之前基于 overridepolicy 重写某些字段的值。
Karmada 的优势是支持对 K8s 无侵入式改动、支持原生 K8s 资源同步到边缘集群、支持多个边缘集群协同。Karmada 原生支持所有 K8s 资源，几乎满足了我们所有的需求，唯一不足的是边缘集群对云侧部署资源的修改无法同步到云侧，在这一点上，我们的实现方法是基于准入控制，当边缘集群在修改云侧部署的资源时，会在云侧为当前边缘集群创建一个 overridepolicy。
参考链接：
https://github.com/kubeedge/kubeedge
https://github.com/openyurtio/openyurt
https://github.com/superedge/superedge
https://github.com/virtual-kubelet/virtual-kubelet
https://github.com/karmada-io/karmada
https://www.idc.com/getdoc.jsp?containerId=prCHC47644421
今日好文推荐
基于HarmonyOS 2的“超级终端”来了！这几款手机即日起可升级
雷军：年轻人入职半年内不要提意见；网易回应HR不当招聘言论：已解除劳动合同；蚂蚁自研数据库OceanBase将开源 | Q资讯
InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。回复“资料”，获取资料包传送门，注册 InfoQ 网站后，可以任意领取一门极客时间课程，免费滴！大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！
点个在看少个 bug 👇