*本文做者系VMware中國研發中心研發總監 路廣git
上一篇文章《設備集羣上的Kubernetes》介紹了業內各類將Kubernetes部署到邊緣的技術方案，而Linux基金會邊緣計劃運營的EdgeX Foundry開源項目是可分佈式部署的邊緣計算框架的佼佼者。在討論如何將EdgeX Foundry部署到Kubernetes上以前，先介紹一下EdgeX Foundry微服務架構的內涵。github
第七篇 EdgeX Foundry微服務架構redis
以EdgeX Foundry在2020年5月發佈的Geneva版本docker-compose-geneva-redis.yml爲例：docker
-
consul: 服務註冊及發現數據庫
-
vault: secret存儲安全
-
security-secrets-setup: 產生secret設置服務器
-
vault-worker: secret存儲設置網絡
-
List item架構
-
反向代理
-kong-db: postgres數據庫
-kong-migrations: 遷移
-kong: API網關
-edgex-proxy: 安全設置app -
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)，關注的焦點大體如上。
一種隱約可見的、但可能有危險的指望是：雲化邊緣應用自己，而不僅是雲化邊緣應用的管理。雲邊協同、或者雲邊融合，必定要根據實際須要，進行充足的驗證而逐步演進。切不可試圖一蹴而就，揠苗滋長。
關於邊緣計算和邊緣設備與雲計算和服務器之間特性的比較，在第一篇前言裏已經闡述，這裏再也不重複。
- 未完待續 -
系列文章（八）預告 從《系列文章（二）丨構造與安裝虛擬化設備》起，以上諸篇主要討論了邊緣設備和邊緣應用的管理。從下一篇起，將會退一步，從更宏觀的角度來檢視企業環境內的雲邊協同。