多图详解边缘计算系统的组成及概念-技术圈

作者：崔广章

来源：大数据DT（ID：hzdashuju）

本文从组成部分和概念解析两方面来说明边缘计算系统。

组成部分：边缘计算系统由云、边、端三部分组成，每部分的解决方案不止一种。本文的云组成部分选择Kubernetes，边组成部分选择KubeEdge，端组成部分选择EdgeX Foundry。
概念解析：对组成边缘计算系统的云、边、端三部分涉及的相关概念进行说明。

01 边缘计算系统的组成

1. 云——Kubernetes

Kubernetes是Google开源的大规模容器编排解决方案。整套解决方案由核心组件、第三方组件和容器运行时组成，具体如下所示。

1）核心组件

Kube-apiserver：Kubernetes内部组件相互通信的消息总线，对外暴露集群API资源的唯一出口
Kube-controller：保证集群内部资源的现实状态与期望状态保持一致
Kube-scheduler：将需要调度的负载与可用资源最佳匹配
Kube-proxy：为节点内的负载访问和节点间的负载访问做代理
Kubelet：根据Kube-scheduler的调度结果，操作相应负载

2）第三方组件

Etcd：存储集群的元数据和状态数据
Flannel
集群的跨主机负载网络通信的解决方案
需要对原来的数据包进行额外的封装、解封装，性能损耗较大
Calico
集群的跨主机负载网络通信的解决方案
纯三层网络解决方案，不需要额外的封装、解封装，性能损耗较小
CoreDNS：负责集群中负载的域名解析

3）容器运行时

Docker：目前默认的容器运行时
Containerd：比Docker轻量，稳定性与Docker相当的容器运行时
Cri-o
轻量级容器运行时
目前稳定性没有保证
Frakti
基于Hypervisor的容器运行时
目前稳定性没有保证

2. 边——KubeEdge

KubeEdge是华为开源的一款基于Kubernetes的边缘计算平台，用于将容器化应用的编排功能从云扩展到边缘的节点和设备，并为云和边缘之间的网络、应用部署和元数据同步提供基础架构支持。KubeEdge使用Apache 2.0许可，并且可以免费用于个人或商业用途。

KubeEdge由云部分、边缘部分和容器运行时组成，具体如下所示。

云部分 | CloudCore
负责将云部分的事件和指令下发到边缘端，同时接收边缘端上报的状态信息和事件信息

边缘部分 | EdgeCore
接收云部分下发的事件和指令，并执行相关指令，同时将边缘的状态信息和事件信息上报到云部分

容器运行时 | Docker
目前，KubeEdge默认支持Docker
官方表示未来会支持Containerd、Cri-o等容器运行时

3. 端——EdgeX Foundry

EdgeX Foundry是一个由Linux基金会运营的开源边缘计算物联网软件框架项目。该项目的核心是基于与硬件和操作系统完全无关的参考软件平台建立的互操作框架，构建即插即用的组件生态系统，加速物联网方案的部署。EdgeX Foundry使有意参与的各方在开放与互操作的物联网方案中自由协作，无论其是使用公开标准还是私有方案。

EdgeX Foundry微服务集合构成了4个微服务层及两个增强的基础系统服务。4个微服务层包含从物理域数据采集到信息域数据处理等一系列服务，两个增强的基础系统服务为4个微服务层提供服务支撑。

4个微服务层从物理层到应用层依次为设备服务（Device Service）层、核心服务（Core Service）层、支持服务（Supporting Service）层、导出服务（Export Service）层，两个增强的基础系统服务包括安全和系统管理服务，具体说明如下所示。

1）设备服务层

Device-modbus-go：Go实现对接使用Modbus协议设备的服务
Device-camera-go：Go实现对接摄像头设备的服务
Device-snmp-go：Go实现对接SNMP服务
Device-mqtt-go：Go实现对接使用MQTT协议设备的服务
Device-sdk-go
Go实现对接其他设备的SDK
SDK给设备接入提供了较大的灵活性

2）核心服务层

Core-command：负责向南向设备发送命令
Core-metadata：负责设备自身能力描述，提供配置新设备，并将它们与其拥有的设备服务配对的功能
Core-data：负责采集南向设备层数据，并向北向服务提供数据服务
Registry & Config：负责服务注册与发现，为其他EdgeX Foundry微服务提供关于EdgeX Foundry的相关服务的信息，包括微服务配置属性

3）支持服务层

Support-logging：负责日志记录
Support-notification：负责事件通知
Support-scheduler：负责数据调度

