在 Kubernetes 中摆设并使用 KubeEdge
作者：马伟，青云科技容器顾问，云原生爱好者，目前专注于云原生技术，云原生范畴技术栈涉及 Kubernetes、KubeSphere、KubeKey 等。边沿盘算在广泛制造业、工业、零售和金融等行业，随着云原生应用的鼓起，不可变底子办法和快速的应用交付等特性很适用于边沿盘算场景。因此在 Kubernetes 上使用边沿盘算框架是近年很火热的一个方向。本篇会介绍下边沿盘算的场景和架构，并以一个 Demo 示例展示怎样运行一个边沿应用到边沿节点上。
边沿盘算痛点和场景
首先，边沿盘算是云盘算的延伸，云盘算按需和资源池化的特性可以满意资源利用率的提拔和盘算资源的会集供给，但边沿测的应用场景决定不大概什么应用都丢到数据中心里。比如
[*]低延迟处理。车联网场景如果要进行数据共享和指令下发需要极低延迟的通讯保障和盘算处理速度。
[*]当地处理数据。有些数据较敏感不能什么都传到云端（如用户照片、密码）
[*]离线自治。很多边端设备不肯定有可靠的连接保持和云端的通讯。如农业、地理科学的传感器。
因此对于边沿节点和边沿设备来说，需要统一管理和当地盘算的本事，来实现云端负责总体决议，边端负责当地实验的结果。这样处理的好处就是数据处理效率高、淘汰云边带宽、低沉运营成本，却又不缺少云端的资产管理、调治监控、安全管控。
https://img-blog.csdnimg.cn/ba86ebc9461641d19f3898fe55945385.png
了解边沿盘算含义后，就有提问了，既然边沿盘算和云盘算都是一种概念，势必市场上有众多边沿盘算的产品和标准，为什么要在 Kubernetes 上使用边沿盘算呢？
这个我个人理解是双向奔赴的，kubernetes 自己比较恰当底子架构标准化和应用交付，可以资助云端统一管理边沿节点和边沿设备，也恰当于标准应用的云端下发，生态丰富且开源开放的可观测体系也恰当于不同的企业用管数据中心的方法实现边端可观测性。而 Kubernetes 也需要边沿盘算将自己的本事得到更多的延伸，去实现更多的平台本事和平台标准，究竟云-网-边-端是今世云盘算需要涵盖的每个方向~
常见边沿盘算框架
对于产品选型来说，云原生范畴最方便的就是打开 landscape 了。我们来看看 Automation&Configuration 这栏：
https://img-blog.csdnimg.cn/e0d433eb290144598f65e8f06026577d.png
我们常见的有三种，如 KubeEdge、OpenYurt 和 SuperEdge。本篇先拿 KubeEdge 这个孵化项目分享下。
KubeEdge 架构
https://img-blog.csdnimg.cn/54efd1a92a3246e080f93e09c4beb3e3.png
KubeEdge 分为云端和边端。云端核心组件 CloudCore 和边端核心组件 EdgeCore 团结实现边沿盘算框架的众多功能，如云边通讯、设备管理、离线自治等。另有一些辅助组件如 EdgeMesh 实现边端通讯和服务治理，Sedna 提供边端 AI 框架等。
而到具体的 CloudCore 和 EdgeCore 的组成，可从下图详细学习架构设计：
https://img-blog.csdnimg.cn/4219155165db4d1fb7068ef99a552046.png
云端
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，下发到边端得到元数据进行设备端更新。
边端
[*]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 交互
安装摆设
安装 Cloudcore
KubeSphere 已经集成了 KubeEdge，可提供边沿节点纳管、应用下发、日志监控等功能。接下来将在 KubeSphere 上演示边沿盘算 Demo。
KubeSphere 上启用 KubeEdge，编辑 clusterconfiguration，设置 edgeruntime enabled 为 true，kubeedge enabled 为 true，设置 advertiseAddress IP 为“master_ip”
https://img-blog.csdnimg.cn/a2255f65381d4a208a19f01d48ba2aa3.png
设置完成后，在集群管理-> 节点中会出现“边沿节点”：
https://img-blog.csdnimg.cn/050de03ddbcc4ec5a25e72c33960bdd4.png
此时查看 kubeedge 定名空间下的工作负载和设置，可以熟悉下摆设架构。
https://img-blog.csdnimg.cn/446bd6fe07b44b9b96ad518539c23d1c.png
CloudCore 作为一个 Deployment 运行，IptablesManager 会资助处理云边通道的 Iptables 规则下发。
https://img-blog.csdnimg.cn/23e496722b7a4ce299f14da2b190c2ee.png
查看 CloudCore 挂载的 ConfigMap 和 Secret，ConfigMap 重要挂载 cloudcore.yaml 设置文件到 /etc/kubeedge/config, 可机动修改 CloudCore Modules 设置。Secret 挂载 CloudCore 和 EdgeCore 需要用到的一些 TLS 证书。
添加边沿节点
进入 KubeSphere Console，导航到节点-> 边沿节点，添加边沿节点：
https://img-blog.csdnimg.cn/8506326eaf634430a16087bbfb18107e.png
https://img-blog.csdnimg.cn/7f86c26106704c72aa2a8e9fb5bedaed.png
填写边沿节点的名字和边沿节点的 IP，天生边沿节点设置命令，粘贴到边沿节点实验：
https://img-blog.csdnimg.cn/380d3ccd429a415cacd4de39067c4e0f.png
由于我们使用的 cloudcore 的服务是通过 NodePort 暴袒露来的，所以在边沿节点注册 Cloudcore 时，需要使用 NodeIP:NodePort 情势，此处将 10000-10004 更换为 30000-30004 端口。
install MQTT service successfully.
kubeedge-v1.9.2-linux-amd64.tar.gz checksum:
checksum_kubeedge-v1.9.2-linux-amd64.tar.gz.txt content:
start to download service file for edgecore
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 控制台的边沿节点，已经可以看到边沿节点注册上来：
https://img-blog.csdnimg.cn/43ac88e86dc8433381dfaf8cdb62ae90.png
使用 kubectl 查看节点情况：
https://img-blog.csdnimg.cn/cfeb3bb4976c4bc6ae650b3664d02066.png
https://img-blog.csdnimg.cn/a84aee113acb444f8b526c73f7500abe.png
Metrics& 日志
此时我们发现节点的 CPU 内存信息无法统计，需要开启 KubeSphere Metrics_Server 并在 Edge 端开启 EdgeStream：
编辑 cc，开启 metrics-server:
https://pek3b.qingstor.com/kubesphere-community/images/202301111715713.png
编辑边沿节点 /etc/kubeedge/config/edgecore.yaml 文件，搜索 edgeStream，将 false 更改为 true：
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：
$ systemctl restart edgecore.service 查看节点监控信息：
https://img-blog.csdnimg.cn/fee78803485d4ee6ab65338910ee7ce1.png
我们上面章节中已经在 edgecore 开启 edgestream，实现了云端收集 Edge 节点的 Metrics 功能，这个利用同时也实现了边端日志查看的本事。
https://img-blog.csdnimg.cn/47a420230e4b4ecb8cb97b34dd56d58c.png
一般来说，当我们 kubectl logs pod -n namespace 后，kubectl 会哀求 kube-apiserver 查询 pod 是否存在以及 pod 里是否含有多个容器，再检索 Pod 地点的 Node 的 Kubelet Server 信息。这个信息一般可以通过 kubectl describe 或 get node 查到：
$ kubectl get node ks2 -oyaml
addresses:
- address: 192.168.100.7
type: InternalIP
- address: ks2
type: Hostname
daemonEndpoints:
kubeletEndpoint:
Port: 10250
kubectl get node edge-node-1 -oayml
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 设置文件：
https://img-blog.csdnimg.cn/85b4d3519f57403b88faceef96964660.png
固然，云边通道只能将日志从消息返回，具体返回到 CloudCore 的 CloudStream，还需设置一个 NAT 规则：
$ iptables -t nat -A OUTPUT -p tcp --dport 10350（edge kubelet 端口）-j NAT --to $ClOUDCOREIPS:10003 这个利用已经让自动摆设的 iptables-manager 完成了~
$ iptables -t nat -L
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 https://img-blog.csdnimg.cn/3bd1c4bbd9114949824b717004fdbde3.png
进入边沿节点，查看容器组，我们可以看到有几个 daemonset 有强容忍度，调治到了边沿节点，由于边沿端很多情况存在不稳固通讯，不恰当运行 Calico 这种 CNI 组件，更多使用 EdgeMesh 进行云边通讯和服务发现，我们可以手动 Patch Pod 以防止非边沿节点调治至工作节点：
#!/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 以上可用），运行脚本
https://img-blog.csdnimg.cn/512c8e4e9ead49008d4a9eb874e8b3dc.png
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 查看边沿节点容器组：
https://img-blog.csdnimg.cn/53cbb16577e94386816a81f333fa79b5.png
运行应用
既然边沿节点注册进来了，我们来运行个应用吧。
进入项目-应用负载，创建一个 Deployment 工作负载：
https://img-blog.csdnimg.cn/7ed586093857472ca64e6955bf5685fe.png
https://img-blog.csdnimg.cn/0894d7c0dd05471e8d558a48f838b7ec.png
https://img-blog.csdnimg.cn/d15473cec538426e9b277d72d10de42c.png
设置资源限制
https://img-blog.csdnimg.cn/d3b8d3bd4a2145008cb907dd65cbc6ab.png
选择节点分配：
https://img-blog.csdnimg.cn/53580eae0a1646b5abb0fc859420f434.png
创建后会表现节点存在污点无法调治，需要加上 toleration：
https://img-blog.csdnimg.cn/044466ffe9074ecfb595d19da5eae7f2.png
https://img-blog.csdnimg.cn/88304647202d41bfb349dacfdd228f67.png
编辑 nginx-edge 应用的 yaml，添加对 edge 的 toleration：
https://img-blog.csdnimg.cn/33c843e523b64eeb8d7077d3ae34f47d.png
添加污点容忍后，Pod 运行乐成：
https://img-blog.csdnimg.cn/42b36257d94e4c8b801074fe33c32251.png
设置一个 NodePort Service，访问 Nginx 服务：
https://img-blog.csdnimg.cn/ce6f5635c5374ac4953ead51a43ec0a4.png
https://img-blog.csdnimg.cn/039e4262f4054b3186c28390c14f8019.png
https://img-blog.csdnimg.cn/dec9d02c331f4558b949cc8ddacde885.png
此时可以发现访问是不通的，由于云端无法访问边沿端的 Pod 网络，查看边沿 nginx-edge 的 ip：
bash-5.1# kubectl get pod -n demo -o wide
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：
$ curl 172.17.0.2
<!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 地址：
$ ip ad
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:1a:fa:b2:cb brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:1aff:fefa:b2cb/64 scope link
valid_lft forever preferred_lft forever $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b6c296a4dc16 nginx "/docker-entrypoint.…" 7 minutes ago Up 6 minutes k8s_container-zpnv7r _nginx-edge-68c66d6bf9-k9l6n_demo_99d01b2c-9ca7-4d56-a475-ab1b6838a35d_0
4e72f538703c kubeedge/pause:3.1 "/pause" 11 minutes ago Up 11 minutes k8s_POD_nginx-edge-6 8c66d6bf9-k9l6n_demo_99d01b2c-9ca7-4d56-a475-ab1b6838a35d_0 我们可以看到 nginx-edge 这个容器还是以 Pod 情势运行的，通过 pause 容器共享网络定名空间，只不外它没有使用集群的 PodCIDR 分配，而是使用 docker bridge 网络。因此在没有 coredns 和 kube-proxy 的服务发现和云边容器网络互通的条件下，边端的 Pod Service 是无法访问的。这很符合边云特点，边沿端更多是私网，且无法被云端访问，这种单向通讯的特点需要有其他情势的网络促成云边的通讯和服务访问，比如创建隧道。
云边服务互访
KubeEdge 社区有个 EdgeMesh 的项目。在边沿盘算机的场景下，网络拓扑结构更加复杂。不同区域的边沿节点往往不能互联，而应用之间又需要业务流量互通。EdgeMesh 即可满意边沿节点之间流量互通的要求。按照官方 Github 介绍，EdgeMesh 作为 KubeEdge 集群的数据平面组件，为应用程序提供简朴的服务发现和流量署理功能，从而屏蔽了边沿场景中的复杂网络结构。
因此 EdgeMesh 重要实现两个终极目标：
[*]用户可以在不同的网络中访问边到边、边到云、云到边的应用
[*]摆设 EdgeMesh 相当于摆设了 CoreDNS+Kube-Proxy+CNI
摆设 EdgeMesh
摆设有些前置条件，比如开启 Edge Kube-API Endpoint: 开启 cloudcore dynamicController：
$ vim /etc/kubeedge/config/cloudcore.yaml
modules:
...
dynamicController:
enable: true 开启 Edge metaServer：
$ vim /etc/kubeedge/config/edgecore.yaml
modules:
...
edgeMesh:
enable: false
...
metaManager:
metaServer:
enable: true 添加 edgemesh commonconfig 信息：
$ vim /etc/kubeedge/config/edgecore.yaml
modules:
...
edged:
clusterDNS: 169.254.96.16
clusterDomain: cluster.local
... 重启 cloudcore 和 edgecore 后，可在 edge 端验证是否能哀求 kube-API：
#curl 127.0.0.1:10550/api/v1/services
{"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 摆设到此项目中。 https://img-blog.csdnimg.cn/fb11596996b843ebaae9925b99b3e8ce.png https://img-blog.csdnimg.cn/93bafdeb2f8e407e9f030d9b088d0522.png 此时需要修改应用设置的 server.nodeName，server.advertiseAddress。 https://img-blog.csdnimg.cn/97d12a1fab7e4e5e977b21833292b02c.png 实验安装，安装乐成后查看 edgemesh-server 和 edgemesh-agent 运行情况： https://img-blog.csdnimg.cn/467f49e9b621478cb039419d4d983639.png https://img-blog.csdnimg.cn/f54ce59ea1c34812a25d68e269bf4763.png
测试边端服务访问：
使用示例应用 https://github.com/kubeedge/edgemesh/examples，摆设一个 hostname 应用及服务： https://img-blog.csdnimg.cn/26424914c88c4772a2eece12e0ac496b.png https://img-blog.csdnimg.cn/7b377d9734254dbc967cd54ab68e869f.png 测试从云端的 Pod 访问边沿 Service: https://img-blog.csdnimg.cn/e9d1093b9cea4ab797bc9eac44870b96.png
测试云边互访：
摆设 https://github.com/kubeedge/edgemesh/examples 的 cloudzone 和 edgezone 应用： https://img-blog.csdnimg.cn/0e9dec73c59340a289ccbb0d99cd1b69.png https://img-blog.csdnimg.cn/a415da96abcf4aaf977f9602eb43055a.png 云端 busybox 访问边端应用： https://img-blog.csdnimg.cn/6613713118ea4af7a18dd78a67b7691d.png 边端 busybox 访问云端应用：
$ 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. 边沿设备数据访问
摆设一个模仿温度数据获取的 App：
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：
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：
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 应用： https://img-blog.csdnimg.cn/0271c39af60d43ab8d617028c0dddc55.png 查看 temperature 应用日志： https://img-blog.csdnimg.cn/65af25e12a554f6e805f228fc362eb69.png 使用 kubectl 查看 device 状态：
# kubectl get device temperature -oyaml
···
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 来实验镜像的拉取任务： https://img-blog.csdnimg.cn/d8e2e8b1f9c5424eb4fe6613043b0c25.png 对于大规模边沿节点场景，可以通过 ImagePullJob 筛选节点后进行批量预热，一个 ImagePullJob 创建后，会被 kruise-manager 中的 imagepulljob-controller 吸取到并处理，将其分解并写入到所有匹配节点的 NodeImage 中，以此来完成规模化的预热。
apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
name: job-with-always
spec:
image: nginx:1.9.1 # 完整的镜像名 name:tag
parallelism: 10 # 最大并发拉取的节点梳理, 默认为 1
selector: # 指定节点的 名字列表 或 标签选择器 (只能设置其中一种)
names:
- node-1
- node-2
matchLabels:
node-type: xxx
# podSelector: # 通过 podSelector 匹配Pod，在这些 Pod 所在节点上拉取镜像, 与 selector 不能同时设置.
# matchLabels:
# pod-label: xxx
# matchExpressions:
# - key: pod-label
# operator: In
# values:
# - xxx
completionPolicy:
type: Always # 默认为 Always
activeDeadlineSeconds: 1200 # 无默认值, 只对 Alway 类型生效
ttlSecondsAfterFinished: 300# 无默认值, 只对 Alway 类型生效
pullPolicy: # 默认 backoffLimit=3, timeoutSeconds=600
backoffLimit: 3
timeoutSeconds: 300 以上就是本次分享的全部内容，重要目标为把 KubeSphere 的边沿盘算用起来，那么这把剑舞到什么程度，还要继续打磨技术+专业服务。
本文由博客一文多发平台 OpenWrite 发布！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]