KubeEdge创始人 课后答疑——《KubeEdge架构与核心技术》

KubeEdge系列课程的第一课

项目地址（欢迎Star、Watch、Fork）： https://github.com/kubeedge/kubeedge

2019年11月14日视频直播了KubeEdge系列课程的第一课《KubeEdge架构与核心技术》，课程首先介绍了云原生、边缘计算的发展历程，从持续狂热的Kubernetes到飞速发展的边缘计算。再针对边缘计算网络不稳定、资源有限等条件下，分析了KubeEdge项目如何将云原生生态的众多标准与优势带到边缘计算。包括在K8s的应用编排、调度能力之上，构建的云边协同、边缘自治、应用管理、设备管理等能力。

本次课程的回放地址： https://huaweicloud.bugu.mudu.tv/watch/6oeddd7r

课后如下问题讲师进行了详细解答

Q1 ：KubeEdge云和边的数据协同有什么优势？

A1 ：K8s的原生架构中， Node (Kubelet) 是通过List-watch机制主动与Master通信。List-watch机制有几个特点：

1. 事件传输没有ACK类的校验机制，要依赖数据中心稳定的网络保证不丢事件

2. 每次网络断开，Node侧都会从新执行List操作(取回所有数据)，要依赖数据中心稳定的网络保证长连接不频繁断开，否则对Master及网络都是很大的损耗。

在边缘场景下，众所周知网络都是很不稳定的，包括丢失数据、连接断开等。针对不稳定的网络，在KubeEdge云边协同的设计中：

1. 我们把List-watch中的事件取出来，加了ACK校验机制，只有边缘收到数据且回复ACK信息，云端才认为发送成功，反之则进行重试。

2. 在网络断开(确认节点离线)后，云端会将待同步数据持久化，等到边缘节点上线，再将缓存的待发送数据逐一下发，3. 针对未发送的消息实时检查合并去重，避免网络震荡。

KubeEdge的云边协同机制不仅保证了云和边之间数据的可靠传输，也避免了网络不稳定时重新List造成的网络压力。

Q2 ：KubeEdge目前是如何解决边缘节点自治能力的？

A2 ：KubeEdge会边缘将收到的应用、设备元数据都进行本地持久化。相比Kubelet在内存中缓存对象的方式，可以有效保证节点离线、故障恢复时的业务自治和快速自愈。

Q3 ：边缘节点离线后，依赖数据多次变更，边缘应用和云端数据的最终一致是怎么保证的？

A3 ： KubeEdge目前的应用管理等操作都需要通过K8s master进行，针对边缘节点离线场景主要提供自治的能力，既本地持久化的数据仅用于管理节点上的应用和设备，云边通信恢复时，节点将同步云依据来自CloudCore的最新消息更新本地元数据。这里稍有不同的是边缘设备管理，对设备期望状态的设置需要通过Device CRD中的Desired State来操作（从云到边），而设备实际状态的上报会体现在Reported State中（从边到云），两个方向的数据同步不会冲突。

Q4 ：KubeEdge与K3s的区别是什么？

A4 ：首先是架构选型问题，K3s选择的是在边缘运行整个K8s集群的方案，不具备云边协同的能力；其次K3s虽然对K8s做了轻量化，但整体资源要求仍然较高，无法运行在IOT Hub、工业网关等小型设备中。

KubeEdge针对边缘场景的优化包括：

1. 针对边缘网络不稳定的情况，增加了云边数据协同的可靠性传输、边缘元数据持久化，减少了网络不稳定造成的压力震荡，实现了边缘离线自治的能力，在云边断联、节点故障恢复时保证业务不受影响。

2. 针对边缘资源不足的情况，对Kubelet进行轻量化裁剪，支持在256MB的设备上运行。

3. 针对复杂多样的边缘设备管理，KubeEdge定义了一套通用的设备管理API（K8s CRD）以及设备协议解耦层，用户可以方便地使用KubeEdge进行管理各种边缘设备。

Q5 ：中心K8s对边缘节点的管理主要操作有哪些？

A5 ： KubeEdge运行在K8s完整的应用调度、管理能力之上，意味着KubeEdge的云端不负责应用的调度、管理，只是将调度到边缘节点的应用、设备元数据下发到边缘。KubeEdge在云端的核心组件是CloudCore，包含EdgeController、DeviceController、CloudHub三个模块，EdgeController、DeviceController负责将应用、设备元数据下发到边缘，同时将来自边缘的节点状态、应用状态、设备状态刷新到K8s集群中；CloudHub负责直接与边缘通信。

Q6 ：新版本边缘节点的service还是仅支持hostPort吗，nodeport是否支持？

A6 ：从KubeEdge 1.1版本开始集成了CRI，意味着用户可以使用CNI插件来配置网络，不再限制于hostport。NodePort是K8s中服务访问的概念，需要通过Kube-proxy来配置，目前在边缘端还不支持。另外KubeEdge提供了EdgeMesh实现边缘应用间的互访。

Q7 ：边缘节点的Docker容器镜像是从整个云-边k8s系统统一的镜像仓库拉取的吗？

A7 ：只要边缘端能够访问到的镜像仓库，都能够用来拉取镜像。

Q8 ：PPT里提到"KubeEdge 用于将容器化应用程序编排功能扩展到Edge的主机。" 那么，是把云上的应用下沉到edge、还把终端设备上的应用提升到edge呢？

A8 ：KubeEdge作为应用管理平台时，可以在云端统一管控，既可以把应用部署到云端节点，也可以部署到边缘节点。用户可以根据自身需求，将云端的部分业务下沉到边缘。如果需要将终端设备上的应用部署到边缘节点，也可以通过KubeEdge来部署。

Q9 ：边缘侧的各个应用是怎么通信的？比如一个做sql过滤的应用和另一个做数据分析的应用是通过hub统一转发的，还是应用间就同步了，亦是通过mqtt等协议？同步异步消息分别怎么实现的？

A9 ：目前KubeEdge中使用EdgeMesh机制来做边缘端应用的互访，不需要通过hub与mqtt转发，在EdgeMesh实现应用互通的前提下，同步异步消息依赖用户应用自身的机制。

Q10 ：KubeEdge节点和普通节点都在 kubectl get node 中获取到，这两者有什么区别？

A10 ：没有本质区别，KubeEdge的边缘组件会将Node通过云边协同通道注册到K8s Master，唯一的不同是普通节点由Kubelet直接访问Master完成节点注册，KubeEdge是通过云边协同通道注册，API都是一致的。

Q11：KubeEdge的 modbus协议是用什么设备调试的？

A11： 目前开发调试中使用modbus slave来调试。

Q12 ：KubeEdge的安全层是怎么做的？

A12 ：KubeEdge云边协同使用了安全的WebSocket通道。对于应用间的安全互访要依赖用户自己配置安全证书等。

Q13 ：KubeEdge边缘节点能管理GPU设备吗？

A13 ：边缘节点可以通过DevicePlugin来管理GPU设备。

关于Kubeedge的网络问题、设备管理、边缘自治等细节问题，请锁定后续每周四晚上的相关课程。