乐趣区

关于rancher:云原生边缘设备解决方案Akri-on-k3s初体验

jiezi

作者：
涂家英，SUSE 资深架构师，专一 Cloud-Native 相干产品和解决方案设计，在企业级云原生平台建设畛域领有丰盛的教训。

写在后面

k3s 是 SUSE 推出的为物联网和边缘计算构建的通过认证的 Kubernetes 发行版，它能够帮忙用户在资源受限的场景下应用 kubernetes，并联合 SUSE Rancher 实现云边协同。

将 k3s 与微软开源的 kubernetes 边缘我的项目 Akri 联合应用，用户就领有了在边缘环境发现和应用各种 IOT 设施的能力。

架构

Akri 目前是 CNCF 的一个开源我的项目，其性能简略地说就是能够依据配置主动地寻找到相应的 iot 设施，为其创立关联的工作负载，并且通过一直地检测实现工作负载的动态变化。援用一句官网的形容为：You name it, Akri finds it, you use it.

架构如下：

蕴含了 Controller 服务、Agent 服务和 Discovery Handlers 服务以及两个 CRD 资源。

具体的组件解析能够查看官网文档：https://docs.akri.sh/architec…

上面咱们通过一个示例来更好地了解 Akri 的工作形式。

体验

示例应用了官网提供的一个 OPC UA 温度计 Demo，OPC UA 是当初应用比拟宽泛的工业自动化通信协议，咱们能够通过 Akri 主动发现应用 OPU CA 协定的温度计设施，并为其创立工作负载，采集和应用其产生的温度数据。

示例中体现的大抵工作流程如下：

首先须要模拟出两台 OPC UA 的服务设施，而后在 k3s 集群上部署 Akri 服务，根底工作实现后：

  1. 向集群配置用于发现 OPC UA 设施的 CRD（Configuration）
  2. CRD 下发后，Akri 的相应 Discovery 服务会依照规定寻找 OPC UA 设施
  3. 在找到 OPC UA 设施后，Agent 服务会生成设施对应的 CRD（Instance），Controller 服务查看到 Instance CRD 资源后，将创立对应的工作负载

OPC UA 设施模仿

应用了一个.NET 类型的开源我的项目模仿实现 OPU CA 设施，我的项目地址为：https://gitee.com/leotuss/opc…

克隆到本地后，须要批改以下文件:

# /opcua-dotnet/Applications/ConsoleReferenceServer/Quickstarts.ReferenceServer.Config.xml 文件第 76、77 行
将 <node-ip style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;"> 替换为节点地址

#/opcua-dotnet/Applications/ReferenceServer/Quickstarts.ReferenceServer.Config.xml 文件第 77、78 行
将 <node-ip style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;"> 替换为节点地址 </node-ip></node-ip>`

Linux 要运行这个程序，须要装置.NET core 的 SDK 和 runtime

能够应用以下命令运行此程序：

dotnet run --project /opcua-dotnet/Applications/ConsoleReferenceServer/NetCoreReferenceServer.csproj

运行后，能够看到如下提醒：

root@edge-iot1:~/opcua-dotnet/Applications/ConsoleReferenceServer# dotnet run --project NetCoreReferenceServer.csproj
.Net Core OPC UA Reference Server
opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer
https://192.168.6.151:62540/Quickstarts/ReferenceServer/
Server started. Press Ctrl-C to exit...

至此程序运行胜利，利用能够通过订阅 opc.tcp://:62541/Quickstarts/ReferenceServer 取得数据

装置 Akri

能够通过 Helm 装置 Akri：

# 增加 Akri repo
helm repo add akri-helm-charts https://project-akri.github.io/akri/

# 部署 Akri
helm install akri akri-helm-charts/akri\
    --set kubernetesDistro=k3s \
    --set opcua.discovery.enabled=true

对于 kubernetesDistro 配置，Akri 依赖 crictl 跟踪 pod 信息，所以必须晓得容器运行时 socket 的地位。目前 Akri 反对四种类型：

  • 规范 kuberentes，对应配置为:--set kubernetesDistro=k8s
  • k3s，对应配置为:--set kubernetesDistro=k3s
  • microk8s，对应配置为:--set kubernetesDistro=microk8s
  • 其它，对应配置为:--set agent.host.containerRuntimeSocket=/container/runtime.sock

