*本文作者系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)，關注的焦點大致如上。
一種隱約可見的、但可能有危險的期望是：雲化邊緣應用本身，而不只是雲化邊緣應用的管理。雲邊協同、或者雲邊融合，一定要根據實際需要，進行充足的驗證而逐步演進。切不可試圖一蹴而就，揠苗助長。
關於邊緣計算和邊緣設備與雲計算和服務器之間特性的比較，在第一篇前言裏已經闡述，這裏不再重複。
- 未完待續 -
系列文章（八）預告
從《系列文章（二）丨構造與安裝虛擬化設備》起，以上諸篇主要討論了邊緣設備和邊緣應用的管理。從下一篇起，將會退一步，從更宏觀的角度來檢視企業環境內的雲邊協同。