【Kubenetes】边缘计算KubeEdge架构设计详解

Jzin

已于 2024-05-16 15:02:08 修改

阅读量680

点赞数 19

分类专栏： kubernetes k8s 云原生文章标签：边缘计算云原生物联网

于 2024-05-16 15:01:41 首次发布

本文链接：https://blog.csdn.net/the_shy_faker/article/details/138942588

版权

kubernetes 同时被 3 个专栏收录

7 篇文章 0 订阅

订阅专栏

k8s

7 篇文章 0 订阅

订阅专栏

云原生

7 篇文章 0 订阅

订阅专栏

前言

从微服务的角度

在现代应用程序开发中，微服务架构已成为构建灵活、可扩展和易于维护系统的首选模式。KubeEdge通过其架构设计支持微服务的分布式部署和管理，使得开发者能够轻松地在边缘计算环境中实现微服务化。KubeEdge结合了Kubernetes强大的容器编排能力和边缘计算的特点，为微服务在边缘的部署提供了高效的解决方案。

从云原生的角度

云原生技术推动了应用程序的革新，通过容器化、服务网格、不可变基础设施等技术实现了应用的高可用性和高弹性。KubeEdge是一个扩展Kubernetes到边缘计算的开源平台，其设计理念完全符合云原生应用的要求。它允许开发者在边缘设备上运行容器化应用，提供一致的管理和运维体验，并且可以无缝集成到现有的云原生生态系统中。

从物联网的角度

物联网（IoT）设备的快速增长带来了数据处理和管理的新挑战。KubeEdge旨在解决这些挑战，通过在边缘设备上提供强大的计算能力和灵活的部署选项，显著降低数据传输的延迟并提升系统的响应速度。KubeEdge支持多种协议的设备接入和管理，使得物联网应用可以在边缘实现实时的数据处理和分析，满足了物联网场景对低延迟和高效能的需求。

通过结合微服务、云原生和物联网的优势，KubeEdge在边缘计算领域提供了一个全面而强大的解决方案，使得边缘计算的应用开发和部署变得更加高效和便捷。

KubeEdge云边通信方式

GitHub地址：https://github.com/kubeedge/kubeedge

从官网的架构设计图来看：
在这里插入图片描述
根据KubeEdge的官方架构图,云端和边缘节点之间的通信主要通过以下几个组件完成:

Cloud Hub:位于CloudCore层,作为云端和边缘节点之间通信的网关,接收并处理来自边缘端EdgeHub的请求。
EdgeHub:位于EdgeCore层,负责与Cloud Hub进行交互,充当Web Socket客户端,与Cloud Hub进行安全通信。
EdgeController和DeviceController:位于CloudCore层,分别处理来自边缘节点的资源操作请求和设备管理操作。

图中显示Cloud Hub和EdgeHub之间存在双向通信通路,实现了云端和边缘环境之间的数据交换和控制流。
在这里插入图片描述

例如：当用户(K8S API Server)在云端进行操作时,EdgeController和DeviceController会处理相关请求,并通过Cloud Hub与EdgeHub进行通信。同样,边缘设备的事件或数据也可以通过EdgeHub和Cloud Hub传输到云端。
该架构使得云端能够高效管理边缘资源、部署应用程序,并在云端和边缘环境之间安全、可控地传输数据。

云端架构设计

在这里插入图片描述
根据KubeEdge的官方架构图,云端(Cloud)部分主要由以下几个核心组件组成:

K8S API Server: Kubernetes API服务器,作为整个Kubernetes集群的入口点,接收和处理所有针对Kubernetes资源的请求。

Controllers:

EdgeController:

（配置）处理来自边缘节点的资源操作请求,如Pod、ConfigMap等资源的创建、更新和删除。

（搭配edge架构图一起看）

云到边：

用户：用户通过kubectl与Kubernetes API服务器进行交互，kubectl是一个用于与Kubernetes API服务器通信的命令行工具。

K8S-Api-Server：这是Kubernetes的API服务器，负责管理所有的管理任务。它处理REST请求，验证这些请求，并在数据库（etcd）中更新相应的对象。

Rest客户端：该客户端将来自Kubernetes API服务器的命令转发到EdgeController。

EdgeController：这是KubeEdge中的核心组件，充当云和边缘之间的桥梁。它管理多个关键功能：

