本文主要介紹諧雲在邊緣計算-分佈式數據中心子場景下，基於開源框架KubeEdge開展雲邊協同落地過程中的實踐經驗，爲企業帶來全面的數字化轉型新模式。
邊緣計算場景概述
典型的邊緣計算場景分爲:
- 物聯網近場場景（例如智慧城市，智能家居等），其特點是需要接入海量設備。
- 分佈式數據中心場景（例如遊戲服務器，CDN），其特點是計算資源按地理區域離散分佈，但無需接入設備。
傳統分佈式架構數據中心在技術層次上，主要包括兩個概念： 🔹單個數據中心的分佈式架構 🔹多個數據中心的分佈式架構。
前者通常是指基於IaaS或PaaS雲計算架構而建設成的數據中心，這種架構已經成爲主流數據中心建設模式。後者主要指基於數據複製技術，由多個數據中心統一整合成的聯合數據中心，旨在實現業務連續性災備，多中心運營和管理等。
邊緣計算下的分佈式數據中心關注點和傳統分佈式架構數據中心有所不同，原因在於邊緣計算領域內的應用對帶寬和時延的極度敏感，這要求數據中心必然是近端、小型而大量分佈的。在靠近城市、商業區或者通信基站的區域下，將建成更多的小型數據中心以支撐如物聯網、AI、雲遊戲等應用。 
案例亮點Highlight
諧云爲國內某大型公司已搭建了私有容器雲PaaS中心雲平臺，大部分業務已經上雲，但全國各省市級數據中心的業務部署運維仍然是傳統的人工模式，服務器資源利用率低下。每個省市級數據中心均可視爲一個邊緣數據中心，其特點是規模小（10+臺），分佈廣（全國分佈），數量多（100+DC），邊緣業務運維成本高，這也是很多企業會面臨的問題。
那如何解決這些問題呢？諧雲在雲邊協同方面的研究成果爲企業帶來全面數字化轉型新模式。
- 基於主流K8S架構，複用雲原生生態賦能雲邊協同平臺
- 基於中心容器雲，邊緣去中心化，權限高度收斂於中心雲
- 支持雲邊跨公網，無需爲DC大量鋪設專線
- 邊緣有限自治，雲邊斷連下節點仍能穩定對外服務
- 邊緣數據中心逐節點入雲，入雲粒度最小至單節點
雲邊協同平臺旨將中心容器雲的彈性計算能力下沉至邊緣省市級數據中心，以此來提升邊緣應用的交付速度，提升資源利用率，提升業務運維效率，進而合理有效的降低邊緣的運維成本。
方案選型-邊緣計算領域現有框架與Kubernetes聯邦
- K3S
- EdgeX
- Openyurt
- KubeEdge
- Kube Federation
上述四種業內開源邊緣計算框架+Kube Federation中，設計時偏向於物聯網近場場景的框架有K3S、EdgeX和KubeEdge；設計時偏向於分佈式數據中心場景的框架有OpenYurt、Kube Federation和KubeEdge。
K3S與EdgeX，前者是K8S的精簡版，旨在在邊緣受限的計算資源下部署kubernetes集羣，但是集羣與集羣之間的聯合並未考慮，屬於單數據中心的分佈式系統建設方案；後者核心是基於與硬件和操作系統完全無關的參考軟件平臺建立的互操作框架，加速物聯網方案的部署，但並不是基於Kubernetes的擴展，而無法較好地適配Kubernetes上層生態的成熟方案，例如監控、日誌、微服務等。這兩者均不太符合邊緣計算場景下的分佈式數據中心。
Federation並不是典型的邊緣計算框架，其主要解決多K8S集羣的協調運作問題，符合傳統分佈式計算中心場景。但在設計上未考慮邊緣計算場景，對於節點數量規模少於10臺的超小型計算中心再部署K8S集羣將有較大佔比的服務器用於構建K8S控制面節點（爲保證高可用一般是3臺），這是開銷巨大的。且由於Kube Federation V1版本在k8s v1.10後被拋棄，V2版本迭代慢，各種特性未GA，我們最終並未選擇基於Kube Federation搭建雲邊協同平臺。
接下來重點介紹基於Kubernetes的兩個邊緣計算架構KubeEdge與Openyurt。
Kubernetes在邊緣
隨着Kubernetes成爲容器編排領域的事實標準，雲原生領域的開源生態快速繁榮發展。諧雲認爲一個好的邊緣計算框架必然是基於Kubernetes的擴展，以複用已有的生態與開源力量，爲雲邊協同平臺賦能，是降本增效的最佳解決途徑。
邊緣計算框架在 Kubernetes 系統裏，需要解決下面的問題:
- 網絡斷連時，節點異常或重啓時，內存數據丟失，業務容器無法恢復；
- 網絡長時間斷連，雲端控制器對業務容器進行驅逐；
- 長時間斷連後網絡恢復時，邊緣和雲端數據的一致性保障。
- 網絡不穩定下，K8S client ListWatch機制下爲保證數據一致性，在每次重連時都需要同步ReList一次，較大規模的邊緣節點數量加以較不穩定的網絡，將造成巨大的網絡開銷和API Server的cpu負擔，特別是不可靠的遠距離跨公網場景。
OpenYurt與KubeEdge所做的種種設計都是爲了解決以上四個問題。不同的是OpenYurt設計思路是針對K8S HTTP api請求的代理與緩存，而KubeEdge的設計思路是K8S事件監聽與消息化可靠推送-監聽邊緣資源的增刪改查事件並主動推送至邊緣節點：
- 對於問題一，OpenYurt和KubeEdge在邊緣均設計了持久化的邊緣數據庫，節點重啓後若網絡仍然斷連，數據將從邊緣數據庫中讀入。
- 對於問題二，OpenYurt和KubeEdge均使用Admission Webhook方案，在雲上攔截、控制作用於邊緣資源的請求。
- 對於問題三，OpenYurt會在網絡恢復時，從雲端同步最新的數據。而KubeEdge則是每隔一段時間比較雲上資源與邊緣資源的版本差異，若雲上資源較新，則生成一例增刪改事件下發至邊緣節點，網絡斷連時此事件被拋棄，網絡重連時事件發送成功，觸發邊緣同步更新。
- 對於問題四，暫不知OpenYurt對此做了何設計，在KubeEdge中，由於數據一致性由雲端維護，同步均由雲端發起，邊端不再有類List請求。
- OpenYurt同KubeEdge都是星型拓撲結構，在邊緣去中心化，一個邊緣數據中心的所有邊緣節點都是同等級的peer node，同雲中心的kubelet節點一致，均強受制於雲上master節點，只是在地理區位上距離master節點有遠近之分。
KubeEdge同時適用於邊緣計算下的物聯網與分佈式數據中心場景，但是在後者中並不需要一些爲物聯網近場場景而設計的設備側功能，使用上可以禁用；OpenYurt在阿里內部主要配合CDN業務，在設計上並未考慮在平臺層進行設備接入，而是認爲設備應該由基於平臺的物聯網應用接入，更適配分佈式數據中心場景。但由於OpenYurt在今年6月纔開源，諧雲邊緣計算團隊在19年12月便開始了技術預研與選型，因而最終選擇了18年便已經開源KubeEdge。 
KubeEdge軟件架構
諧雲落地實踐與KubeEdge改造賦能將在第二部分着重講述，請關注下期分享～