前言
如何让
- 不通类型
- 靠近用户侧、距Master节点较远
- 性能不足
的边缘计算资源，加入K8s集群称为受K8s-Master节点控制的特殊Node节点，并可以在这些边缘Node节点上部署、运行、管理这些容器应用？
边缘计算概念
边缘计算：就是将中心节点/K8s集群的能力延伸到边缘计算节点，使得边缘节点拥有云端相同能力，能够实时处理终端设备计算需求。
KubeEdge是1个致力于解决边缘场景问题的开源系统；
旨在Kubernetes原生的容器编排和调度能力之上，实现了云边协同、计算下沉、海量边缘设备管理、边缘自治等能力。
KubeEdge 架构如下图所示，包括云端和边缘端两部分。
Work-Node和Edge-Node区别
Kubernetes+容器的组合大大提高了用户部署应用的效率。
Kubernetes可以把多台主机整合成1个集群，用户在Master 节点上通过编写1个yaml 或者json 格式的配置文件，或者通过命I请求 Kubernetes API创建应用，就可以直接将应用部署到集群上的各Node，该配置文件中还包含了用户想要应用程序保持的状态，从而生成用户想要的环境。
Kubernetes 作为容器编排的标准，自然会想把它应用到边缘计算上？
即通过Kubernetes在边缘侧部署应用，但是 kubernetes 在边缘侧部署应用时遇到了一些问题，例如：
- 边缘侧设备没有足够的资源运行一个完整的 Kubelet（Node计算资源不足）
- 一些边缘侧设备是 ARM 架构的，然而大部分的 Kubernetes 发行版并不支持 ARM 架构（Node计算节点异构）
- 边缘侧网络很不稳定，甚至可能完全不通，而 kubernetes 需要实时通信，无法做到离线自治（Node计算节点和Master节点之间的网络）
- 很多边缘设备都不支持TCP/IP 协议（Node计算节点和Master节点之间的通信协议）
- Kubernetes 客户端（集群中的各个Node节点）是通过 list-watch 去监听 Master 节点的 apiserver 中资源的增删改查，list-watch 中的 watch 是调用资源的 watch API 监听资源变更事件，基于 HTTP 长连接实现，而维护一个 TCP 长连接开销较大。从而造成可扩展性受限。（Node计算节点和Master节点之间的通信效率）
为了解决包含但不限于以上 Kubernetes 在物联网边缘场景下的问题，从而产生了KubeEdge 。对应以上问题：
- KubeEdge 保留了 Kubernetes 的管理面，重新开发了节点 agent，大幅度优化让边缘组件资源占用更低很多
- KubeEdge 可以完美支持 ARM 架构和 x86 架构
- KubeEdge 有离线自治功能，可以看 MetaManager 组件的介绍
- KubeEdge 丰富了应用和协议支持，目前已经支持和计划支持的有：MQTT、BlueTooth、OPC UA、Modbus等
- KubeEdge 通过底层优化的多路复用消息通道优化了云边的通信的性能，可以看 EdgeHub 组件的介绍
