在 KubeSphere 中玩转 KubeEdge 边缘计算

文章目录

- 一、边缘计算概念
- 二、边缘计算痛点
- 三、边缘计算应用场景
- 四、常见边缘计算框架
- [五、KubeEdge 架构](#五、KubeEdge 架构)
- - 4.1、kubeedge云端
  - 4.2、kubeedge边端
  - 4.3、安装部署
  - - [4.3.1、安装 Cloudcore](#4.3.1、安装 Cloudcore)
    - 4.3.2、添加边缘节点
    - [4.3.3、开启Metrics& 日志](#4.3.3、开启Metrics& 日志)
  - 4.4、运行应用
- 六、云边服务互访
- - [6.1、部署 EdgeMesh](#6.1、部署 EdgeMesh)
  - 6.2、测试边端服务访问
  - 6.3、测试云边互访
  - 6.4、边缘设备数据访问
- 七、镜像预热

一、边缘计算概念

边缘计算服务是在靠近数据收集的地方提供服务，位置从云端转移到了边缘节点（edge node）或边缘服务器（edge server）上。可以说边缘计算是云计算的延伸，是云计算把一些业务下沉到了边缘层。

边缘计算的基础架构图如下：

边缘计算发生在边缘层，位于云层和设备层中间，显而易见的好处就是离用户更近了，所以时延更小，提高了实时响应能力，降低了网络不稳定或带宽不足带来的影响，提高了业务持续性和可用性，也增强了数据安全性。

二、边缘计算痛点

云计算能力由中心逐步下沉到边缘，节点数量增多，覆盖范围缩小，运维服务成本快速增加。根据国内网络（国内有多张骨干网，分别是电信 CHINANET 与 CN2，联通 CNCNET 以及移动 CMNET）现状，骨干网节点，城际网节点，汇聚网节点，接入网节点，以及数以万计的业务现场计算节点都可以安置边缘计算，因此范围太广难以形成统一标准。因此我们说中心云计算由技术定义，边缘计算由网络与业务需求定义。

边缘计算范围大，场景泛，目前整个行业缺少经典的案例及标准。因此推动边缘计算落地，一定是面向真实的业务场景及需求整体规划，面向价值逐步建设。

三、边缘计算应用场景

边缘计算主要应用在哪些领域呢？

常见的领域包括：

交通（交通量、违规、事故等监测）
智能家居（传感器）
物流（货物追踪、分拣等）
智慧农业（环境监测，调整灌溉量和施肥量等）
安防（人脸识别，物体检测，监控视频数据等）
零售（货物种类/数量识别，数据分析，智能营销等）
除此之外，边缘计算也可应用于自动驾驶、远程手术、工业自动化等领域。

四、常见边缘计算框架

常见边缘计算框架有三种，如 KubeEdge、OpenYurt 和 SuperEdge。

云原生全景图-CNCF Landscape ：https://landscape.cncf.io/

五、KubeEdge 架构

KubeEdge 分为云端和边端。

云端核心组件 CloudCore 和边端核心组件 EdgeCore 联合实现边缘计算框架的众多功能，如云边通信、设备管理、离线自治等。还有一些辅助组件如 EdgeMesh 实现边端通信和服务治理，Sedna 提供边端 AI 框架等。

而到具体的 CloudCore 和 EdgeCore 的组成，可从下图详细学习架构设计：

4.1、kubeedge云端

CloudCore 由 CloudHub 和 EdgeController、DeviceController 组成。

CloudHub：主要观察云边变化，读写 Edge 消息，缓存数据后通过WebSocket/QUIC（K8s 的 listwatch 机制太耗资源）发送给 EdgeHub，还要把和 Edge 通信得到的一些消息发送给 Controller。
EdgeController：作为 ApiServer 和 EdgeCore 的桥梁，管理常用的配置、Pod、缓存等事件，把 EdgeCore 订阅到的 Pod 的众多事件信息同步状态到 ApiServer。也把 ApiServer 的 ADD/UPDATE/DELETE 等事件同步到 EdgeCore。
DeviceController ：通过 EdgeCore DeviceTwin 同步设备更新，总体过程是 Mapper--->MQTT--->EventBus--->DeviceTwin->EdgeHub->CloudHub--->Deviceontroller->APIServer。
另一方面就是云端创建的 Device，下发到边端得到元数据进行设备端更新。

4.2、kubeedge边端

EdgeHub：云边通信边端，同步资源更新。
EventBus：发送 / 接收 MQTT 消息。
MetaManager：在 SQLlite 存储数据，是 Edged 和 EdgeHub 的消息处理器。
Edged：边端裁剪版 kubelet。管理 Pod、configmap、volume 等资源的生命周期。还包含一个 StatusManager 和 MetaClient 组件。前者每 10s 将本地数据库存储的状态信息上传至云，后者作为 client 和本地迷你 Etcd（MetaManager）交互，如读取云端下发的 ConfigMap、Secret，写 Node、Pod Status。
DeviceTwin：存储设备属性和状态，创建 Edge 设备和节点关系，同步设备属性到云。
ServiceBus: 接收云上服务请求和边缘应用进行 http 交互。

4.3、安装部署

4.3.1、安装 Cloudcore

KubeSphere 已经集成了 KubeEdge，可提供边缘节点纳管、应用下发、日志监控等功能。接下来将在 KubeSphere 上演示边缘计算 Demo。

KubeSphere 上启用 KubeEdge，编辑 clusterconfiguration，设置 edgeruntime enabled 为 true，kubeedge enabled 为 true，设置 advertiseAddress IP 为LoadBalancerIP，本篇简化实验，直接使用"master_ip"

kubectl 中执行以下命令检查安装过程：

bash 复制代码

kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f

设置完成后，在集群管理-> 节点中会出现"边缘节点"：

此时查看 kubeedge 命名空间下的工作负载和配置，可以熟悉下部署架构。CloudCore 作为一个 Deployment 运行，IptablesManager 会帮助处理云边通道的 Iptables 规则下发。

查看 CloudCore 挂载的 ConfigMap 和 Secret，ConfigMap 主要挂载 cloudcore.yaml 配置文件到 /etc/kubeedge/config, 可灵活修改 CloudCore Modules 配置。Secret 挂载 CloudCore 和 EdgeCore 需要用到的一些 TLS 证书。

4.3.2、添加边缘节点

进入 KubeSphere Console，导航到节点-> 边缘节点，添加边缘节点：

填写边缘节点的名字和边缘节点的 IP，生成边缘节点配置命令，粘贴到边缘节点执行：

由于我们使用的 cloudcore 的服务是通过 NodePort 暴露出来的，所以在边缘节点注册 Cloudcore 时，需要使用 NodeIP:NodePort 形式，此处将 10000-10004 替换为 30000-30004 端口。

bash 复制代码

install MQTT service successfully.
kubeedge-v1.9.2-linux-amd64.tar.gz checksum:
checksum_kubeedge-v1.9.2-linux-amd64.tar.gz.txt content:
[Run as service] start to download service file for edgecore
[Run as service] success to download service file for edgecore
kubeedge-v1.9.2-linux-amd64/
kubeedge-v1.9.2-linux-amd64/edge/
kubeedge-v1.9.2-linux-amd64/edge/edgecore
kubeedge-v1.9.2-linux-amd64/version
kubeedge-v1.9.2-linux-amd64/cloud/
kubeedge-v1.9.2-linux-amd64/cloud/csidriver/
kubeedge-v1.9.2-linux-amd64/cloud/csidriver/csidriver
kubeedge-v1.9.2-linux-amd64/cloud/admission/
kubeedge-v1.9.2-linux-amd64/cloud/admission/admission
kubeedge-v1.9.2-linux-amd64/cloud/cloudcore/
kubeedge-v1.9.2-linux-amd64/cloud/cloudcore/cloudcore
kubeedge-v1.9.2-linux-amd64/cloud/iptablesmanager/
kubeedge-v1.9.2-linux-amd64/cloud/iptablesmanager/iptablesmanager

KubeEdge edgecore is running, For logs visit: journalctl -u edgecore.service -b

查看 KubeSphere 控制台的边缘节点，已经可以看到边缘节点注册上来：

使用 kubectl 查看节点情况：

4.3.3、开启Metrics& 日志

此时我们发现节点的 CPU 内存信息无法统计，需要开启 KubeSphere Metrics_Server 并在 Edge 端开启 EdgeStream：

编辑 cc，开启 metrics-server:

编辑边缘节点 /etc/kubeedge/config/edgecore.yaml 文件，搜索 edgeStream，将 false 更改为 true：

bash 复制代码

  edgeStream:
    enable: true
    handshakeTimeout: 30
    readDeadline: 15
    server: 192.168.100.7:30004
    tlsTunnelCAFile: /etc/kubeedge/ca/rootCA.crt
    tlsTunnelCertFile: /etc/kubeedge/certs/server.crt
    tlsTunnelPrivateKeyFile: /etc/kubeedge/certs/server.key
    writeDeadline: 15

此处 server 字段设置端口为 30004，因为我们使用 NodePort 端口和云端通信

重启 edgecore.service

bash 复制代码

systemctl restart edgecore.service

查看节点监控信息：

我们上面章节中已经在 edgecore 开启 edgestream，实现了云端收集 Edge 节点的 Metrics 功能，这个操作同时也实现了边端日志查看的能力。

一般来说，当我们 kubectl logs pod -n namespace 后，kubectl 会请求 kube-apiserver 查询 pod 是否存在以及 pod 里是否含有多个容器，再检索 Pod 所在的 Node 的 Kubelet Server 信息。这个信息一般可以通过 kubectl describe 或 get node 查到：

bash 复制代码

kubectl get  node ks2 -oyaml

yaml 复制代码

 addresses:
  - address: 192.168.100.7
    type: InternalIP
  - address: ks2
    type: Hostname
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10250

bash 复制代码

kubectl get node edge-node-1 -oayml

yaml 复制代码

  addresses:
  - address: 192.168.100.6
    type: InternalIP
  - address: edge-node-1
    type: Hostname
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10352

InternalIP+kubeletEndpoint 组成 kubelet server 的地址，kubectl logs 就可以请求这个地址得到相关日志信息。但对于边缘端来说，大多数情况这个 internalIP 云端是无法访问的。

此时就需要 CloudCore 的 CloudStream 和 EdgeCore 的 EdgeStream 建立一个云边通道，在 CloudCore 和 EdgeCore 建立云边 WebSocket 通信后，将请求的 Edge kubelet server 的日志信息能通过通道返回给云端。这个通道需要两边开启 CloudStream 和 EdgeStream，并通过 TLS 证书进行验证。

边缘端在上面已经开启 EdgeStream，云端部署 CloudCore 后会自动开启。

查看云端挂载的 CloudCore.yaml 配置文件：

当然，云边通道只能将日志从消息返回，具体返回到 CloudCore 的 CloudStream，还需设置一个 NAT 规则

bash 复制代码

iptables -t nat -A OUTPUT -p tcp --dport 10350（edge kubelet 端口）-j NAT --to $ClOUDCOREIPS:10003

这个操作已经让自动部署的 iptables-manager 完成了~

bash 复制代码

iptables -t nat -L

bash 复制代码

Chain TUNNEL-PORT (2 references)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             tcp dpt:10351 to:10.20.253.88:10003
DNAT       tcp  --  anywhere             anywhere             tcp dpt:10352 to:10.20.253.127:10003

进入边缘节点，查看容器组，我们可以看到有几个 daemonset 有强容忍度，调度到了边缘节点，由于边缘端很多情况存在不稳定通信，不适合运行 Calico 这种 CNI 组件，更多使用 EdgeMesh 进行云边通信和服务发现，我们可以手动 Patch Pod 以防止非边缘节点调度至工作节点：

bash 复制代码

#!/bin/bash
NoShedulePatchJson='{"spec":{"template":{"spec":{"affinity":{"nodeAffinity":{"requiredDuringSchedulingIgnoredDuringExecution":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"node-role.kubernetes.io/edge","operator":"DoesNotExist"}]}]}}}}}}}'
ns="kube-system"
DaemonSets=("nodelocaldns" "kube-proxy" "calico-node")
length=${#DaemonSets[@]}
for((i=0;i<length;i++));  
do
         ds=${DaemonSets[$i]}
        echo "Patching resources:DaemonSet/${ds}" in ns:"$ns",
        kubectl -n $ns patch DaemonSet/${ds} --type merge --patch "$NoShedulePatchJson"
        sleep 1
done

进入节点终端（KS3.3 以上可用），运行脚本：

bash 复制代码

sh-4.2# ./bash.sh
Patching resources:DaemonSet/nodelocaldns in ns:kube-system,
daemonset.apps/nodelocaldns patched
Patching resources:DaemonSet/kube-proxy in ns:kube-system,
daemonset.apps/kube-proxy patched
Patching resources:DaemonSet/calico-node in ns:kube-system,
daemonset.apps/calico-node patched

查看边缘节点容器组：

4.4、运行应用

进入项目-应用负载，创建一个 Deployment 工作负载：

设置端口：

选择节点分配：

创建后会显示节点存在污点无法调度，需要加上 toleration：

编辑 nginx-edge 应用的 yaml，添加对 edge 的 toleration：

添加污点容忍后，Pod 运行成功：

设置一个 NodePort Service，访问 Nginx 服务。

此时可以发现访问是不通的，因为云端无法访问边缘端的 Pod 网络，查看边缘 nginx-edge 的 ip：

bash 复制代码

kubectl get pod -n demo -o wide

bash 复制代码

NAME                          READY   STATUS    RESTARTS      AGE     IP              NODE          NOMINATED NODE   READINESS GATES
nginx-9c99b5774-vvsfq         1/1     Running   4 (12h ago)   4d11h   10.20.253.123   ks2           <none>           <none>
nginx-edge-68c66d6bf9-k9l6n   1/1     Running   0             7m55s   172.17.0.2      edge-node-1   <none>           <none>

ssh 到边缘节点，访问 172.17.0.2：

bash 复制代码

curl 172.17.0.2

bash 复制代码

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

可见 Nginx Pod 服务是正常的，这个 IP 地址分配也很熟悉，172.17.0.0/16，这不是 docker bridge 网段嘛，查看下边缘节点 docker0 地址：

bash 复制代码

ip ad

我们可以看到 nginx-edge 这个容器还是以 Pod 形式运行的，通过 pause 容器共享网络命名空间，只不过它没有使用集群的 PodCIDR 分配，而是使用 docker bridge 网络。因此在没有 coredns 和 kube-proxy 的服务发现和云边容器网络互通的条件下，边端的 Pod Service 是无法访问的。这很符合边云特点，边缘端更多是私网，且无法被云端访问，这种单向通信的特点需要有其他形式的网络促成云边的通信和服务访问，比如建立隧道。

六、云边服务互访

KubeEdge 社区有个 EdgeMesh的项目。在边缘计算机的场景下，网络拓扑结构更加复杂。不同区域的边缘节点往往不能互联，而应用之间又需要业务流量互通。

EdgeMesh 即可满足边缘节点之间流量互通的要求。按照官方 Github 介绍，EdgeMesh 作为 KubeEdge 集群的数据平面组件，为应用程序提供简单的服务发现和流量代理功能，从而屏蔽了边缘场景中的复杂网络结构。

因此 EdgeMesh 主要实现两个终极目标：

用户可以在不同的网络中访问边到边、边到云、云到边的应用
部署 EdgeMesh 相当于部署了 CoreDNS+Kube-Proxy+CNI

6.1、部署 EdgeMesh

部署有些前置条件：

开启 Edge Kube-API Endpoint
开启 cloudcore dynamicController

bash 复制代码

vim /etc/kubeedge/config/cloudcore.yaml

yaml 复制代码

modules:
  ...
  dynamicController:
    enable: true

开启 Edge metaServer：

bash 复制代码

vim /etc/kubeedge/config/edgecore.yaml

yaml 复制代码

modules:
  ...
  edgeMesh:
    enable: false
  ...
  metaManager:
    metaServer:
      enable: true

添加 edgemesh commonconfig 信息：

bash 复制代码

vim /etc/kubeedge/config/edgecore.yaml

yaml 复制代码

modules:
  ...
  edged:
    clusterDNS: 169.254.96.16
    clusterDomain: cluster.local
...

重启 cloudcore 和 edgecore 后，可在 edge 端验证是否能请求 kube-API：

bash 复制代码

curl 127.0.0.1:10550/api/v1/services

yaml 复制代码

{"apiVersion":"v1","items":[{"apiVersion":"v1","kind":"Service","metadata":{"creationTimestamp":"2023-01-04T13:09:51Z","labe                           ls":{"component":"apiserver","provider":"kubernetes","service.edgemesh.kubeedge.io/service-proxy-name":""}······

EdgeMesh Helm Chart 已收入 KubeSphere 应用商店，我们打开应用商店直接部署即可。

进入 kubeedge 项目，将 EdgeMesh 部署到此项目中。

此时需要修改应用设置的 server.nodeName 和 server.advertiseAddress：

执行安装，安装成功后查看 edgemesh-server 和 edgemesh-agent 运行情况：

6.2、测试边端服务访问

使用示例应用 https://github.com/kubeedge/edgemesh/examples，部署一个 hostname 应用及服务：

测试从云端的 Pod 访问边缘 Service：

6.3、测试云边互访

部署 https://github.com/kubeedge/edgemesh/examples 的 cloudzone 和 edgezone 应用：

云端 busybox 访问边端应用：

bash 复制代码

 docker exec -it 5a94e3e34adb sh
/ # cat /etc/resolv.conf
nameserver 169.254.96.16
search edgezone.svc.ks2 svc.ks2 ks2 sh1.qingcloud.com
options ndots:5

/ # telnet tcp-echo-cloud-svc.cloudzone 2701
Welcome, you are connected to node ks2.
Running on Pod tcp-echo-cloud-6d687d88c4-tllst.
In namespace cloudzone.
With IP address 10.20.253.177.
Service default.

6.4、边缘设备数据访问

部署一个模拟温度数据获取的 App：

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: temperature-mapper
  labels:
    app: temperature
spec:
  replicas: 1
  selector:
    matchLabels:
      app: temperature
  template:
    metadata:
      labels:
        app: temperature
    spec:
      hostNetwork: true
      tolerations:
      - key: "node-role.kubernetes.io/edge"
        operator: "Exists"
        effect: "NoSchedule"
      nodeSelector:
        kubernetes.io/hostname: "edge-node-1"
      containers:
      - name: temperature
        image: lammw12/temperature-mapper:edge
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true

创建 DeviceModel：

yaml 复制代码

apiVersion: devices.kubeedge.io/v1alpha2
kind: Device
metadata:
  name: temperature
  labels:
    description: 'temperature'
    manufacturer: 'test'
spec:
  deviceModelRef:
    name: temperature-model
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: ''
            operator: In
            values:
              - edge-centos
status:
  twins:
    - propertyName: temperature-status
      desired:
        metadata:
          type: string
        value: ''

创建 Device：

yaml 复制代码

apiVersion: devices.kubeedge.io/v1alpha2
kind: Device
metadata:
  name: temperature
  labels:
    description: 'temperature'
    manufacturer: 'test'
spec:
  deviceModelRef:
    name: temperature-model
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: ''
            operator: In
            values:
              - edge-node-1
status:
  twins:
    - propertyName: temperature-status
      desired:
        metadata:
          type: string
        value: ''

KubeEdge 通过 Kubernetes 的 CRD，增加了 DeviceModel 和 Device 两个资源，分别来描述设备元信息和设备实例信息，DeviceController 负责边缘设备管理，在云和边之间传递这些信息。用户可以通过 Kubernetes API 从云中创建、更新和删除设备元数据，也可以通过 CRD API 控制设备属性的预期 (desired) 状态，从云端对设备进行 CRUD 操作。

DeviceModel 描述了设备属性，例如 "温度" 或 "压力", 类似一个可重复使用的模板，使用它可以创建和管理许多设备。

一个 Device 实例代表一个实际的设备对象。它就像 device model 的实例化，引用了 model 中定义的属性。

kubectl apply 上述资源。

查看运行的 temperature 应用：

查看 temperature 应用日志：

使用 kubectl 查看 device 状态：

bash 复制代码

kubectl get device temperature -oyaml

yaml 复制代码

···
status:
  twins:
  - desired:
      metadata:
        type: string
      value: ""
    propertyName: temperature-status
    reported:
      metadata:
        timestamp: "1673256318955"
        type: string
      value: 70C

yaml 中的 device status 包含两份数据，一个是云端希望设置的状态数据（'desired'），一个是边缘端上报的状态数据（'reported'）。云端的DeviceController 通过 Kubernetes API 监听 device 设备的创建事件，会自动创建一个新的 configmap，存储该 device 的 status 等属性信息，并保存到 ectd 中。EdgeController 将 configmap 同步到边缘节点，因而边缘节点的应用也能够获取设备的属性信息。'desired'值将初始化到边缘节点数据库以及边缘设备中，因而即使边缘节点重启，也能自动恢复到之前的状态。当然这个'desired'值也会随着云端用户对设备的

CRUD 而更改。

七、镜像预热

在实际应用中，边缘节点和设备是大规模且网络环境不够稳定的，云端下发边缘应用到多个节点后，可能镜像拉取花费的时间很受管理员困扰。这与容器化快速大规模交付应用和业务上线/ 扩容 / 升级的期望背道而驰。
因此镜像预热的能力是大规模边缘节点场景中不可或缺的，我们可以借助镜像预热工具实现边缘节点上的镜像提前拉取，加快应用部署的速度。开源社区有一个OpenKruise 的项目，可以实现此需求。

OpenKruise 为每个 Node 驻扎一个 Daemonset，通过与 CRI 交互来绕过 kubelet 实现拉取镜像的能力。比如，定义一个 NodeImage CR，定义每个节点需要预热什么镜像，然后 kruise-daemon 就可以按照 NodeImage 来执行镜像的拉取任务：

对于大规模边缘节点场景，可以通过 ImagePullJob 筛选节点后进行批量预热，一个 ImagePullJob 创建后，会被 kruise-manager 中的 imagepulljob-controller 接收到并处理，将其分解并写入到所有匹配节点的NodeImage 中，以此来完成规模化的预热。

yaml 复制代码

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: job-with-always
spec:
  image: nginx:1.9.1   # [required] 完整的镜像名 name:tag
  parallelism: 10      # [optional] 最大并发拉取的节点梳理, 默认为 1
  selector:            # [optional] 指定节点的 名字列表 或 标签选择器 (只能设置其中一种)
    names:
    - node-1
    - node-2
    matchLabels:
      node-type: xxx
# podSelector:         # [optional] 通过 podSelector 匹配Pod，在这些 Pod 所在节点上拉取镜像, 与 selector 不能同时设置.
#   matchLabels:
#     pod-label: xxx
#   matchExpressions:
#   - key: pod-label
#      operator: In
#        values:
#        - xxx
  completionPolicy:
    type: Always                  # [optional] 默认为 Always
    activeDeadlineSeconds: 1200   # [optional] 无默认值, 只对 Alway 类型生效
    ttlSecondsAfterFinished: 300  # [optional] 无默认值, 只对 Alway 类型生效
  pullPolicy:                     # [optional] 默认 backoffLimit=3, timeoutSeconds=600
    backoffLimit: 3
    timeoutSeconds: 300

每一次的跌倒，都是对未来的一次深情拥抱。