更新Pod ConfigMap：处理部署在边缘的Pod的配置更新。
添加新的Pod ConfigMap：为新部署的Pod添加配置信息。
删除Pod ConfigMap：当Pod不再需要时，删除其配置。
管理Pod、ConfigMap和Secret：创建管理器以处理这些资源，确保资源的同步和更新。
定位ConfigMap和Secret：确定将ConfigMap和Secret发送到哪个节点。
CloudHub：作为云端组件，负责与EdgeCore的通信。它通过TCP/WebSocket协议与EdgeCore保持连接。

EdgeCore：位于边缘部分的组件，负责执行来自CloudHub的指令，并管理边缘节点的资源和应用。
在这里插入图片描述

边到云

EdgeCore：这是位于边缘节点的主要组件，负责处理和执行所有来自云端的命令以及管理本地资源和应用。EdgeCore还负责监控Pod的状态和条件，并将相关信息通过TCP/WebSocket传回云端。

TCP/WebSocket连接：这是连接云端和边缘端的通信协议，保证数据传输的实时性和可靠性。

CloudHub：作为云端的组件，它接收来自EdgeCore的信息，如Pod状态更新、配置查询和消息。CloudHub处理这些来自边缘的数据，并相应地更新云端的Kubernetes API服务器。

EdgeController：在云端进行操作，它管理来自边缘节点的数据和请求。主要功能包括：

更新Pod状态：接收来自边缘节点的Pod状态更新，并对Kubernetes API进行更新。
查询ConfigMap/Secret：处理来自边缘节点的配置和秘密数据的查询请求。
创建StopMessage通道：为了能够控制和管理边缘节点的操作，如需要停止某些服务或应用时。
更新Pod条件：根据从边缘节点接收的数据更新Pod的运行条件。
K8S-Api-Server：Kubernetes的API服务器，这是云端的中心节点，负责处理所有Kubernetes资源的管理和调度。

REST客户端：它在云端与Kubernetes API服务器之间进行通信，传达EdgeController的命令和请求。

通过这样的结构，KubeEdge可以有效地在云端与边缘端之间进行数据和命令的双向同步，确保边缘计算资源的高效管理和云端策略的实时更新。这种模式适合需要低延迟处理和地理分布式处理的应用场景。
在这里插入图片描述

DeviceController:

云到边

（业务）处理来自边缘节点的设备管理相关操作,如设备注册、设备状态更新等。

Kubernetes API：用户通过kubectl命令行工具与Kubernetes API进行交互，执行诸如创建、修改或删除设备（device）或设备模型（device model）的操作。这是设备管理的入口点，允许用户从中央位置管理边缘设备的配置。

观察设备模型更新和设备更新：在Kubernetes服务器端，设备模型和设备的更新被监视。这包括对设备配置的任何更改，如属性或行为的更新，这些更改需要同步到边缘设备。

创建/删除配置映射：作为设备配置管理的一部分，可以创建或删除配置映射（ConfigMaps），这些映射存储设备配置数据，以便可以动态地将配置推送到边缘设备。

CloudHub：CloudHub作为云组件，负责处理来自Kubernetes API的设备管理指令和配置数据，然后将这些数据通过Downstream通道发送到边缘。它是云端和边缘之间通信的中枢。

Downstream：这是一个通信通道，CloudHub通过它向边缘设备发送数据。这包括：

发送设备双胞胎所需/报告的属性更新：设备双胞胎（Device Twin）是设备在云中的镜像，反映设备的当前状态和所需状态。此过程确保设备的状态始终与云端同步。
发送节点成员身份更新：更新有关哪些设备属于哪些节点的信息，这对于设备在边缘的管理和运维至关重要。
通过这样的架构，KubeEdge能够有效地实现从云到边的设备管理和状态同步，确保边缘设备可以根据云端的最新配置和指令进行操作，同时保持设备状态的实时更新。

边到云

CloudHub：作为云端组件，CloudHub负责接收来自边缘节点的数据。在这个上下文中，它主要处理来自设备的属性值报告。

Upstream：这是从边缘到云端的数据传输通道。在这个通道中，设备的双胞胎报告的属性值通过CloudHub上传到云端。这些属性值可以包括设备的状态、测量数据或其他相关信息。

