詳解KubeEdge邊緣網路專案EdgeMesh

摘要：本文帶大家進一步瞭解 EdgeMesh 的進展以及未來的規劃。

本文分享自華為雲社群《走向成熟的KubeEdge邊緣網路專案EdgeMesh詳解》，作者：華為云云原生團隊 王傑章 。

KubeEdge 社群邊緣網路方案致力於研究和解決邊緣計算場景下跟網路連通、服務協同、流量治理等相關的一系列問題。其中，EdgeMesh 子專案當前實現了邊緣計算場景下應用的跨雲邊、跨邊邊的網路通訊，目前專案已逐漸從一個創新專案走向成熟，被多家廠商整合到自己的邊緣計算解決方案中。本文帶大家進一步瞭解 EdgeMesh 的進展以及未來的規劃。

▍1 邊緣網路通訊挑戰

下圖展示了一個目前比較通用的邊雲協同影片AI服務的大致架構，通過這個服務我們可以去做一些人臉識別、人流分析等任務，並將這些技術運用在安防、交通、電力等等實際的產業裡。如下圖所示，邊緣會有一些端側裝置接入到EdgeCore中，比如攝像頭或車載系統，在某些場景下邊緣應用會採集影片流、圖片、音訊等等媒體資源，再到雲上處理或訓練，通過這種邊雲協同的方式來提高AI識別的精度。

但是在邊緣計算場景下，會遇到一些困難和挑戰使得沒法順利的完成這些功能。總結如下：

• 邊雲、邊邊網路割裂，微服務之間無法跨子網直接通訊
• 邊緣端網路質量不穩定，節點離線、網路抖動是常態
• 邊緣場景下網路組網複雜、配置管理困難
• 邊緣側缺少服務發現、負載均衡與流量治理等能力

通過上述邊緣計算場景網路通訊面臨的挑戰分析，總結歸納後，我們將它們抽象成了一個分層的結構。

如上圖所示，邊緣網路通訊痛點問題主要分為三個層次：

從物理鏈路層看

1. 邊緣網路拓撲構造複雜，網路質量不穩定
2. 邊雲、邊邊物理網路割裂，多邊服務協同困難

從虛擬網路層看

1.傳統的虛擬網路技術，比如kube-proxy、cni等，無法解決跨網路資料的轉發2.資料處理鏈路較長，專線鋪設造價昂貴

從物理鏈路層看

1. 邊緣網路拓撲構造複雜，網路質量不穩定
2. 邊雲、邊邊物理網路割裂，多邊服務協同困難

▍2 KubeEdge的邊緣網路 Scope

依據上面的痛點分析結果，我們歸納出了當前階段主要關注的幾個核心問題的範疇。如下所示，依舊是按照一個分層的結構去抽象問題。

邊緣物理網路層

邊緣物理網路層也是使用傳統的計算機網路技術搭建的網路基礎設施。在邊緣場景裡，物理網路一般都是基於區域隔離，大到跨省、跨市，小到跨園區。它們之間的網路往往是不互通的，必須經過因特網以及電信運營商的網路才能互通。對於物理網路這個層次，其實很難在這個層面進行改造，主要因為物理網路層幾乎都是硬體的基礎設施，確實不太好深入去改造，所以我們主要將焦點瞄準在上面幾個層次。

邊緣隧道網路層

邊緣隧道網路層最核心的問題就是如何將下層割裂的物理網路進行連通，以此遮蔽邊緣網路拓撲的複雜性。這層核心的能力是提供網路隧道技術、加密技術等，主要的業界實現有libp2p，ipsec等。像EdgeMesh其實就是用到了libp2p技術，嘗試去建立每個對等點的連線（無論這些對等點是否處於同一個子網內），以此形成一個p2p的隧道網路。像阿里雲開源的raven以及博雲開源的fabedge就是用了ipsec技術來完成這件事情。像kilo這款cni外掛，用了wireguard技術先實現了隧道網路，再實現了cni的功能。

邊緣容器網路層

容器網路主要圍繞cni技術展開，前文也提到過邊緣場景下cni外掛是不支援跨子網轉發資料的，因為cni本身依賴三層網路能互通。所以邊緣容器網路得依賴邊緣隧道網路層的能力才能發揮原本cni容器網路配置、資料包封包和路由以及網路策略的能力。上層依賴下層提供的服務的形式型別於計算機網路協議棧的概念。EdgeMesh目前缺失邊緣容器網路層的能力，因此EdgeMesh目前還不支援pod ip級別的資料轉發，也還不支援網路策略，不過這塊內容在EdgeMesh未來的路標內。

