系列文章(七)丨Kubernetes上的EdgeX Foundry资料

本文主要介绍系列文章(七)丨Kubernetes上的EdgeX Foundry资料 方法和在新技术下所面对的“挑战”,方便大家深入理解系列文章(七)丨Kubernetes上的EdgeX Foundry资料 过程。本文也将分享系列文章(七)丨Kubernetes上的EdgeX Foundry资料 所遇到的问题和应对策略。
通过深入本文可以理解代码原理,进行代码文档的下载,也可以查看相应 Demo 部署效果。

*本文作者系VMware中国研发中心研发总监 路广

上一篇文章《设备集群上的Kubernetes》介绍了业内各种将Kubernetes部署到边缘的技术方案,而Linux基金会边缘计划运营的EdgeX Foundry开源项目是可分布式部署的边缘计算框架的佼佼者。在讨论如何将EdgeX Foundry部署到Kubernetes上之前,先介绍一下EdgeX Foundry微服务架构的内涵。

第七篇 EdgeX Foundry微服务架构

系列文章(七)丨Kubernetes上的EdgeX Foundry

以EdgeX Foundry在2020年5月发布的Geneva版本docker-compose-geneva-redis.yml为例:

  • consul: 服务注册及发现

  • vault: secret存储

  • security-secrets-setup: 产生secret设置

  • vault-worker: secret存储设置

  • List item

  • 反向代理
    -kong-db: postgres数据库
    -kong-migrations: 迁移
    -kong: API网关
    -edgex-proxy: 安全设置

  • redis: 数据库

  • system: 系统管理代理

  • notifications: 支持通知

  • metadata: 元数据

  • data:核心数据

  • command: 命令

  • scheduler: 定时任务

  • app-service-rules: 可配置应用服务

  • rulesengine: 规则引擎

  • device-virtual: 虚拟设备

  • device-rest: Restful API设备
    系列文章(七)丨Kubernetes上的EdgeX Foundry

依据各微服务依次启动的依赖关系,稍简化后、可以画出如上的有向无环图(DAG)。从上图可以看出,EdgeX Foundry的核心模块聚集在左侧,右侧基本上是支持管理性微服务/模块。

分布式部署EdgeX Foundry

根据上面的分析结果,如果要将EdgeX Foundry进行分布式部署,需要实现:

设备服务Daemon化,以在特定设备上保持南向连接

  • 比如device-modbus
    核心数据服务有状态,须连接持久化存储/卷
  • 比如redis、kong-db
    响应性服务无状态,可以考虑多实例部署
  • 比如command
    应用服务Daemon化,以在特定设备上保持北向连接(可选)
  • 比如app-service-rules

当然,实际分布式部署EdgeX Foundry的情况可能千差万别,这里只是举最常见的例子。
系列文章(七)丨Kubernetes上的EdgeX Foundry

与Kubernetes对象适配
Kubernetes通过Pod和Controller来管理部署于其上的应用。Pod包含一个或多个容器,它是Kubernetes对象模型中的最小可部署对象,也是应用的最小可执行单元。Kubernetes通过Controller来部署应用,这些应用可由运行特性不同的ReplicaSet、StatefulSet、DameonSet等类型的Pod组成。

如果将EdgeX Foundry的当前模块与Kubernetes的不同Pod类型来对应,可以得到如下粗略列表:

  • Deployment/ReplicaSet: consul, command, rulesengine, …
  • DaemonSet:device services, app-service-rules, …
  • StatefulSet: redis, data,metadata, …
  • Job/CronJob: scheduler

需要注意的是这些对应只是从功能角度大致匹配,但实际执行方式可能会有较大差别。有些是长时运行,而其对应的模块可能是平台服务、或由平台服务触发的短时任务,比如定时。

如果将EdgeX Foundry在Docker上的原生部署服务和Kubernetes生态系统比较,可以得到下表:

系列文章(七)丨Kubernetes上的EdgeX Foundry

可以看出,对于像定时、API代理、服务发现、部署这样的基础功能,是比较容易从Kubernetes生态里找到对应的轻量级服务的。

另一个选项是保留在Docker中采用的原始服务,但这样就不能像Kubernetes原生应用那样运维了。而这并非本篇讨论的初心。

Helm Chart
更进一步地,可以将部署方式从Docker Compose转换为Helm Chart(https://helm.sh/)。同时,充分考虑分布式部署EdgeX Foundry在网络和存储方面的需求和设置,利用比如Flannel(https://github.com/coreos/flannel)和PersistentVolume(https://kubernetes.io/docs/concepts/storage/persistent-volumes/)之类服务实现。

之前业内已经有如下的若干尝试,只是在大约1-2年前纷纷停止于Delhi或Edinburgh版本。
https://github.com/edgexfoundry-holding/edgex-helm-chart

https://github.com/edgexfoundry-holding/edgex-kubernetes-support

https://github.com/rohitsardesai83/edgex-on-kubernetes

近期,VMware也在积极地准备将Geneva版本的EdgeX Foundry通过Helm Chart部署在Kubernetes上,很快就会放出开源代码给社区。

Operator

在支持Helm Chart之上,可以考虑利用Kubernetes应用管理平台上的Operator,实现云边协同的统一管理。

系列文章(七)丨Kubernetes上的EdgeX Foundry

Service Mesh
对于更复杂的功能,例如生命周期管理、Service Mesh等,在Kubernetes生态里能找到很好的实现,但这些技术是否适合在资源有限的边缘设备上应用,就需要打个问号了。

比如Istio里的连接、安全、策略、观测等功能,在现在EdgeX Foundry架构定义和部署方式下:统一身份认证、共享网络、资源有限、外联受限,恐怕要花更多时间进一步观察和讨论。即使退一步讲,对于普通的边缘应用来说是否有足够的意义,也要仔细考虑。

重构EdgeX Foundry
在所有这些讨论的基础上,可能就会有或隐或现的想法,试图重构EdgeX Foundry,让其更符合Kubernetes、或者更准确地说:云原生应用的分布式部署架构。

这个想法看起来很迷人,主要的希望如下:

  • 数据及服务高可用性
  • 增强安全性
  • 从云侧基于策略管理
  • 细粒度资源控制
  • 和Kubernetes深度兼容与集成

这些理由从长远来看都是有效需求,但关键问题在于何时、以何种方式实现。近期在Hanoi版本的项目计划会上(https://wiki.edgexfoundry.org/display/FA/Mar+31+Hanoi+Virtual+PreWire)及之后有一系列热烈的讨论(https://edgexfoundry.slack.com/archives/CE6914ZDL/p1589482287033800),关注的焦点大致如上。

一种隐约可见的、但可能有危险的期望是:云化边缘应用本身,而不只是云化边缘应用的管理。云边协同、或者云边融合,一定要根据实际需要,进行充足的验证而逐步演进。切不可试图一蹴而就,揠苗助长。

关于边缘计算和边缘设备与云计算和服务器之间特性的比较,在第一篇前言里已经阐述,这里不再重复。

  • 未完待续 –

系列文章(八)预告
从《系列文章(二)丨构造与安装虚拟化设备》起,以上诸篇主要讨论了边缘设备和边缘应用的管理。从下一篇起,将会退一步,从更宏观的角度来检视企业环境内的云边协同。

注意:本文归作者所有,未经作者允许,不得转载
系列文章(七)丨Kubernetes上的EdgeX Foundry资料部分资料来自网络,侵权毕设源码联系删除

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » 系列文章(七)丨Kubernetes上的EdgeX Foundry资料

提供最优质的资源集合

立即查看 了解详情