对于 xxx.discovery.enabled 配置，Akri 目前反对三种设施发现：

  • onvif：IP Cameras 的支流协定
  • opc ua：工业自动化通信协议
  • udev：linux 设施管理器

如咱们须要 Akri 发现 onvif 设施，就能够配置 --set onvif.discovery.enabled=true, 配置后 Akri 会在集群中部署相应的 Discovery 服务，以 Daemonset 的形式运行，反对叠加部署，如须要发现上述三种类型设施，部署命令能够批改为：

helm install akri akri-helm-charts/akri\
    --set kubernetesDistro=k3s \
    --set opcua.discovery.enabled=true \
    --set onvif.discovery.enabled=true \
    --set udev.discovery.enabled=true

部署实现后查看集群 Pods 能够看到：

root@edge-k3s:~# kubectl get pods
NAME                                         READY   STATUS    RESTARTS       AGE
akri-controller-deployment-d4f7847b6-rlgrr   1/1     Running   11 (25h ago)   4d2h
akri-agent-daemonset-9s9m9                   1/1     Running   10 (25h ago)   3d23h
akri-opcua-discovery-daemonset-tv84d         1/1     Running   8 (25h ago)    3d17h

部署 CRD

应用 Akri 发现设施须要部署类型为 Configuration 的 CRD:

apiVersion: akri.sh/v0
kind: Configuration
metadata:
 name: akri-opcua-monitoring
 namespace: default
spec:
 brokerProperties:
   IDENTIFIER: Thermometer_Temperature
   NAMESPACE_INDEX: "2"
 brokerSpec:
   brokerPodSpec:
     containers:
     - image: ghcr.io/project-akri/akri/opcua-monitoring-broker:latest
       name: akri-opcua-monitoring-broker
       resources:
         limits:
           '{{PLACEHOLDER}}': "1"
           cpu: 30m
           memory: 200Mi
         requests:
           '{{PLACEHOLDER}}': "1"
           cpu: 9m
           memory: 76Mi
 capacity: 1
 configurationServiceSpec:
   ports:
   - name: grpc
     port: 80
     protocol: TCP
     targetPort: 8083
   type: ClusterIP
 discoveryHandler:
   name: opcua
   discoveryDetails: |+
     opcuaDiscoveryMethod:
       standard:
         discoveryUrls:
         - opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer/
         - opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer/
     applicationNames:
       action: Exclude
       items: []
   name: opcua
 instanceServiceSpec:
   ports:
   - name: grpc
     port: 80
     protocol: TCP
     targetPort: 8083
   type: ClusterIP

须要关注的配置：

  • spec.brokerProperties: 用于定义须要采集数据的 ID 信息，本演示中 opcua 程序中增加了 IDENTIFIER: 为 Thermometer_Temperature和 NAMESPACE_INDEX: "2" 的数据输入，数据输入内容为 70-80 的随机数，并且在随机到 75 时，将 75 替换为 120
  • spec.brokerSpec.brokerPodSpec.containers.image: 设施对应工作负载的镜像，演示应用的是官网提供的镜像，作用是订阅 opcua 所产生的相应数据，此镜像是能够自定义的，实现更多可能
  • spec.capacity：针对设施的工作负载正本数量，用于实现工作负载高可用
  • spec.discoveryHandler: 这部分次要定义了发现 opuca 设施的规定，反对一些过滤规定
  • spec.configurationServiceSpec：Akri Controller 服务会为所有设施的工作负载创立一个总 svc，这段用于定义相应的 svc 的配置
  • spec.instanceServiceSpec: Akri Controller 服务会为每一个工作负载创立 svc，这段用于定义相应 svc 的配置

示例中能够看到 opuca 的发现规定是具体的服务地址，如果要反对批量的 opuca 设施发现，能够应用 Local discovery server（LDS），将 opcua 的设施注册到 LDS 中，而后在 discoveryUrls 配置中应用 LDS 的地址。采纳 LDS 形式的话，能够实现过滤能力，如排除掉哪些 opcua 服务或者蕴含哪些 opcua 服务，示例如下：

# 发现 LDS 中的所有 opcua 设施，除了 <someserver style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;"> 以外 </someserver>
discoveryDetails: |+
 opcuaDiscoveryMethod:
   standard:
     discoveryUrls:
     - opc.tcp://<lds 服务器地址 style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;">:4840</lds 服务器地址 >
 applicationNames:
   action: Exclude
   items:
   -

