Kubernetes上的EdgeX Foundry | 系列文章（7）
题图摄于北京景山公园中轴线
近期文章：
VMware招聘机器学习和云原生开发工程师
Harbor 2.0的飞跃: OCI 兼容的制品仓库
Harbor从CNCF毕业啦！
KubeFATE: 用云原生技术赋能联邦学习
（转发 VMware 中国研发中心系列文章，本文作者系 VMware 边缘计算实验室主任）
第七篇 EdgeX Foundry微服务架构
以EdgeX Foundry在2020年5月发布的Geneva版本docker-compose-geneva-redis.yml为例：
consul: 服务注册及发现
vault: secret存储
security-secrets-setup: 产生secret设置
vault-worker: secret存储设置
反向代理
- 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设备
依据各微服务依次启动的依赖关系，稍简化后、可以画出如上的有向无环图（DAG）。从上图可以看出，EdgeX Foundry的核心模块聚集在左侧，右侧基本上是支持管理性微服务/模块。
分布式部署EdgeX Foundry
根据上面的分析结果，如果要将EdgeX Foundry进行分布式部署，需要实现：
设备服务Daemon化，以在特定设备上保持南向连接
- 比如device-modbus
核心数据服务有状态，须连接持久化存储/卷
- 比如redis、kong-db
响应性服务无状态，可以考虑多实例部署
- 比如command
应用服务Daemon化，以在特定设备上保持北向连接（可选）
- 比如app-service-rules
当然，实际分布式部署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生态系统比较，可以得到下表：
微服务/模块 |
EdgeX Foundry on Docker |
Kubernetes生态 |
定时服务 |
自制scheduler |
Job/CronJob |
API网关 |
Kong |
Envoy |
服务发现 |
Consul |
CoreDNS |
部署 |
Docker Compose |
Helm Chart |
网络 |
Flannel/Calico |
|
存储 |
Volume |
PV/CSI |
生命周期管理 |
Operator |
|
Service Mesh |
Istio/Network Service Mesh |
可以看出，对于像定时、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，实现云边协同的统一管理。
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)，关注的焦点大致如上。
一种隐约可见的、但可能有危险的期望是：云化边缘应用本身，而不只是云化边缘应用的管理。云边协同、或者云边融合，一定要根据实际需要，进行充足的验证而逐步演进。切不可试图一蹴而就，揠苗助长。
关于边缘计算和边缘设备与云计算和服务器之间特性的比较，在第一篇前言里已经阐述，这里不再重复。
- 未完待续 -
要想了解云原生、区块链和人工智能等技术原理，请立即长按以下二维码，关注本公众号亨利笔记 （ henglibiji )，以免错过更新。