邊緣虛擬網路層

能夠通過K8s service去訪問特定的服務是此層的核心功能，主要負責應用暴露服務的透明代理兼負載均衡器，比較常見的實現有k8s官方的kube-proxy，其他還有cilium等。Cilium的能力覆蓋到了容器網路層和虛擬網路層，它使用了ebpf技術能在核心態去轉發資料，效能很高，這也是EdgeMesh未來在效能轉發方面的一個優化方向。

邊緣服務網格層

這一層會提供比容器網路層更加豐富的網路策略管理能力，此外還有很多服務治理功能，比如服務發現、灰度釋出、熔斷、限流、分散式呼叫鏈等等。目前業界實現的istio、linkerd之類的產品，都做的非常強大，EdgeMesh對此層更傾向於整合已有的Service Mesh的成果。

可能有人會疑問的是，除了邊緣隧道網路層以外的其他幾層現在都有業界成熟的實現，那是不是隻需要把邊緣隧道網路層做出來，其他上面幾層直接部署原生的元件即可？其實這是沒問題的，但是可能場景覆蓋得不夠全面。比如在一些資源特別受限的場景下，邊緣計算資源很難整合太多元件（比如kube-proxy、cni外掛、coredns等），而且服務網格資料面使用sidecar模式會佔用更多的資源。然而edgemesh僅需一個輕量的元件（記憶體佔用<80MB）即可解決一切問題，也會採用節點級的模式代替sidecar模式進行服務治理。

▍3 EdgeMesh:邊緣網路通訊解決方案

EdgeMesh定位於解決邊緣場景下雲邊、邊邊網路通訊，下圖是EdgeMesh的架構。

EdgeMesh具有以下幾點優勢：

• 跨子網通訊遮蔽複雜的邊緣網路環境，提供容器間的跨子網邊邊和邊雲通訊能力
• 高可靠性通過NAT穿透技術建立點對點直連，轉發效率高；在不支援打洞時通過中繼轉發流量，保障服務之間的正常通訊
• 雲原生體驗為 KubeEdge 叢集中的容器應用提供與雲原生一致的服務發現與流量轉發體驗
• 輕量化每個節點僅需部署一個極輕的代理元件，採用分層式設計架構，各模組能夠與原生元件相容並支援動態關閉

下圖展示了EdgeMesh的基本工作流程：

▍4 進展與未來規劃

下圖展示了我們正在做的以及後續規格中要做的事項，紅色邊的區域代表目前基本已經完成的模組，後續也會持續的演進和優化。其他藍色區域表示都是在未來規劃內的模組，比如容器網路/網路策略、服務網格、動態路由。動態路由這一塊內容，主要是想去探索一下在移動場景下的網路通訊的優化。最後是訊息系統，目前市面上有很多訊息中介軟體，比如rabbitmq，kafka和redis等，可以為網路環境中為應用系統提供同步或非同步、可靠的訊息傳輸的支撐性軟體系統，這在邊緣網路通訊場景下也是非常有價值的。

關於KubeEdge

KubeEdge是業界首個雲原生邊緣計算框架、雲原生計算基金會內部唯一孵化級邊緣計算開源專案,社群已完成業界最大規模雲原生邊雲協同高速公路專案（統一管理10萬邊緣節點/50萬邊緣應用）、業界首個雲原生星地協同衛星、業界首個雲原生車雲協同汽車、業界首個雲原生油田專案，開源業界首個分散式協同AI框架Sedna及業界首個邊雲協同終身學習正規化，並在持續開拓創新中。

KubeEdge網站 :  http://kubeedge.io

GitHub地址 : http://github.com/kubeedge/kubeedge

Slack地址 : http://kubeedge.slack.com

郵件列表 : http://groups.google.com/forum/#!forum/kubeedge

每週社群例會 : http://zoom.us/j/4167237304

Twitter : http://twitter.com/KubeEdge

文件地址 : http://docs.kubeedge.io/en/latest/

 

 

點選關注，第一時間瞭解華為雲新鮮技術~