将 akri-opcua-monitoring 的 crd 部署到集群后，能够通过 kubectl get akric 查看：

root@edge-k3s:~/akric-crd# kubectl get akric
NAME                    CAPACITY   AGE
akri-opcua-monitoring   1          2m13s

查看 Discovery 的服务日志能够看到，两个 opcua 设施曾经被发现：

[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - found server : Quickstart Reference Server
[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - server has [UAString { value: Some("https://192.168.6.151:62540/Quickstarts/ReferenceServer/discovery") }, UAString {value: Some("opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer") }] DiscoveryUrls
[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_urls - Server at opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer/ responded with 1 Applications
[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - found server : Quickstart Reference Server
[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_impl] get_discovery_url_from_application - server has [UAString { value: Some("https://192.168.6.152:62540/Quickstarts/ReferenceServer/discovery") }, UAString {value: Some("opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer") }] DiscoveryUrls
[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_handler] discover - found OPC UA server at DiscoveryURL opc.tcp://192.168.6.151:62541/Quickstarts/ReferenceServer
[2022-11-10T08:26:26Z TRACE akri_opcua::discovery_handler] discover - found OPC UA server at DiscoveryURL opc.tcp://192.168.6.152:62541/Quickstarts/ReferenceServer

能够通过 kubectl get akrii 查看由 Agent 主动生成的 opcua 的 instance crd 资源：

root@edge-k3s:~/akric-crd# kubectl get akrii
NAME                           CONFIG                  SHARED   NODES          AGE
akri-opcua-monitoring-7aa6fb   akri-opcua-monitoring   true     ["edge-k3s"]   5m10s
akri-opcua-monitoring-20f7e0   akri-opcua-monitoring   true     ["edge-k3s"]   5m9s`

于此同时，应用 kubectl get pods 能够查看到为设施主动创立的工作负载：

NAME                                         READY   STATUS    RESTARTS       AGE
akri-controller-deployment-d4f7847b6-rlgrr   1/1     Running   11 (27h ago)   4d4h
akri-agent-daemonset-9s9m9                   1/1     Running   10 (27h ago)   4d1h
akri-opcua-discovery-daemonset-tv84d         1/1     Running   8 (27h ago)    3d19h
edge-k3s-akri-opcua-monitoring-7aa6fb-pod    1/1     Running   0              6m44s  <---
edge-k3s-akri-opcua-monitoring-20f7e0-pod    1/1     Running   0              6m43s  <---

部署数据展现服务

部署数据展现服务查看成果：

kubectl apply -f https://raw.githubusercontent.com/project-akri/akri/main/deployment/samples/akri-anomaly-detection-app.yaml

部署实现后，查看一下展现服务 SVC 的 NodePort 端口：

root@edge-k3s:~# kubectl get svc
NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes                         ClusterIP   10.43.0.1       <none>        443/TCP        5d6h
akri-opcua-monitoring-7aa6fb-svc   ClusterIP   10.43.152.214   <none>        80/TCP         13m
akri-opcua-monitoring-svc          ClusterIP   10.43.242.118   <none>        80/TCP         13m
akri-opcua-monitoring-20f7e0-svc   ClusterIP   10.43.22.196    <none>        80/TCP         13m
akri-anomaly-detection-app         NodePort    10.43.248.164   <none>        80:32007/TCP   7s <---

拜访 NodePort 端口，查看成果：

这个展现服务原理是通过连贯工作负载的 SVC 获取工作负载采集到的设施数据，当值为 70-80 中任意数值时示意失常，用黑体展现；当值为 120 时示意异样，用红体展现

当设施下线时，Akri 会主动删除设施对应的工作负载，删除的工夫大概为 5 分钟，以便应答可能呈现的长期网络故障。

总 结

Akri 其实能够了解为是一种设施主动发现的框架，它能够通过云原生的形式帮忙咱们发现并应用 IOT 设施，目前反对 onvif、udev、opcua 三种类型。其它包含 Bluetooth、CoAP、IP、LoRaWAN、Zeroconf、acpid、MQTT 也正在开发中。

应用 k3s 能够帮忙用户实现在边缘侧应用 kubernetes 的能力，通过 Akri 能够解决边缘场景下发现和应用设施的问题，这样用户就能将更多的精力专一在数据处理的利用上。

退出移动版