4）导出服务层

Export-client：导出数据的客户端
Export-distro：导出数据的应用

5）两个增强的基础系统服务

System-mgmt-agent：提供启动、停止所有微服务的API
Sys-mgmt-executor：负责启动、停止所有微服务的最终执行

02 概念解析

组成边缘计算系统的云、边、端三部分的相关概念如下。

云：涉及的概念包括Container、Pod、ReplicaSet、Service、Deployment、DaemonSet、Job、Volume、ConfigMap、NameSpace、Ingress等。
边：目前边缘系统的实现方式是通过对云原有的组件进行裁剪并下沉到边缘，所以边涉及的概念是云的子集，而且与云保持一致。
端：部署在边上的一套微服务，目前没有引入新的概念。

目前，边和端都在沿用云的概念，所以本节主要是对云的概念进行解析。下面以图解的形式对云涉及的相关概念进行说明。由图1-1可知，Container（容器）是在操作系统之上的一种新的环境隔离技术。使用容器隔离出的独立空间包含应用所需的运行时环境和依赖库。在同一台主机上，容器共享操作系统内核。

▲图1-1 Container解析

由图1-2可知，Pod是由一组容器组成的，在同一个Pod内的容器共享存储和网络命名空间。在边缘计算系统中，Pod是最小的可调度单元，也是应用负载的最终载体。

▲图1-2 Pod解析

由图1-3可知，ReplicaSet用来管理Pod，负责让Pod的期望数量与Pod真实数量保持一致。在边缘计算系统中，ReplicaSet负责维护应用的多实例和故障自愈。

▲图1-3 ReplicaSet解析

由图1-4可知，Service作为一组Pod的访问代理，在多个Pod之间做负载均衡。Pod的生命周期相对比较短暂，变更频繁。Service除了为与之相关的Pod做访问代理和负载均衡外，还会维护与Pod的对应关系。

▲图1-4 Service解析

由图1-5可知，Deployment是ReplicaSet的抽象，在ReplicaSet的基础上增加了一些高级功能。其功能和应用场景与ReplicaSet相同。

▲图1-5 Deployment解析

由图1-6可知，DaemonSet负责让指定的Pod在每个节点上都启动一个实例。该功能一般用在部署网络插件、监控插件和日志插件的场景。

▲图1-6 DaemonSet解析

由图1-7可知，Job用来管理批量运行的Pod，该管理类型的Pod会被定期批量触发。与Deployment管理的Pod不同，Job管理的Pod执行完相应的任务后就退出，不会一直驻留。在边缘计算系统中，一般用Job所管理的Pod来训练AI模型。

▲图1-7 Job解析

由图1-8可知，Volume是用来给Pod提供存储的，通过挂载的方式与对应Pod关联。Volume分临时存储和持久存储，临时存储类型的Volume会随着Pod的删除而被删除，持久存储类型的Volume不会随着Pod的删除而被删除。

▲图1-8 Volume解析

由图1-9可知，ConfigMap作为Pod存储配置文件的载体，通过环境变量（env）和文件卷的方式与Pod进行关联。在边缘计算系统中，以ConfigMap方式来管理配置信息会更方便。ConfigMap还可以对配置中的敏感信息进行加密，使配置信息更安全。

▲图1-9 ConfigMap解析

由图1-10可知，NameSpace是对Pod、Service、ConfigMap、Deployment、DaemonSet等资源进行隔离的一种机制，一般用在同一公司的不同团队隔离资源的场景。边缘计算系统使用NameSpace来对一个团队可以使用的资源（CPU、内存）和创建的负载所需要的资源进行限制。

▲图1-10 NameSpace解析

由图1-11可知，Ingress可作为集群内与集群外相互通信的桥梁—将集群内的服务暴露到集群外，同时可以对进入集群内的流量进行合理的管控。在边缘计算系统中，Ingress是一种资源对象，需要配合Ingress Controller和反向代理工作。

▲图1-11 Ingress解析

关于作者：崔广章，之江实验室高级研究专员，资深云计算和边缘计算技术工程师。从2014年接触云计算以来，参与过多个云计算生产项目，其中代表性的项目有基于OpenStack进行定制开发的运营商私有云、政务云，基于开源容器云方案定制开发的面向运营商的数据中心操作系统（DCOS），2018年开始从事边缘计算相关研究与开发。

本文摘编自《深入理解边缘计算：云、边、端工作原理与源码分析》，经出版方授权发布。