【笔记版】edgecore.yaml分析总结

大家好，欢迎来到IT知识分享网。

1. 文件路径

2. 文件生成方式

2.1 方式一

systemctl restart edgecore 

2.2 方式二
如果使用二进制安装，需要先获取初始的最小化edgecore配置文件：(/etc/kubeedge/config路径)，或者
–defaultconfig创建完整配置文件。

edgecore --minconfig > edgecore.yaml 

启动edgecore服务

nohup ./edgecore --config edgecore.yaml 2>&1 > edgecore.log & 

nohup : no hang up（不挂起），用于在系统后台不挂断地运行命令，退出终端不会影响程序的运行。
2>&1 : 将标准错误 2 重定向到标准输出 &1 ，标准输出 &1 再被重定向输入到 edgecore.log 文件中。
0 – stdin (standard input，标准输入)
1 – stdout (standard output，标准输出)
2 – stderr (standard error，标准错误输出)
在命令的末尾加个&符号后，程序可以在后台运行。

3. 总体层次概述

4. modules 组件概述

5. edged解析

5.1 edged启动原理

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

5.2 edged配置项解析

kubeedge官网解释：https://kubeedge.io/zh/docs/architecture/edge/edged

edged: cgroupDriver: cgroupfs #cri的cgroup驱动程序配置为cgroupfs cgroupRoot: "" #默认为空，使用底层containter runtime的cgroup root，一般是 /sys/fs/cgroup/ cgroupsPerQOS: true #对应 pod 容器的 QOS 级别 clusterDNS: "" #集群dns（默认dns） clusterDomain: "" #集群域(默认域) cniBinDir: /opt/cni/bin #放可执行的原生CNI插件。 cniCacheDirs: /var/lib/cni/cache #存储运行容器的网络配置信息 cniConfDir: /etc/cni/net.d #CNI的配置文件，在不同CNI插件中表现为NetworkConfig结构体的差异。 concurrentConsumers: 5 #并发 devicePluginEnabled: false #设备插件是否启用 dockerAddress: unix:///var/run/docker.sock #Docker守护进程通信 edgedMemoryCapacity:  #边缘内存容量 enable: true enableMetrics: true #一个集群范围内的资源数据集和工具,只是显示数据，并不提供数据存储服务 gpuPluginEnabled: false #gpu插件 hostnameOverride: edgezh1-virtual-machine #覆盖名 imageGCHighThreshold: 80 #垃圾回收高阈值 imageGCLowThreshold: 40 #垃圾回收低阈值 imagePullProgressDeadline: 60 maximumDeadContainersPerPod: 1 networkPluginMTU: 1500 nodeIP: 192.168.2.101 nodeStatusUpdateFrequency: 10 podSandboxImage: kubeedge/pause:3.1 registerNode: true registerNodeNamespace: default remoteImageEndpoint: unix:///var/run/dockershim.sock remoteRuntimeEndpoint: unix:///var/run/dockershim.sock runtimeRequestTimeout: 2 runtimeType: docker 

5.2.1 cgroup

cgroup是什么?
Cgroup (Control Group)是对一组进程的资源使用（CPU、内存、磁盘 I/O 和网络等）进行限制、审计和隔离。
cgroups(Control Groups) 是 linux 内核提供的一种机制。（对多组,暂时场景不是多组，所以不深入探究）。
cgroupfs：
类似于procfs和sysfs，是一种虚拟文件系统。并且cgroupfs是可以挂载的，默认情况下挂载在/sys/fs/cgroup目录。

三个核心功能：
分组：根据需求把一系列系统任务及其子任务整合(或分隔)到按资源划分等级的不同组内。
限制：可以限制、记录任务组所使用的物理资源。
调度：内核附加在程序上的一系列钩子(hook)，通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。

cgroup如何分组？

