云端组件CloudCore与k8s Master的关系
从黑盒角度看，CloudCore就是k8s的一个插件，它是非侵入的来扩展k8s的一部分功能，将原来云上的节点映射到边缘端进行管理，一个CloudCore可以管理多个边缘节点。
CloudCore里面有EdgeController、DeviceController、CSI Driver、Admission Webhook以及CloudHub这些组件。
EdgeController详解
upstream处理上行数据（与原生k8s中kubelet上报自身信息一致，这里主要上报边缘节点node状态和pod状态）；downstream处理下行数据。云边协同采用的是在websocket之上封装了一层消息，而且不会全量的同步数据，只会同步和本节点最相关最需要的数据，边缘节点故障重启后也不会re-list，因为边缘采用了持久化存储，直接从本地恢复。本地数据怎么实时保持最新？就是通过downstream不断从云上发生变更的相关数据往边缘去同步。
kubernetes中拉起应用的过程
workload controller是k8s中管理各种应用类型的控制器，管理各种应用的生命周期，以goroutine方式运行在controller manager中，是k8s原生的组件。
0. workload controllers(这里用deployment controller举例) 会watch所有deployment对象，scheduler主要watch未分配节点的pod对象，kubelet watch的过滤条件是调度到本节点的pod
通过命令行创建一个Deployment
api server就会做对应的存储（所有集群状态的查询都是通过api server与etcd的交互进行的）
etcd会有一个反馈给api server
api server会把这个事件反馈给订阅了这个事件的组件，比如deployment相关事件会反馈给deployment controller组件
deployment controller watch到变化后，根据定义文件去发出创建相应pod事件
api server修改etcd中pod的信息
etcd接着反馈给api server资源变更事件
api server把pod create事件反馈给scheduler
scheduler会根据它加载的调度策略在集群中找到一个合适节点 ，更新pod字段信息
api server修改etcd中pod信息
etcd返回给api server pod Bound(update)事件
订阅相关node name pod的kubelet就会收到事件通知，然后执行拉起动作
图中黄色框就是kubeedge中通过CloudCore加边缘节点组件做等价替换的范围。
KubeEdge拉起边缘应用前面部分都一样，系统起来的时候，CloudCore里面的EdgeController会watch很多资源，对于pod来说，它会watch所有pod，但它里面会有一个过滤，但是过滤不会反映在list-watch上， 只在内部做下发的时候处理。
12. CloudCore收到pod变更通知后，会在内部循环中做条件的判断，看pod中的nodeName字段是不是在它所管理的边缘节点范围。如果是，它会做一个事件的封装发送到CloudHub中去
13. CloudHub对事件做完消息的封装和编码后会通过websocket通道发送到每个边缘的节点，边缘节点的EdgeHub收到消息后解开去查看pod的信息，然后发送到MetaManager组件
14. MetaManager会把收到的pod进行本地持久化
15. MetaManager在把pod信息发送到Edged(轻量化的kubelet)，去拉起应用
Device CRD和DeviceController的设计
这个完全是一个operator的典型设计和实现，有一个自定义的API对象以及有一个相应的自定义controller去管理该对象的生命周期。
DeviceModel设备模版抽象关于设备的API有两个：DeviceModel（来定义一种型号的设备），另一个是Device设备实例的API，这两个的关系就像是类和对象的关系。
DeviceInstance设备实例的定义
DeviceController