Kubeedge架构介绍
Posted Armstlarm
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kubeedge架构介绍相关的知识，希望对你有一定的参考价值。
KubeEdge这个架构主要是分了云、边、端三部分
云上就是KubeEdge的控制面，边就是KubeEdge的边缘节点
端就是跑了一些端侧设备
云上是一个Kubernetes的master，是没有做过改动的原生的Kubernetes控制面
后边我们加了一个组件叫CloudCore
它云上的组件主要是会拿一些Kubernetes控制面上的东西
通过EdgeController和DeviceController做一些处理，然后通过下边的CloudHub
CloudHub主要是跟边端通信的
边端有个EdgeHub和Cloud Hub通信，然后把数据拿下来
边端是主要做了一个应用管理和设备管理的能力
应用管理左边会有一个Edged
右边有DeviceTwin、EventBus
分别是应用管理和设备管理
DataStore就是我们说的本地自治的能力
组件介绍：
CloudHub
CloudHub是cloudcore 的一个模块，是Controller（EdgeController和DeviceController）和Edge端之间的中介
它同时支持基于web-socket 的连接以及QUIC协议访问。
EdgeHub可以选择其中一种协议来访问CloudHub。CloudHub 的功能是实现边缘和控制器之间的通信。
边缘的连接（通过EdgeHub模块）是通过websocket连接上的 HTTP 完成的。
对于内部通信，它直接与控制器通信。
发送到CloudHub的所有请求都是context对象的请求，该对象与标记为其nodeID的事件对象的映射通道一起存储。
CloudHub执行的主要功能
获取消息context并为事件创建ChannelQ
通过websocket创建http连接
服务websocket连接
从边缘节点读取消息
将消息写入边缘节点
向Controller发布消息
DeviceController（设备控制器）
DeviceController是 KubeEdge 的云组件，负责设备管理。
KubeEdge 中的设备管理是通过使用 Kubernetes 自定义资源定义 (CRD)来描述设备元数据/状态和设备控制器来在边缘和云之间同步这些设备更新来实现的。
DeviceController启动两个独立的 goroutines，称为upstream controller和downstream controller。
DeviceController利用设备模型和设备实例来实现设备管理
设备模型：Device model描述设备和属性访问者公开的设备属性以访问这些属性。设备模型就像一个可重复使用的模板，使用它可以创建和管理许多设备。
设备实例：一个Device instance代表一个实际的设备对象。它就像一个实例化Device model并引用模型中定义的属性。
DeviceController主要功能
upstream controller
通过device twin将设备更新从边缘节点同步到云端。
downstream controller
通过在 K8S API 从云端更新边缘节点上的设备属性。
EdgeHub
EdgeHub负责与云中端的CloudHub组件进行交互。它使用 websocket 连接或使用QUIC协议连接到CloudHub。支持同步云端资源更新、报告边缘端主机和设备状态变化等功能。
EdgeHub 执行的主要功能
Keep Alive
发布客户信息
边端路由到云端
云端路由到边缘
DeviceTwin （设备孪生）
DeviceTwin 模块负责存储设备状态、处理设备属性、处理DeviceTwin操作、在边缘设备和边缘节点之间创建成员、将设备状态同步到云端以及在边端节点和云之间同步DeviceTwin信息。
它还为应用程序提供查询接口。DeviceTwin由四个子模块（即成员模块、通信模块、设备模块和设备孪生模块）组成。
以下是设备双控制器执行的功能：
将元数据同步到db（Sqlite ）和从db（Sqlite ）中获取数据
注册和启动子模块
向子模块分发消息
健康检查
Sedna终身学习以及KubeEdge梳理
文章目录
- 一、KubeEdge以及Sedna架构
- 二、Sedna边云协同终身学习
- 三、楼宇热舒适度预测案例流程
一、KubeEdge以及Sedna架构
1 KubeEdge架构及组件
1.1 整体架构
参考https://blog.csdn.net/qq_43475285/article/details/126760865
1.2 CloudCore组件
Edge Controller：管理边缘节点以及应用状态元数据云边协同。
Device Controller：负责接入和管理边缘设备。
Sync Controller：保持云边数据最终统一。
CloudAdmission Webhook：实现边缘应用最佳实践，扩展API输入校验。
CSI Driver：支持第三方CSI插件的无缝集成。
CloudHub：边云数据通道。
1.3 EdgeCore组件
EdgeHub：边云数据通道；通过Websocket连接CloudHub。
MetaManager：数据本地化。
MetaServer：MetaManager的子模块，使K8s Operator能够无差别的运行在边缘节点。
Edged：引用了上游K8s的Kubelet-Lite，并做轻量化的定制。与基于CNI标准的容器引擎进行对接。
EventBus：本质是一个MQTT客户端，与边缘设备通信。
1.4 EdgeMesh插件
EdgeMesh是KubeEdge在边缘场景下的网络边缘多边互通的一个解决方案。
组件：EdqeMesh-Server和EdgeMesh-Agent
参考https://github.com/kubeedge/edgemesh/blob/main/README.md
2 Sedna架构及组件
参考https://sedna.readthedocs.io/
1 GlobalManager
基于K8S操作符的边缘AI控制。
2 LocalController
管理边端AI以及边端的数据和模型资源。
3 Workers:
可以看作docker容器，基于需要被启用，可以在边节点或云节点运行。基于 机器学习框架，做训练、推理等工作。
4 Lib
exposes the Edge AI features to applications, i.e. training or inference programs.
二、Sedna边云协同终身学习
参考1Zheng Z, Luo P, Li Y, et al. Towards lifelong thermal comfort prediction with KubeEdge-sedna: online multi-task learning with metaknowledge base[C]//Proceedings of the Thirteenth ACM International Conference on Future Energy Systems. 2022: 263-276.
参考2https://www.bilibili.com/video/BV1ra411Z7sW/
1 边云协同机器学习的挑战以及解决方式
1.1 挑战
目前，边云协同机器学习面临复杂场景下的数据异构问题以及边缘节点样本数量少。
1.2 如何解决
借助于多任务学习和增量学习（在历史场景之间共享知识进行学习），以及云知识库（有memory，将历史知识应用在边端未见过的未知任务上），希望克服挑战。
2 经典终身学习框架与Sedna改进的终身学习框架
经典的终身学习不断地对KB做增量，也叫做增量学习。
但存在数据异构问题，也就是相同的输入，在不同的边侧，会有不同的标注结果，因此改进之后的终身学习架构（Sedna终身学习架构）添加基于任务的知识挖掘模块，只对特定知识进行增量。
3 Sedna边云协同终身学习技术方案
3.1 边云协同终身学习定义及流程
初始化知识库
在云侧知识库中存储和维护过去N个任务（记为第T-N到T-1个任务）中训练并累积的知识。
学习当前任务
在边侧设备面对当前任务（记为第T个任务）时，基于云侧知识库先验知识训练第T个任务。注意，第T个任务并不一定在历史的N个任务当中。
更新知识库
将学习到的边侧第T个任务知识反馈到云侧知识库并更新。
学习未来任务
持续学习未来M个任务（记为第T+1到T+M个任务）。与上面第T个任务利用过去N个任务知识（从T-N到T-1）类似，第T+1个任务的边侧任务知识则利用过去N+1个云侧任务知识（从T-N到T）。以此类推，直到完成第T+M个任务，结束整个流程。
3.2 元概念
3.2.1 元知识，Metaknowledge
元知识指knowledge of using models。
元知识就是映射关系，f，元知识库中的元知识越丰富，可以处理的任务就越多，model就越多。
元知识被一个元知识库保留和维护，这个元知识库可以通过扩展现有的元数据库（metadata base）来实现。
利用元知识，实现动态分配任务而不是对所有sample都使用固定的任务。
3.2.2 元知识的阶，Order
用n表示。
如果为0阶，那么metadata，metaknowledge和metalabel 就分别对应经典机器学习中的data, knowledge和label。
如果为1阶，那么元知识体现了一个任务中一群样本的信息，这是样本群/任务level，而不是0阶的单个样本level。
也就是把0阶的特征抽象了。因此一阶元知识是0阶元知识的元知识。
3.2.3 元数据，Metadata
记作m，x
样本数据中具有代表性的项，例如季节、温度。
提取一阶元数据：
3.2.4 元标签，Metalabel
一个样本在一个任务上的预测置信度。
通过元标签选择最适合的知识（也就是模型），也就是通过元标签决定某个任务是否适合决策某个样本。
3.3 舒适度预测终身学习框架
下图为舒适度预测终身学习框架。
共有五个关键模块：元知识初始化，任务分配，未知任务识别，未知任务处理以及元知识库。
3.4 元知识初始化（元学习）
3.4.1 定义
此过程为“通过元学习从元数据中提取元知识”。
是对有label的数据进行知识提取。
元学习可在基础模型（XGBoost，SVM，神经网络等）的基础上，进一步学习，有很高的灵活性。
3.4.2 元学习过程
1、元知识库提供元数据attribute以及模型；建筑系统提供样本（包含data value: x和label: y）
2、通过data value和元数据attribute提取一阶元数据。（下图左侧）
3、通过模型，data value以及label计算出元标签，元标签反映了把一个任务用在一个样本上的置信度。（下图右侧）
4、找到在此样本上置信度最高的模型，就是我们要的元知识。
5、总结：此过程针对首先基于知识库对样本进行特征提取得到元数据，再为元数据寻找最合适的模型（通过label以及置信度），也就是通过元数据提取了元知识。
3.5 任务分配（推理阶段）
从这一步开始，才真正开始推理。
本质是一个决策模型。
对推理样本和任务（元知识库中已有的的元知识）进行相似度计算（也就是预测的置信度），分配相似度最高的模型用于推理。
3.6 未知任务识别以及处理（知识库更新）
虽然我们的知识库中有很多任务，但随着新任务的到来，知识库需要基于新任务进行更新以保持可用性。
3.6.1 如何检测未知任务
1、未知任务的定义：当任务的n阶元知识和推理样本的n阶元知识的相似度大于某一阈值时，那么这个样本属于未知任务。
2、本文通过两个相似度算子，来评估当前任务与已有任务之间的相似性。
分别为0阶元知识（模型相似度）和1阶元知识（属性相似度）
3.6.2 知识库更新的四种操作（未知任务处理）
1、0阶和1阶元知识都很相似——Metaknowledge Reservation
此时为已知任务，无需更新模型，直接应用模型进行推理。
2、0阶不相似，1阶相似——Metaknowledge Remodeling
没有好的模型来拟合，因此进行模型重建，如上图左下。
3、0阶相似，1阶不相似——Metaknowledge Rescoping
在元知识库中没有一个完美的任务属性元模型，应对任务进行元学习，重新抽取任务属性。
4、0阶和1阶都不相似—— Metaknowledge Accumulation
那么此任务属于当前元知识库完全未知的任务，那么增加新任务。
3.7 基于Brick的元知识库
Brick是一个元数据库，它为建筑学中的知识建模，但并不提供终身学习的特性（例如添加新的attribute或元知识）。
基于Brick开发了元知识库用于提供和保留元数据和元知识，并提供终身学习特性。
把任务定义为由模型，属性，样本构成的三元组；通过属性得到最接近的任务，使用该任务的模型进行推理。
下图红框内为Task6的三元组。
3.8 多任务训练以及模型可插拔
LEON可以适应多任务学习中的各种基础模型（XGBoost，SVM，神经网络等），而不是必须依赖某一种模型，即模型可插拔，因为LEON在基础模型（黑盒）的基础上进行元学习，这黑盒是可插拔的。
有了LEON，人们可以使用XGBoost和SVM等任意模型来建立终身服务，只需进行很少的修改。
3.9 此框架（LEON）的计算性能
3.9.1 性能相比FR较好
Frequent Re-training (FR)指新sample到来时，重新训练所有model和attribute。
Leon相比FR，相同准确率下，在8至33个任务的测试中，平均快了217倍多。
3.9.2 原因
1、LEON通过任务分配（3.5）只更新一个目标任务，而不是重新训练所有任务。
2、LEON可以只更新一个未知任务的一部分，即任务属性或模型（3.6.2的情况2和3）；并且无需更新已知任务。
3.10 实验
3.10.1 数据集
使用ASHRAE Global Thermal Comfort Database II (ATCII)数据库，包含了1995至2015年间，28个国家99个城市超过60000条数据。
在实验中预测“热感觉”和“热偏好”这两个较为直接的舒适度指标。
3.10.2 训练过程
将整个数据集分为12个子集，每个子集有5337个sample。
1、训练集
其中11个子集用于训练，第一个子集用于系统的初始化，接下来，为了模拟终身学习中数据持续到来这一特征，每次都做增量训练。共11轮。
以4:1的比例从训练集中拆分验证集。
2、测试集
第12个子集用作测试集。
3.10.3 六种基线方法（Baseline Methods）
1、Predicted Mean Vote (PMV)
是一个用领域知识而不是机器学习构建的知名综合模型。
2、Single Task Learning (STL)
通过汇集所有任务的初始训练数据来学习单个模型。
3、Metadata-based Multi-task Learning (DUET)
使用元数据来分配任务，但不维护知识，不提供终身学习特性
4、Online single task learning (OSTL)
数据持续到来的STL。
5、Traditional lifelong learning (TLL)
基于给定的任务在线学习。
6、Lifelong memory learning (LML)
用知识在线学习，而LEON是用元知识学习。
3.10.4 Criterion以及LEON的表现
3.10.4.1 SMAPE（Symmetric Mean Absolute Percentage Error）
1、对称平均绝对百分比误差，用作损失函数。
用SMAPE作为损失函数可以惩罚明显的错误，例如ground truth是“want cooler”，那么“want warmer”相比“want no change”得到更大的惩罚。
2、结果
（1）在线学习的优势
将4种在线学习算法（OSTL, TLL, LML and LEON）与3种非在线学习算法（PMV, STL, DUET）比较，在线学习算法总体上强出13.64%。
而仅看LEON相比3种非在线学习算法（PMV, STL, DUET），如Figure 7，我们看到LEON总体上通过数据增量逐渐提高其学习能力，而非终身学习算法由于只有一次训练的性质而无法改进（fiexed model无法向终身学习模型那样积累知识）。
（2）元知识的优势
LEON与其他三种终身学习算法的主要区别就是是否使用了元知识。
LEON引入元知识来正确地积累、维护和重用多任务知识，如Figure 8。然而，非元知识方法无法了解生成了什么知识以及何时使用知识，导致学习能力较低。
注意Table 4中的Std，OSTL是单任务设定，不能有效地处理数据异构，因此相比其他三种多任务学习方法，显示出较大的性能波动。
3.10.4.2 BWT（Backward Transfer）
这个指标反映知识库在生命周期中在数据增量和处理后，对之前遇到的任务性能的影响。
反映了灾难性遗忘。
下图说明LEON利用元知识更好地记忆和表示了历史任务，较好的缓解灾难性遗忘问题。
3.10.4.3 FWT（Forward Transfer）
这个指标反映了预测未知任务的能力。将现有的模型应用于未知任务是终身学习的重要部分。
如下图，LEON展示出了很好的泛化能力，因为元知识库中储存多任务知识，并且能用在未知任务上。
3.10.4.4 0阶1阶元知识相似度阈值的选取
增大0阶和1阶阈值的选取都会对准确率有负面的影响，因为更大的阈值会带来元知识库更少频率的更新。但是，更大的阈值选取可以防止频繁的retaining，以减少训练时间。
推荐的0阶和1阶阈值分别为0.5和1。
三、楼宇热舒适度预测案例流程
参考1 https://sedna.readthedocs.io/en/latest/proposals/lifelong-learning.html
参考2 https://github.com/kubeedge/sedna/blob/main/docs/proposals/incremental-learning.md#details-of-api-between-gmcloud-and-lcedge
参考3 https://zhuanlan.zhihu.com/p/378501662
3.1 总体流程
3.1.1 阶段及状态
共有三个阶段: train, eval, deploy
每个阶段有几种状态: Waiting, Ready, Starting, Running, Failed, Completed.
3.1.2 Sedna边云协同终身学习框架
维护一个全局可用的知识库（KB）服务于每个终身学习任务。
Workers之间不需传输数据。
3.2 Job Creation
训练和评估在云侧，部署到边侧，推理在边侧。
3.3 训练
3.3.1 训练流程
1、数据（旧数据以及边侧采集到的新数据）传输至负责训练的Cloud Node的LC中。（步骤2）
2、LC此时已准备成功，向GM发送Ready to do training消息，GM发送给K8S。（步骤3&4）
3、K8S在此Cloud Node创建Train Worker。
4、开始训练，训练结束之后更新KB。（步骤5）
3.4 评估
3.4.1 评估流程
1、评估全部为云侧进行。
2、Cloud Node中的Train Worker训练结束之后，告知自己Cloud Node的LC训练已完成。（步骤1）
3、LC通信GM，GM再通信K8S，更新状态。
4、K8S创造Evaluation Worker（仍在此Cloud Node中）。
5、Evaluation Worker向LC报告工作的状态以及evaluation的结果。（步骤五）
6、如果评估结果不错，进行3.5的部署到边端。
3.5 部署
3.5.1 部署流程
1、Evaluation Worker将评估结果发给LC。（步骤1）
2、如果结果较好，向GM以及边端进行同步。
3、Edge Node的LC中的Model Mgmt模块将overwrite模型。（步骤5）
4、Edge Node的LC向GM发送它已经处于准备部署的状态，GM再发至K8S。（步骤6&7&8）
5、K8S在此Edge Node中创建Inference Worker。（步骤10）
6、Inference Worker重载新模型，并开始工作。（步骤11）
以上是关于Kubeedge架构介绍的主要内容，如果未能解决你的问题，请参考以下文章