• cgroup.clone_ children, cpuset 的 subsystem 会读取这个配置文件，如果这个值是 1 (默认是 0)，子 cgroup 才会继承父 cgroup 的 cpuset 的配置。
• cgroup.procs 是树中当前节点 cgroup 中的进程组 ID，现在的位置是在根节点，这个文件中会有现在系统中所有进程组的 ID。
• notify_on_release 和 release agent 会一起使用。 notify_on_release 标识当这个 cgroup 最后一个进程退出的时候是否执行了 release_agent; release_agent 则是一个路径，通常用作进程退出之后自动清理掉不再使用的 cgroup。
• tasks 标识该 cgroup 下面的进程 ID，如果把一个进程 ID 写到 tasks 文件中，便会将相应的进程加入到这个 cgroup 中。

cgroup如何限制？

Container级别:
路径：

• Guaranteed container：默认 /sys/fs/cgroup/{controller}/kubepods/{pod_id}/{container_id}/；
• Burstable container：默认 /sys/fs/cgroup/{controller}/kubepods/burstable/{pod_id}/{container_id}/；
• BestEffort container：默认 /sys/fs/cgroup/{controller}/kubepods/besteffort/{pod_id}/{container_id}/。

一个资源申请（容器）的例子：

apiVersion: v1 kind: Pod spec: containers: name: busybox image: busybox resources: limits: cpu: 500m memory: "400Mi" requests: cpu: 250m memory: "300Mi" command: ["md5sum"] args: ["/dev/urandom"] 

在Kubernetes中，资源请求和限制通常使用以下单位来表示：

Pod 级别：
Pod 配置在 QoS cgroup 配置的下一级，

• Guaranteed Pod：默认 /sys/fs/cgroup/{controller}/kubepods/{pod_id}/；
• Burstable Pod：默认 /sys/fs/cgroup/{controller}/kubepods/burstable/{pod_id}/；
• BestEffort Pod：默认 /sys/fs/cgroup/{controller}/kubepods/besteffort/{pod_id}/。
  kubelet 计算 pod requets/limits 的过程
  

一个Pod的容器的request和limits是通过在Pod的容器定义中设置资源请求和限制来确定的。

在Pod的容器定义中，可以为每个容器定义资源请求和限制。资源请求是指容器在运行时对某一资源（如CPU或内存）的需求量。资源限制是指容器在运行时对某一资源的最大使用量。

在计算一个Pod的所有容器的资源请求和限制时，Kubernetes将遵循以下规则：

cgroup如何调度？

调度算法根据各 node 当前可供分配的资源量（Allocatable），为容器选择合适的 node； 注意，k8s 的调度只看 requests，不看 limits。

5.2.2 cni

cniBinDir: /opt/cni/bin #放可执行的原生CNI插件。 cniCacheDirs: /var/lib/cni/cache #存储运行容器的网络配置信息 cniConfDir: /etc/cni/net.d #CNI的配置文件，在不同CNI插件中表现为NetworkConfig结构体的差异。 

在这个示意图中，我们看到有一个容器运行时 (Container Runtime) 和多个不同的网络插件 (Network Plugins)，它们可以是 Calico、Flannel、Weave 等等。CNI 提供了一个统一的接口，使得容器运行时可以与任何支持 CNI 规范的网络插件进行通信。
当一个容器启动时，容器运行时会调用 CNI 接口，并将容器的网络配置传递给网络插件。网络插件会根据配置信息来创建和管理容器的网络，同时也负责处理容器之间的通信。CNI 还定义了一些标准的网络配置参数，用于指定容器的 IP 地址、网关、子网等。

5.2.3 GC

• The image garbage collector is an edged routine which wakes up every 5 secs, and collects information about disk usage based on the policy used.
  镜像垃圾收集器是一个边缘例程，每5秒唤醒一次，并根据所使用的策略收集磁盘使用信息。
  
• The policy for garbage collecting images takes two factors into consideration, HighThresholdPercent and LowThresholdPercent .
  图像垃圾收集策略需要考虑两个因素:HighThresholdPercent和LowThresholdPercent。
  
• Disk usage above the high threshold will trigger garbage collection, which attempts to delete unused images until the low threshold is met.
  磁盘使用率高于高阈值将触发垃圾收集，垃圾收集将尝试删除未使用的映像，直到达到低阈值。
  
