*本文作者系VMware中国研发中心研发总监 路广
上一篇文章《设备集群上的Kubernetes》介绍了业内各种将Kubernetes部署到边缘的技术方案，而Linux基金会边缘计划运营的EdgeX Foundry开源项目是可分布式部署的边缘计算框架的佼佼者。在讨论如何将EdgeX Foundry部署到Kubernetes上之前，先介绍一下EdgeX Foundry微服务架构的内涵。
第七篇 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设备
依据各微服务依次启动的依赖关系，稍简化后、可以画出如上的有向无环图（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生态系统比较，可以得到下表：
可以看出，对于像定时、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)，关注的焦点大致如上。
一种隐约可见的、但可能有危险的期望是：云化边缘应用本身，而不只是云化边缘应用的管理。云边协同、或者云边融合，一定要根据实际需要，进行充足的验证而逐步演进。切不可试图一蹴而就，揠苗助长。
关于边缘计算和边缘设备与云计算和服务器之间特性的比较，在第一篇前言里已经阐述，这里不再重复。
- 未完待续 -
系列文章（八）预告
从《系列文章（二）丨构造与安装虚拟化设备》起，以上诸篇主要讨论了边缘设备和边缘应用的管理。从下一篇起，将会退一步，从更宏观的角度来检视企业环境内的云边协同。