设备双胞胎属性值报告：设备在边缘节点上的状态或属性更新，被作为"设备双胞胎报告的属性值"通过Upstream发送。设备双胞胎模型允许云端维护设备的一个虚拟表示，这个表示包括设备的预期状态和实际报告状态。

更新设备双胞胎报告的属性值：一旦设备的状态或属性在边缘发生变化，这些新的数据点将通过CloudHub上传，并通过Kubernetes API更新到设备双胞胎的模型中。

Kubernetes API：更新反映在Kubernetes服务器端，确保设备双胞胎的记录与设备的实际情况保持同步。

这个过程确保了设备状态的实时反馈到云端，允许管理员能够基于最新数据进行决策和管理。这种从边到云的数据流是KubeEdge用于高效设备管理和状态监控的关键组成部分。
在这里插入图片描述

Cloud Hub:作为云端和边缘节点之间的通信网关,负责接收并处理来自EdgeHub的请求。它扮演着云端和边缘之间数据交互和控制流转发的中介角色。

云端架构的设计思路是将边缘计算相关的控制面与Kubernetes控制面相结合。当用户通过K8S API Server发起操作请求时,EdgeController和DeviceController会分别处理相应的资源管理和设备管理请求,并通过Cloud Hub与边缘端EdgeHub进行通信,从而实现对边缘节点的控制和管理。

这种设计使得KubeEdge可以无缝地将边缘资源纳入Kubernetes管理体系,并利用Kubernetes现有的控制平面扩展边缘计算的能力。同时,云端架构也为边缘节点提供了资源调度、应用部署、设备管理等功能,支持跨云端和边缘端的统一管理。

边缘端架构设计

在这里插入图片描述
重要的是：

Edged边缘后台进程核心模块
MetaManager 元数据管理
DeviceTwin 设备孪生
EventBud/ServiceBus总线

Edged

一共有11个模块

在这里插入图片描述
分为5大部分

Pod的管理部分

pod的增删改查和运行时

Pod Management（Pod 管理）:
功能: Pod Management 负责在边缘端创建、修改、删除和查询Pods。它确保Pods的状态与API服务器中的期望状态一致。
工作流程: 当API服务器下发Pod创建指令时，Edged的Pod Management模块会接收到这些指令，并负责在本地创建和配置Pod。这包括配置网络、分配资源等。此外，它还会监控Pod的状态，如运行状况、重启、停止等，并将状态信息报告回云端。
Container Runtime（容器运行时）:
功能: Container Runtime 模块负责实际的容器操作，包括启动、停止、暂停容器等。它与容器运行时接口（CRI）兼容，支持不同的容器运行时如Docker、containerd等。
工作流程: 在Pod Management模块创建Pod后，Container Runtime模块接管对容器的具体操作。它根据Pod定义中的容器规格来启动或管理容器。这包括从镜像仓库拉取镜像、创建容器、执行容器、监控容器的运行状态以及在必要时进行容器的停止和清理。

Pod的监控部分

简称PLEG

Probe Management（探针管理）:
功能: 探针管理是用于执行和管理探针（Probes），探针是Kubernetes中用来检查Pod中容器是否健康的机制。它包括Liveness Probes（存活探针）、Readiness Probes（就绪探针）和Startup Probes（启动探针）。
工作流程: Probe Management负责定期执行探针检查，并根据探针的响应来判断容器的状态。例如，如果一个容器的Liveness Probe失败，表明容器已不再运行，Probe Management会触发容器的重启。
Pod Status Management（Pod状态管理）:
功能: 此模块负责追踪和更新Pod的状态信息。它确保Pod的当前状态能够被准确地报告给云端的Kubernetes API服务器。
工作流程: Pod Status Management模块监控各个Pod的状态变化，如运行、暂停、停止等，并将这些信息通过边缘到云的通信通道同步到云端的etcd存储中，保证数据的一致性和准确性。
Pod Lifecycle Event Generator（Pod生命周期事件生成器）:
功能: 该模块生成与Pod生命周期相关的事件，如创建、启动、停止、删除等，并将这些事件通知给其他模块或同步到云端。
工作流程: 当Pod的生命周期状态发生变化时，Pod Lifecycle Event Generator将生成相应的事件。这些事件可以被其他模块（如Pod Status Management）使用来更新Pod的状态，或者被上报到云端，供用户或其他系统组件查询和监控。

Pod的卷管理

不管是Secret还是ConfigMap统一为卷管理