• Least recently used images are deleted first.
  首先删除最近最少使用的图像。
  

5.2.4 taints

- effect: NoSchedule key: node-role.kubernetes.io/edge volumeStatsAggPeriod:  

6. edgestream解析

Stream是KubeEdge中提供云边隧道的模块，目前支持ApiServer向Kubelet发起containerLog、exec和metrics请求。云边隧道基于WebSocket建造，支持双向传输和流式传输。

主要功能是启动创建websocket

1. 读取本地的证书配置
2. 连接cloud 端的 tunnel server（也就是下面提到的server端）

edgeStream: handshakeTimeout: 30 #握手超时时间（second） default 30 readDeadline: 15 #读取证书的截止时间：15s内 server: 1.94.44.163:30004 tlsTunnelCAFile: /etc/kubeedge/ca/rootCA.crt tlsTunnelCertFile: /etc/kubeedge/certs/server.crt tlsTunnelPrivateKeyFile: /etc/kubeedge/certs/server.key writeDeadline: 15 #写证书的截止时间：15s内 

7. edgeHub解析

1. 消息路由：EdgeHub允许边缘设备与云平台之间进行双向的消息传递。它可以接收来自云平台的消息，并将其路由到边缘设备上运行的模块，也可以将来自边缘设备的消息发送到云平台。这种消息路由的能力使得边缘设备能够与云平台进行实时的通信和数据交换。
2. 模块通信：在边缘设备上运行的模块之间可能需要相互通信，例如将传感器数据从一个模块传递给另一个模块进行处理。EdgeHub提供了一个统一的消息传递机制，使得模块之间可以通过发送和接收消息进行通信。这种模块之间的通信能力使得边缘设备上的各个模块可以协同工作，共同完成复杂的任务。
3. 安全性：EdgeHub提供了对消息传输的安全保护。它使用TLS来加密消息，以确保消息在传输过程中的机密性和完整性。此外，EdgeHub还支持设备身份验证和授权，只有经过身份验证的设备才能与边缘设备进行通信，从而增加了系统的安全性。

总的来说，EdgeHub在边缘端起到了消息路由、模块通信和安全性保护等重要作用，使得边缘设备能够与云平台进行可靠的通信，并提供了模块之间的协同工作能力。

edgeHub: #通信接口，WebSocket 客户端，用于云边消息同步 enable: true heartbeat: 15 #根据心跳时间向云端发送心跳 15s发一次 httpServer: https://1.94.44.163:30002 #httpclient：用于与EdgeCore与CloudCore通信所需证书的申请 projectID: e632aba927ea4ac2b575ec1603d56f10 quic: #quic client：负责与CloudCore的日常通信（资源下发、状态上传等） enable: false handshakeTimeout: 30 #握手超时时间：30s（默认30） readDeadline: 15 #读取证书的截止时间：15s内 server: 1.94.44.163:30001 writeDeadline: 15 rotateCertificates: true #证书轮转 tlsCaFile: /etc/kubeedge/ca/rootCA.crt tlsCertFile: /etc/kubeedge/certs/server.crt tlsPrivateKeyFile: /etc/kubeedge/certs/server.key token: b80a0a2a87b0910be5dadbfa56fb7eabdf0cc1668c.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MDY1NjMzNDF9.QSRQsMmL_YZQFEfLC0r0Rr6_HgNBKmBPvs50VLfHGnU websocket: #websocket：负责与CloudCore的日常通信（资源下发、状态上传等） enable: true handshakeTimeout: 30 readDeadline: 15 server: 1.94.44.163:30000 writeDeadline: 15 

8. MetaManager解析

 metaManager: #它管理边缘节点上的元数据。 contextSendGroup: hub contextSendModule: websocket #上下文发送的模块，客户端和服务端之间建立tcp连接的通信 enable: true metaServer: enable: false server: 127.0.0.1:10550 podStatusSyncInterval: 60 #定期发送MetaSync操作消息的同步间隔，同步pod状态，60s（默认）。 remoteQueryTimeout: 60 #发送请求超时时间，60s（默认） 

