【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
11月21日视频直播了KubeEdge系列课程的第二课《KubeEdge云边协同&云端组件设计》，课程首先回顾了KubeEdge的云、边、端三层整体架构。再针对KubeEdge的云上部分，分析了云端组件与K8s Master的关系、各个云端组件的设计原理，Device API的设计原理、云边消息可靠协同的设计原理等，详情见本次课程回放。
回放地址：
Q1：云端环境部署好后，状态处于Notready，云端检测边缘端状态流程是怎样的？（k8s版本 1.15.0，docker -ce 1.18，ubuntu 最新版本）
A1：云端检测边缘节点状态的工作流程：1. 边缘节点通过Edgehub->Cloudhub->EdgeController->KubeAPIserver将节点状态信息上报到K8s中。之后流程与K8s原生架构一致， 根据上报的状态信息，K8s通过原生的node-controller来设置node的状态。
云端环境部署好后，状态处于Notready，可能的情况是云边的通道（Cloudhub与Edgehub）通信失败，考虑网络地址或证书配置有问题。
Q2 ：能否简单对比KubeEdge与国内外的主流同类型平台产品
A2：
1. 同类平台里的EdgeX Foundry偏重于端侧设备的管理，提供了一些设备接入、边缘数据传输等场景的实现，但不具备云上对边缘端的应用和设备的管控、云边协同等智能边缘系统的能力。
2. K3s已在上节课中提到过，K3s选择的是在边缘运行整个K8s集群的方案，不具备云边协同的能力；其次K3s虽然对K8s做了轻量化，但整体资源要求仍然较高，无法运行在IOT Hub、工业网关等小型设备中**。**
3. KubeEdge打通了云、边、端的整体流程：
· 用户能够在云上统一管理边缘节点上的应用、设备
· 提供了云边协同的能力，能够同步云边的应用、设备的数据
· 针对复杂多样的边缘设备，KubeEdge定义了一套通用的设备管理API（K8s CRD）以及设备协议解耦层，用户可以方便地使用KubeEdge在云上管理各种边缘设备
· 针对云边网络不稳定的情况，提供了云边数据协同的可靠性传输、边缘元数据持久化
· 针对边缘资源不足的情况，轻量化裁剪了Kubelet，支持在256MB的小型设备上运行
Q3 ：目前KubeEdge支持的设备是哪些？
A3：KubeEdge通过MQTT Broker将设备变化状态通过边缘节点上传到边缘节点再到云端。支持MQTT协议的设备可以直接接入到KubeEdge。
使用专有协议（非MQTT）的设备，可通过协议转换器Mapper将数据处理转成MQTT接入KubeEdge。目前KubeEdge针对工业设备场景在DeviceAPI中内置了Bluetooth、Modbus、OPC-UA三种常见通信协议的设备支持，减少了用户设备接入的准备工作。对于尚未内置的协议，用户也可参考KubeEdge给出的设备管理标准自行实现Mapper来接入边缘设备。
Q4 ：在KubeEdge中，有云、边、端，那端中软件服务有吗？有哪些？硬件又包括哪些设备呢？
A4 ：端的硬件、软件都由用户提供，只要满足KubeEdge的接入协议标准的设备，都可以接入到KubeEdge平台。
Q5 ：KubeEdge边缘端的容器监控，哪个版本能够支持？比如在云端执行：kubectl top 命令。
A5 ：目前已有规划支持边缘端基于cAdvisor的容器监控，预计在1.3版本（2020年Q1）中支持。
Q6 ：CSI的插件必须部署在云端吗？
A6 ： K8s社区推荐方案中使用DaemonSet部署的agent组件（node-registrar以及实际的存储后端）应该部署在边缘，而管理面组件（external-provisioner、external-attacher、KubeEdge-CSI-driver）要部署在云端。
Q7 ：KubeEdge的API调用方式，是否计划提供sdk调用方式？
A7 ：由于KubeEdge不屏蔽K8s APIserver，涉及原生功能的API可以直接使用K8s client-go调用，KubeEdge扩展的API，计划于1.3版本（2020年Q1）提供SDK
全开放的项目，完全包容的社区，等你来star和贡献，项目地址：
kubeedge/kubeedge
来源：oschina
链接：https://my.oschina.net/u/4425967/blog/3151013