Volume Management（卷管理）:
功能: 卷管理模块负责Pod中各种类型卷的生命周期管理，包括持久卷（PVs）、临时卷（ephemeral volumes）等。此模块确保卷的正确挂载和卸载，以及与存储资源的接口。
工作流程: 当Pod创建请求发起时，Volume Management模块会根据Pod定义中指定的卷配置，执行卷的挂载操作，将存储资源连接到Pod中相应的容器。在Pod终止时，此模块也会负责卸载卷，清理资源。
Secret Management（秘密管理）:
功能: Secret Management模块负责管理和提供Kubernetes Secrets，这些是用来存储敏感信息如密码、令牌等的对象。
工作流程: 在Pod配置中如果指定了需要使用Secrets，Secret Management模块会从云端同步这些Secrets到边缘节点，并确保它们被安全地传递并挂载到相应的容器中。这样，应用程序就可以在运行时安全地访问所需的敏感信息。
ConfigMap Management（配置映射管理）:
功能: ConfigMap Management模块负责处理Kubernetes ConfigMaps，这些是用来存储非敏感配置数据，如配置文件、命令行参数等。
工作流程: 类似于Secrets管理，ConfigMap Management模块负责从云端同步ConfigMaps到边缘节点，并将它们挂载到Pod中指定的容器内。这允许应用使用这些配置数据进行自我调整或调优。

Pod的垃圾回收

Container Garbage Collection（容器垃圾回收）:
功能: 此模块负责清理不再需要的容器，这些容器可能是因为Pod更新、删除或其他操作而变得多余。
工作流程: Container Garbage Collection模块监控容器的状态，并定期检查是否有停止运行的容器。对于这些停止运行的容器，如果它们不再被任何当前运行的Pod引用，该模块将执行清理操作，删除这些容器以释放系统资源。
Image Garbage Collection（镜像垃圾回收）:
功能: 镜像垃圾回收模块负责从节点上删除不再需要的容器镜像。在边缘设备上，存储空间可能特别宝贵，因此有效管理镜像存储是至关重要的。
工作流程: 此模块定期检查节点上的镜像使用情况，特别是那些未被任何当前容器使用的镜像。它根据一定的策略（如镜像的年龄、使用频率等）来决定哪些镜像应该被删除。当确定一个镜像不再需要时，它会从本地存储中删除这些镜像，从而回收空间。

Pod同步管理

从云端拉下来的数据不是直接给Edged的而是通过MetaManager进行缓存再到Edged的
MetaClient能保证Edged照常运行只是说状态不能完全保证上报到云端仅此而已
所以说离线之后 Edged里的Pod能照常运行
等会再细讲MetaManager

MetaClient：

MetaClient 主要负责同步边缘节点上的资源状态信息到云端，这包括但不限于Pods, Nodes, ConfigMaps, Secrets等Kubernetes资源的元数据。通过这种同步，云端的Kubernetes API服务器能够获取到最新的边缘节点状态，从而进行适当的管理和调度决策。

工作流程

数据收集：MetaClient 定期从Edged的其他模块收集资源状态数据。这些数据包括资源的创建、更新、删除等事件。
数据缓存：收集到的数据会被暂存于本地缓存中。这样做的目的是减少因网络问题导致的数据同步失败，同时也可以在网络不可用时继续收集和存储本地数据。
数据同步：当网络连接可用时，MetaClient 会尝试将缓存中的数据同步到云端的Kubernetes API服务器。同步过程中，它会处理可能出现的数据冲突和依赖问题，确保云端的数据状态准确反映边缘节点的实际情况。
错误处理和重试机制：在数据同步过程中，如果遇到网络中断或其他导致同步失败的情况，MetaClient 会利用其内置的重试机制尝试重新同步，直到数据成功上传到云端或达到重试次数上限。

通过这样的机制，MetaClient 确保了边缘计算环境中数据的一致性和可靠性，使得边缘设备能够在相对独立的环境中运行，同时保持与中心云的数据同步，支持更智能的资源管理和应用部署。

MetaMangger

总结：MetaMangger能解决云和边网络断开的情况下服务能够照常运行的问题
存储了一些元数据配置相关的信息

在这里插入图片描述

