<th id="4os99"><pre id="4os99"></pre></th>
<form id="4os99"></form> 
邊緣計算場景概述
典型的邊緣計算場景分為:
1. 物聯網近場場景（例如智慧城市，智能家居等），其特點是需要接入海量設備。
2. 分布式數據中心場景（例如游戲服務器，CDN），其特點是計算資源按地理區域離散分布，但無需接入設備。
傳統分布式架構數據中心在技術層次上，主要包括兩個概念：
??單個數據中心的分布式架構
??多個數據中心的分布式架構。
前者通常是指基于IaaS或PaaS云計算架構而建設成的數據中心，這種架構已經成為主流數據中心建設模式。后者主要指基于數據復制技術，由多個數據中心統一整合成的聯合數據中心，旨在實現業務連續性災備，多中心運營和管理等。
邊緣計算下的分布式數據中心關注點和傳統分布式架構數據中心有所不同，原因在于邊緣計算領域內的應用對帶寬和時延的極度敏感，這要求數據中心必然是近端、小型而大量分布的。在靠近城市、商業區或者通信基站的區域下，將建成更多的小型數據中心以支撐如物聯網、AI、云游戲等應用。
|
不同場景下的分布式DC |
傳統 |
邊緣計算 |
|
單系統DC個數與區域分布 |
小、<5個 異地多活 |
多，100+ 廣域分布 |
|
單DC節點規模 |
大 >100節點 |
小 <50 |
|
與用戶端的距離 |
遠 |
近 |
|
帶寬與時延敏感 |
相對低 |
高 |
|
DC間通信需求與網絡基礎 |
高，VPN、專線，穩定可靠 |
低，公網，不穩定不可靠 |
|
典型應用 |
異地災備 |
云游戲、CDN |
|
異構計算接入能力需求 |
相對低 |
高 |
案例亮點Highlight
諧云為國內某大型公司已搭建了私有容器云PaaS中心云平臺，大部分業務已經上云，但全國各省市級數據中心的業務部署運維仍然是傳統的人工模式，服務器資源利用率低下。每個省市級數據中心均可視為一個邊緣數據中心，其特點是規模?。?0+臺），分布廣（全國分布），數量多（100+DC），邊緣業務運維成本高，這也是很多企業會面臨的問題。
那如何解決這些問題呢？諧云在云邊協同方面的研究成果為企業帶來全面數字化轉型新模式。
1. 基于主流K8S架構，復用云原生生態賦能云邊協同平臺
2. 基于中心容器云，邊緣去中心化，權限高度收斂于中心云
3. 支持云邊跨公網，無需為DC大量鋪設專線
4. 邊緣有限自治，云邊斷連下節點仍能穩定對外服務
5. 邊緣數據中心逐節點入云，入云粒度最小至單節點
云邊協同平臺旨將中心容器云的彈性計算能力下沉至邊緣省市級數據中心，以此來提升邊緣應用的交付速度，提升資源利用率，提升業務運維效率，進而合理有效的降低邊緣的運維成本。
方案選型-邊緣計算領域現有框架與Kubernetes聯邦
上述四種業內開源邊緣計算框架+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 系統里，需要解決下面的問題:
1. 網絡斷連時，節點異?；蛑貑r，內存數據丟失，業務容器無法恢復；
2. 網絡長時間斷連，云端控制器對業務容器進行驅逐；
3. 長時間斷連后網絡恢復時，邊緣和云端數據的一致性保障。
4. 網絡不穩定下，K8S client ListWatch機制下為保證數據一致性，在每次重連時都需要同步ReList一次，較大規模的邊緣節點數量加以較不穩定的網絡，將造成巨大的網絡開銷和API Server的cpu負擔，特別是不可靠的遠距離跨公網場景。
OpenYurt與KubeEdge所做的種種設計都是為了解決以上四個問題。不同的是OpenYurt設計思路是針對K8S HTTP api請求的代理與緩存，而KubeEdge的設計思路是K8S事件監聽與消息化可靠推送-監聽邊緣資源的增刪改查事件并主動推送至邊緣節點：
1. 對于問題一，OpenYurt和KubeEdge在邊緣均設計了持久化的邊緣數據庫，節點重啟后若網絡仍然斷連，數據將從邊緣數據庫中讀入。
2. 對于問題二，OpenYurt和KubeEdge均使用Admission Webhook方案，在云上攔截、控制作用于邊緣資源的請求。
3. 對于問題三，OpenYurt會在網絡恢復時，從云端同步最新的數據。而KubeEdge則是每隔一段時間比較云上資源與邊緣資源的版本差異，若云上資源較新，則生成一例增刪改事件下發至邊緣節點，網絡斷連時此事件被拋棄，網絡重連時事件發送成功，觸發邊緣同步更新。
4. 對于問題四，暫不知OpenYurt對此做了何設計，在KubeEdge中，由于數據一致性由云端維護，同步均由云端發起，邊端不再有類List請求。
5. OpenYurt同KubeEdge都是星型拓撲結構，在邊緣去中心化，一個邊緣數據中心的所有邊緣節點都是同等級的peer node，同云中心的kubelet節點一致，均強受制于云上master節點，只是在地理區位上距離master節點有遠近之分。
KubeEdge同時適用于邊緣計算下的物聯網與分布式數據中心場景，但是在后者中并不需要一些為物聯網近場場景而設計的設備側功能，使用上可以禁用；OpenYurt在阿里內部主要配合CDN業務，在設計上并未考慮在平臺層進行設備接入，而是認為設備應該由基于平臺的物聯網應用接入，更適配分布式數據中心場景。但由于OpenYurt在今年6月才開源，諧云邊緣計算團隊在19年12月便開始了技術預研與選型，因而最終選擇了18年便已經開源KubeEdge。
KubeEdge軟件架構
諧云落地實踐與KubeEdge改造賦能將在第二部分著重講述，請關注下期分享～
CpjJwWHV
CpjJwWHV
