Kubeedge Edged概述

Kubeedge Edged概述

Overview

EdgeD是管理节点生命周期的边缘节点模块。它可以帮助用户在边缘节点上部署容器化的工作负载或应用程序。这些工作负载可以执行任何操作，从简单的远程遥测数据操作到分析或ML推理等等。使用kubectl云端的命令行界面，用户可以发出命令来启动工作负载。

通过容器运行时接口Container Runtime Interface（CRI）支持几种符合OCI的运行时runtimes。请参阅KubeEdge运行时配置，以获取有关如何配置边缘以利用其他运行时的更多信息。

有许多模块协同工作以实现edged的功能。

EdgeD Overall

Fig 1: EdgeD Functionalities

Pod Management

它是pod添加，删除和修改的句柄。它还使用pod status manager和pleg跟踪pod的运行状况。其主要工作如下：

· 接收并处理来自metamanager的pod添加/删除/修改消息。

· 处理单独的工作队列以添加和删除容器。

· 处理工作程序例程以检查工作程序队列以执行pod操作。

· 分别为配置映射和秘密保留单独的缓存。

· 定期清理孤立的吊舱orphaned pods

Pod Addition Flow

Fig 2: Pod Addition Flow

Pod Deletion Flow

Fig 3: Pod Deletion Flow

Pod Updation Flow

Fig 4: Pod Updation Flow

Pod Lifecycle Event Generator生命周期事件生成器

该模块有助于监视吊舱pod的边缘状态。每隔一秒钟，通过使用活动性和就绪状态的探测，会使用窗格状态管理器为每个窗格更新信息。

PLEG Design

Fig 5: PLEG at EdgeD

CRI for edged

Container Runtime Interface (CRI) – a plugin interface which enables edged to use a wide variety of container runtimes like Docker, containerd, CRI-O, etc., without the need to recompile. For more on how to configure KubeEdge for container runtimes, see KubeEdge runtime configuration.

容器运行时接口Container Runtime Interface（CRI）–一个插件接口，使边缘用户无需重新编译即可使用各种容器运行时runtimes，例如Docker，contained，CRI-O等。有关如何为容器运行时配置KubeEdge的更多信息，请参见KubeEdge运行时配置。

Why CRI for edged?

为了在以下情况中需要CRI支持边缘化的多个容器运行时runtimes：

· 在无法运行现有Docker运行时的资源受限边缘节点上支持轻量级容器运行时runtime。

· 在边缘节点上支持多个容器运行时runtime，例如Docker，contained，CRI-O等。

稍后将考虑对具有暂停容器和IP的相应CNI的支持。

CRI Design

Fig 6: CRI at EdgeD

Secret Management

在边缘，秘密是分开处理的。对于添加，删除和修改之类的操作，有单独的配置消息和接口集。使用这些接口，机密会在缓存存储中更新。下面的流程图说明了消息流。

Secret Message Handling

Fig 7: Secret Message Handling at EdgeD

Edged使用MetaClient模块从MetaManager获取机密。如果边缘查询尚未存储在MetaManager中的新机密，则该请求将转发到云。在发送包含机密的响应之前，MetaManager将其存储在本地数据库中。随后将从数据库检索对同一密钥的查询，从而减少了等待时间。下面的流程图显示了如何从MetaManager和云中获取机密。它还描述了机密如何存储在MetaManager中。

Query Secret

Fig 8: Query Secret by EdgeD

Probe Management

探针管理分别创建两个探针，以准备就绪和活动，以便吊舱监视容器。就绪探针可通过监视容器何时达到运行状态来提供帮助。活动性探针可通过监视吊舱的健康状况（指示吊舱处于打开还是关闭状态）来提供帮助。如前所述，PLEG模块使用其服务。

ConfigMap Management

在有边缘的情况下，ConfigMap也被单独处理。对于添加，删除和修改之类的操作，有单独的配置消息和接口集。使用这些接口，可以在缓存存储中更新ConfigMap。下面的流程图说明了消息流。

ConfigMap Message Handling

Fig 9: ConfigMap Message Handling at EdgeD

Edged使用MetaClient模块从MetaManager获取ConfigMap。如果边缘查询尚未存储在MetaManager中的新ConfigMap，则该请求将转发到云。在发送包含ConfigMap的响应之前，MetaManager将其存储在本地数据库中。随后将从数据库检索对同一ConfigMap密钥的查询，从而减少了延迟。下面的流程图显示了如何从MetaManager和Cloud获取ConfigMap。它还描述了ConfigMap如何存储在MetaManager中。

Query Configmaps

Fig 10: Query Configmaps by EdgeD

Container GC

The container garbage collector is an edged routine which wakes up every minute, collecting and removing dead containers using the specified container gc policy. The policy for garbage collecting containers is determined by three variables, which can be user-defined:

容器垃圾收集器是一个边缘例程，它每分钟唤醒一次，使用指定的容器gc策略收集和删除死容器。垃圾收集容器的策略由三个变量确定，可以由用户定义：

· MinAge 是可以收集垃圾的最小年龄，零是无限制的。

· MaxPerPodContainer 是允许任何单个吊舱（UID，容器名称）对具有的失效容器的最大数量，不超过零且没有限制。

· MaxContainers是死容器总数的最大数量，无限制地小于零。通常，最旧的容器会先被移除。

Image GC

图像垃圾收集器是一个边缘程序，每5秒唤醒一次，并根据使用的策略收集有关磁盘使用情况的信息。垃圾收集图像的策略考虑了两个因素：HighThresholdPercent和LowThresholdPercent。磁盘使用率高于高阈值将触发垃圾回收，垃圾收集将尝试删除未使用的映像，直到达到低阈值为止。首先删除最近最少使用的图像。

Status Manager

状态管理器是一个独立的边缘例程，它每10秒收集一次pod状态，并使用metaclient接口将该信息转发到云。

Status Manager Flow

Fig 11: Status Manager Flow

Volume Management

卷管理器作为边缘例程运行，该边缘例程基于在边缘节点上安排的容器，带出要附加/安装/卸载/分离哪些卷的信息。

在启动Pod之前，将附加并安装Pod规格中引用的所有指定卷，直到阻塞该流及其其它操作。

MetaClient

Metaclient是Metamanger for Edge的接口。它有助于从Metamanager或云中获取ConfigMap和秘密详细信息。它还向metamanger发送同步消息，节点状态和pod状态到云。