图中展示了KubeEdge架构中边缘端MetaManager模块在云与边缘数据同步过程中的工作流程。这个流程图分为两个主要部分：从云到边缘的更新（Update From Cloud To Edge）和从边缘到云的更新（Update From Edge To Cloud）。以下是每个流程的详解：

从云到边缘的更新 (Update From Cloud To Edge)

云端发送更新消息：云端（通过edgehub组件）发送一个更新消息到边缘节点。
MetaManager接收并检查资源是否有变化：MetaManager接收到来自云端的消息，并检查边缘端的资源（通过sqlite数据库）是否需要更新。

如果需要，MetaManager更新本地元数据：如果检测到资源有变化，MetaManager会更新存储在sqlite数据库中的元数据。

MetaManager将更新的确认消息发送回云端：更新完毕后，MetaManager向云端确认更新成功。
云端接收更新消息：云端收到边缘节点的更新确认消息。
云端处理响应：云端处理来自边缘节点的响应。

从边缘到云的更新 (Update From Edge To Cloud)

边缘端发起更新消息：边缘端的Edged组件发起一个更新消息到MetaManager。
MetaManager检查资源是否有变化：MetaManager检查资源状态是否发生变化。
MetaManager更新sqlite数据库中的元数据：如果资源状态有所变化，MetaManager将更新sqlite数据库中的相应元数据。

MetaManager将更新消息发送至云端：MetaManager将边缘端的资源状态更新发送至云端。
云端接收更新消息：云端通过edgehub组件接收到来自边缘的更新消息。
云端处理更新消息并响应：云端处理接收到的更新消息，并发送响应回边缘。

MetaManager接收来自云端的响应：MetaManager接收到来自云端的响应。
边缘端处理响应：边缘端处理来自云端的响应。

DeviceTwin

DeviceTwin和MetaMangger类似
存储的是自定义信息业务数据
在这里插入图片描述

在KubeEdge架构中，DeviceTwin是一个关键模块，负责在边缘设备和云端之间维护设备状态信息。DeviceTwin模块在边缘计算环境中实现设备管理和状态同步。以下是根据提供的图示对DeviceTwin模块的详细解析：

云到边缘的设备更新操作

云端发送设备属性更新消息：
- 云端向edgehub发送一个设备属性更新消息。
edgehub将消息发送到DeviceTwin：
- edgehub接收到云端的消息后，将其发送到DeviceTwin中的DeviceTwin Controller。
DeviceTwin Controller将消息发送到设备模块：
- DeviceTwin Controller接收到消息后，将更新指令发送到Device模块。
设备模块更新设备属性细节：
- 设备模块接收到更新指令后，更新存储在sqlite数据库中的设备属性信息。
设备模块发送设备属性更新结果：
- 设备模块将更新结果发送到Communication模块。
Communication模块将更新结果发送到EventBus进行发布：
- Communication模块将更新结果发送到EventBus，以便进一步处理或发布给其他订阅者。

关键组件

Device Module（设备模块）：
- 负责处理具体的设备操作，包括从数据库读取和写入设备属性信息。
DeviceTwin Controller（设备孪生控制器）：
- 负责接收和处理来自edgehub的消息，并将这些消息路由到适当的设备模块。
Communication Module（通信模块）：
- 负责在设备模块与EventBus之间传递信息，确保更新结果能够被订阅者接收到。
EventBus（事件总线）：
- 负责发布设备属性更新结果，确保其他模块或系统组件可以订阅和响应这些变化。
sqlite：
- 边缘设备上的本地数据库，用于存储设备的属性和状态信息，确保设备信息的持久化和高效访问。

更新从云到边缘的具体步骤

云端发送设备属性更新消息：
- 云端系统或用户通过API接口向边缘设备发送设备属性更新指令。
edgehub接收并转发消息：
- edgehub作为消息代理，接收来自云端的更新指令，并将其转发给DeviceTwin中的DeviceTwin Controller。
DeviceTwin Controller处理消息：
- DeviceTwin Controller解析更新指令，并将其路由到Device模块。
Device模块更新设备属性：
- Device模块根据指令更新设备的属性信息，并将更新后的数据写入到sqlite数据库中。
Device模块发送更新结果：
- 更新完成后，Device模块将结果发送给Communication模块，确保更新结果能够被记录和发布。
Communication模块将结果发布到EventBus：
- Communication模块将更新结果发送到EventBus进行发布，使得其他模块或系统组件可以订阅和响应这些更新。