1. 边缘计算
边缘特指计算资源在地理分布上更加靠近设备，而远离云数据中心的资源节点，可以理解为是近场计算。典型的边缘计算分为物联网（智慧城市，智能家居等）和非物联网（CDN 等）场景。
1. 物联网场景
随着互联网智能终端设备数量的急剧增加，以及 5G 和物联网时代的到来，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求。将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控，将是云计算的重要发展趋势。
2. 非物理网场景（以CDN为例）
CDN的全称是ContentDelivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。简单的说CDN就是用空间换时间，空间的话就是分部在离终端用户较近的边缘节点，时间上就是终端用户直接从边缘节点直接获取资源，这样就不需要直接访问源站，从而提升用户体验。
边缘计算的主要计算节点以及应用分布式部署在靠近终端的数据中心，这使得在服务的响应性能、还有可靠性方面都高于传统中心化的云计算概念，而CDN的节点正好可以充分复用起来，提供计算服务。
3. 思考
随着云计算的崛起,K8S已经升入人心,强大的容器编排能力让人眼前一亮,随着5G网络的横空出世，IOT借着5G开始大力发展，我们自然而然的就会思考，在一些算力资源并不那么足够的情况下能否将k8s的容器编排能力赋予上去，例如做到计算下沉,在某些远离云数据中心的场景下（这里特指物理距离），边缘能够做出及时的响应实时计算就很重要。于是，华为的KubeEdge就由此诞生了。华为的KubeEdge前生是华为的IEF，KubeEdge也就是基于IEF的某一个时候的分支分化出来的，华为决定开源，就有了现在的KubeEdge。
2. KubeEdge
KubeEdge是一个开源系统，用于将容器化应用程序编排功能扩展到Edge的主机。它基于kubernetes构建，并为网络应用程序提供基础架构支持。云和边缘之间的部署和元数据同步。
从上面的架构图可以很好的看出KubeEdge分为云和边两部分组成。云端即Cloud，边缘即Edge。这里顺便讲一下KubeEdge和K8s的关系，KubeEdge是依托K8s运行的，脱离k8s,KubeEdge是没有意义的，因为KubeEdge无非也就是定义了几个自己的CRD，搞了几个controller然后实现云边通信balabala...其实这东西没这么复杂。剥开KubeEdge的源码你会发现，里面竟然用到了client-go,这就更加说明了没有k8s，kubeedge其实啥也不是。唯一和k8s不同的是，在一个部署了KubeEdge的集群中，如果想要加入负载节点，不需要像k8s这样加入，从上面的架构图中可以很明显的看到，边缘端即Edge完全就没有kubelet这种东西，取而代之的是一个叫Edged的组件，这两个东西虽然名字不一样，不过功能是类似的，只不过因为边缘节点的资源实在是有限，所以Edged其实就是一个裁剪阉割版的kubelet。还是没有弄明白的话看下面的文章吧，我讲kubeedge部署的时候你就大概能看明白了，如果这样还是没有弄明白k8s与KubeEdge的关系的话，直接在下面的评论区留言，我和你好好掰扯掰扯。
1. Cloud
EdgeController & DeviceController & Cloud Hub
Cloud的核心组件是Cloudcore,这只是一个二进制而已，刚刚我也说了，核心就是controller，这里有两个controller，一个是EdgeController还有一个是DeviceController。其实这俩controller的作用从字面上就能看出来了。EdgeController是负责管控边缘Edge的，另一个DeviceController，就是负责管理设备相关的啦。KubeEdge的一大亮点就是本身自己就支持接入物联网的硬件设备。当然这也是KubeEdge定义了两个特殊的设备CRD，一个叫Device一个叫DeviceModel,然后边缘端部署Mapper(数据采集的应用，Mapper是KubeEdge的叫法)然后边缘到云的数据采集。这我只是说了一个大概，内部还有一些细节，具体的细节还是等我之后文章的写吧，我敢保证我输出的这些，在KubeEdge与IOT结合的场景下，也就是和设备相关的场景，如果你用KubeEdge，我输出的干货，不管是Google还是百度，在全球范围内搜索你都搜不到如此详细的实践细节与理论介绍，喝水不往挖井人，还是要感谢浙大SEL实验室,华为KubeEdge社区以及HarmonyCloud的支持。ok，回到正题，介绍完了controller，还剩下一个Cloud hub，这个组件就是Cloudcore和Edgecore交互的核心组件，edgecore通过websocket或者是quic接入cloudcore的cloudhub。
2. Edge
Edge的核心组件就是edgecore，和cloudcore一样也是一个二进制文件,edgecore相对于cloudcore而言，组件要多很多。
1. MetaManager
MetaManager模块后端对应一个本地的数据库（sqlLite），所有其他模块需要与cloud端通信的内容都会被保存到本地DB种一份，当需要查询数据时，如果本地DB中存在该数据，就会从本地获取，这样就避免了与cloud端之间频繁的网络交互；同时，在网络中断的情况下，本地的缓存的数据也能够保障其稳定运行（比如你的智能汽车进入到没有无线信号的隧道中），在通信恢复之后，重新同步数据。
2. Edged
之前提到过kubernetes的kubelet，它相当于k8s的核心。这块其实简单做了一些裁剪，去掉一些用不上的功能，然后就成为Edged模块，该模块就是保障cloud端下发的pod以及其对应的各种配置、存储（后续会支持函数式计算）能够在edge端稳定运行，并在异常之后提供自动检测、故障恢复等能力。当然，由于k8s本身运行时的发展，该模块对应支持各种CRI应该也比较容易。
3. EventBus/ServiceBus/Mappper
前面讲到的模块都与k8s直接或间接相关，接下来说下与设备（或者说真正IOT业务）相关的设备管理侧。外部设备的接入当前支持MQTT和Rest-API，这里分别对应EventBus和ServiceBus。EventBus就是一个MQTT broker的客户端，主要功能是将edge端各模块通信的message与设备mapper上报到MQTT的event做转换的组件；而ServiceBus就是对应当外部是Rest-API接入时的转换组件。说道这里，就有必要提一下MQTT broker，其实搞互联网的基本都用过类似于rabbitmq、activeMQ之类的消息中间件，其实他们就支持MQTT协议啦（可以理解为AMQP的精简版）。IOT的各种设备可能直接支持MQTT，但有的只支持蓝牙或者其他近场通信的协议。没关系，Mappper可以实现将各种协议转换为对MQTT的订阅与发布，从而实现与edge端的通信。当然，ServiceBus对应就适用于支持http协议的服务了。
4. DeviceTwin
edge端最后就剩下一个DeviceTwin模块了，要理解这个名词，就得提一下数字孪生这个概念。这里来科幻一下，假设人类要实现乾坤大挪移，但是有点难度的是，这下是要把你移到火星上。怎么办？这里有一个解决方案：在地球上通过扫描你的所有生物信息，生成拥有你完整生物特征的数据包之后，然后在地球上就把你毁灭了。再将描述你完整信息的数据包通过电波光速发送到火星上，让火星的设备再使用接收到的生物特征造出一个你。是不是挺可行！_ 回个头来，我们要说的数字孪生就是那个用来传输到火星的用于描述你所有生物特征的数据包；当然，这里对应就是接入设备信息。所以，DeviceTwin就是将这些信息保存到本地DB中，并处理基于cloud端的操作来修改device的某些属性（也就是操作设备）；同时，将设备基于eventBus上报的状态信息同步到本地DB和cloud端的中间人。
3. Mapper
Mapper不是EdgeCore的组件,但是和Edgecore有着密不可分的关系,Mapper是一个抽象的概念,在KubeEdge中专门指采集应用的程序，而且是以Container的形式运行在edgecore的Docker中(当然你可能用的并不是不是Docker,也可能是containerd等的别的CRI容器运行时)。Mapper是专门为KubeEdge在IOT场景下设计的，配合之前我提到过的Device和DeviceModel等等的CRD，简单的理解就在在传统的IOT工作的方式上加上容器编排部署的功能，这也就是KubeEdge的核心。截止到当前KubeEdge社区当前实现了Bluetooth和Modbus(RTU和TCP)的Mapper,CRD中还定义了OPCUA协议的相关字段，当前还没开发相关的Mapper。如果你有别的协议，比如是NB啊Lora啊要实现这些的Mapper，需要自己动手去开发，CRD中有预留字段给新的协议的。关于Mapper这东西具体咋玩的，后续我会在博客中更新，等着我更新就行。
4. 总结
整个KubeEdge的架构设计已经大概宏观的讲了一遍,Kubeedge一直在更新迭代，我现在写这篇文章的时候ke是v1.5.0版本，该版本实现了云边隧道,可以和k8s一样实现exec和log的功能。在边缘计算领域，ke相对而言是一个开源比较早的边缘计算框架，相比于Rancher的k3s 阿里巴巴的openyurt和腾讯的superedge这些项目而言，从实际的落地场景和社区的活跃度，ke都是比较健壮的，朝着一个良性的方向发展，而且在2020年已经成为了CNCF的孵化项目，笔者自己本身也是ke开源社区的贡献者，所以还是比较看好以后在边缘计算领域ke的发展，希望可以早日从CNCF毕业。