9. DeviceTwin解析

官网解释

在Edge设备上，Device Twin是Azure IoT Hub提供的一个关键功能。它允许开发人员在设备端和云端之间同步设备的状态和属性。

具体而言，Device Twin在Edge端的作用包括：

1. 设备状态管理：Device Twin允许设备端将其当前状态（如温度、湿度、电池电量等）报告给云端，并将其保存为设备的状态属性。这样，云端可以随时了解设备的最新状态。
2. 远程配置：设备端可以使用Device Twin获取来自云端的配置信息，并根据配置信息调整自己的行为。这样，设备可以动态地适应不同的环境和需求。
3. 双向通信：Device Twin允许设备端和云端之间进行双向通信。设备可以向云端发送命令、请求或报告设备状态，云端可以向设备端发送配置信息、命令或其他指令。
4. 设备拓扑管理：Device Twin允许设备端创建和管理设备拓扑。设备可以将自己作为父设备或子设备与其他设备进行关联，并在Device Twin中管理这些关联关系。

总的来说，Device Twin在Edge端提供了一种可靠的、双向的设备与云端之间的通信机制，使得设备可以灵活地与云端进行交互，并根据云端的配置和指令适应不同的场景和需求。在Edge设备上，Device Twin是Azure IoT Hub提供的一个关键功能。它允许开发人员在设备端和云端之间同步设备的状态和属性。

10. EventBus解析

EventBus在边缘端起到了以下作用：

1. 事件发布与订阅：EventBus允许在边缘端组件之间进行松散耦合的通信，组件可以发布事件，并且其他组件可以订阅这些事件。这种事件驱动的机制能够提高边缘端的可扩展性和灵活性。
2. 实时数据传递：边缘端的设备和传感器通常会产生大量的实时数据。EventBus可以用于在边缘端不同组件之间实时传递数据，实现实时数据的处理和分发。这种实时的数据传递能够帮助边缘端系统实时响应和处理数据。
3. 解耦和管理：EventBus可以解耦边缘端的不同组件，使它们之间的通信更加灵活和可扩展。通过订阅事件的方式，组件之间不需要直接耦合在一起，降低了代码的依赖性和复杂性。同时，EventBus还可以管理事件的发布和订阅，确保事件的交付和处理。
4. 系统集成：边缘端的系统往往由多个组件和服务组成，这些组件和服务可能来自不同的厂商或者遵循不同的通信协议。EventBus可以作为一个中间件，帮助不同的组件和服务进行集成和协同工作。通过发布和订阅事件的方式，不同的组件可以通过EventBus进行通信和协作。

总之，EventBus在边缘端起到了解耦和管理组件之间通信、实时数据传递、系统集成等作用，提高了边缘端系统的可扩展性、灵活性和实时性。

 eventBus: #使用MQTT处理内部边缘通信。 enable: true eventBusTLS: enable: false tlsMqttCAFile: /etc/kubeedge/ca/rootCA.crt tlsMqttCertFile: /etc/kubeedge/certs/server.crt tlsMqttPrivateKeyFile: /etc/kubeedge/certs/server.key mqttMode: 2 #启用内部 mqtt 代理（mqttMode=2）。 mqttQOS: 0 mqttRetain: false mqttServerExternal: tcp://127.0.0.1:1883 mqttServerInternal: tcp://127.0.0.1:1884 mqttSessionQueueSize: 100 

（mqttMode=0）：bothMqttMode：启用内部和外部代理（mqttMode=1）：externalMqttMode：仅启用外部代理

11. ServiceBus解析

在边缘端，ServiceBus起多个作用：

ServiceBus在边缘端起到了连接边缘设备和云端的桥梁作用，提供可靠的消息传递、数据集成、高可用性和离线操作等功能。这使得边缘设备可以更好地与云端进行交互，并实现更强大的功能和应用场景。

 serviceBus: enable: false port: 9060 server: 127.0.0.1 timeout: 60