白話邊緣計算解決方案 SuperEdge

騰訊雲原生發表於2021-07-13

一、SuperEdge的定義

引用下SuperEdge開源官網的定義:

SuperEdge is an open source container management system for edge computing to manage compute resources and container applications in multiple edge regions. These resources and applications, in the current approach, are managed as one single Kubernetes cluster.

翻譯過來的意思是：

SuperEdge 是開源的邊緣容器解決方案，能夠在單 Kubernetes 叢集中管理跨地域的資源和容器應用。

我們通過關鍵詞來簡單解釋下這句話：

  • 開源

這個方案雖然是由騰訊雲容器團隊開源的邊緣容器解決方案，但這是一個完全第三方中立的開源專案。官宣當日分別由 Intel、VMware、美團、寒武紀、首都線上、虎牙、騰訊共同官宣開源，並不由騰訊一家說了算，在邊緣有想法的同學和企業也歡迎參與，共建邊緣，共同推進邊緣計算在實際場景的落地和發展。

  • 邊緣容器解決方案

這句話不用過多的解釋，主要做容器的編排和排程管理。但是目前做容器的排程編排最火的方案是Kubernetes，為什麼不拿 Kubernetes 直接做邊緣容器的編排和排程管理呢？這個後面再解釋。

  • 單 Kubernetes 叢集

還是用 Kubernetes 做容器編排排程，深入瞭解後，發現 SuperEdge 團隊並沒有刪減 Kubernetes 任意一行程式碼，也就是說完全 Kubernetes 原生，具備 Kubernetes 對應版本的全部特性。

  • 單 Kubernetes 叢集中管理跨地域的資源和容器應用

重點詞落在單和跨地域。為什麼要在單 Kubernetes 叢集中管理跨地域的資源和容器應用呢？場景、場景、還是場景決定的。

簡單一個例子，有個連鎖超市，10個營業網點，每個網點都有一個當日的特價廣告推銷程式。各個營業網點之間，以及營業網點和中心管控面之間，網路完全不通，完全獨立，形成地域隔離。每個網點的廣告程式完全一樣，推送的內容也完全一樣，目標是能夠在單 Kubernetes 叢集中，管理10個營業網點，像管理一個網點一樣輕鬆。

二、可能存在的問題

看了SuperEdge官網的特性，我也沒完全懂。什麼是 Network tunneling? 為什麼要 Built-in edge orchestration capability? 介紹的特性到底可以解決什麼問題，我也存疑？

還是拿有個連鎖超市，10個營業網點，中心和網點之間，網點和網點之間網路不通，但要部署運維同一個應用程式來設計下解決方案，看看這其中需要解決的問題，也許對SuperEdge的特性和設計初衷就能就更好的掌握了。

我們看下這個例子在實際的場景中，我們將要面對的問題：

1.10個營業網點一樣的程式

雖然例子中只有10個營業網點，但實際中可能成百上千。我們也要考慮以後的擴充套件性，成百上千網點要讓同一個程式全部都同步起來做一件事，難度自然不小。要是管理成百上千的營業網點，就像管理一個網點一樣輕鬆容易，那確實輕鬆不少。

2.中心和網點之間，網點和網點之間網路不通

現實中真實存在這樣的場景，畢竟專線耗時耗力成本高。真實的場景比較複雜，各個網點可能是一個小機房，也可能是一個小盒子，沒有公網IP。有的網點幾百個盒子，只有一個盒子可以訪問外網，有的甚至所有的盒子都無法訪問外網，部署的時候就相當的困難。

3.弱網、地域相隔甚遠

邊緣的場景不比中心，邊緣的很多盒子，比如攝像頭，各個區域都可能是走公網訪問或者WIFI連線，時不時斷網，短則幾分鐘，或者幾個小時，長則幾天都連不上網，都屬於正常現象。更有甚者，斷電重啟一下……要在這種場景下保證邊緣業務能夠正常提供服務，儘可能提高服務的可用性，就是挑戰了。

4.如何知道邊緣節點的健康性？

邊緣節點不健康了，就要把異常節點的服務排程到可用的節點上去，儘可能的保證服務的健康性。中心和邊緣網路不通，各個網點的網路又不通的情況下，要怎麼知道網點節點的健康性？

5.資源有限

嵌入式邊緣節點往往資源有限，1G1C很常見，如何保證邊緣資源有限的情況下，把邊緣服務執行起來？

6.資源混部

中心雲Kubernetes既想管理中心雲應用，又想管理邊緣應用，怎麼搞呢？

...

不展開說了，這裡面要考慮的細節問題還是比較多的，不能等在實際場景中碰到了才去解決，一定要在方案設計的時候，就儘可能的解決掉將要面對的問題。這樣我們才能把有限的時間投入到具體的業務中，而不是和底層架構較勁。

三、思考自己的解決方案

如果我們遇到上面的問題，如何解決呢？

1.10個營業網點一樣的程式

讓一個程式以不變的環境，一份程式到處執行，比較好的解決方式是什麼？容器，一個測試好的映象，只要底層機型系統一致，執行起來問題不大。

2.用什麼做容器的編排排程呢？

當然是 Kubernetes，可問題是開源社群的 Kubernetes 能直接拿來用嗎？答案是：不能！為什麼？因為Kubernetes官網網路模型中明確表明：

Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):
- pods on a node can communicate with all pods on all nodes without NAT
- agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

也就說 Kubernetes 要求節點和 kube-apiserver 所在 master 節點網路互通，即節點的元件能訪問 master 節點的元件，master 節點的元件也能訪問節點的元件。我們的第二問題是中心和網點間網路不通，直接部署原生的Kubernetes 顯然是行不通的，那麼我們該如何解決邊緣服務的管理呢？

3.弱網

弱網的話，即使我們中心和邊緣建立了連線，但是中心和邊緣也會時不時的斷網，斷網的情況下如何保證邊緣容器正常服務呢？還有重啟邊緣節點，邊緣容器能夠正常服務的問題。

4.地域相隔甚遠，邊緣節點的部署怎麼搞？

地域相隔甚遠就得考慮部署的問題，我們不可能每部署一個網點都跑到使用者那裡去。出了什麼問題，還得使用者給開個後門，遠端連線使用者的節點去解決。

...

拿真實的場景思考下來，面臨的問題還真是不少，希望這些問題可以引起大家的深思，邊緣解決方案沒有統一的標準，只能要能平滑的解決客戶的問題，就是完美的方案。

下來我們一起看看 SuperEdge 的解決方案。

四、SuperEdge的功能

在介紹功能之前我們先把 SuperEdge 的架構圖貼出來，一邊看架構圖，一邊挖掘 SuperEdge 的實現：

1.Network tunneling（tunnel隧道）

看了這個功能的介紹和 SuperEdge 的架構圖，其實 Network tunneling 就是圖中的 tunnel 隧道。在邊緣節點部署一個 tunnel-edge, 在中心部署一個 tunnel-cloud。由 tunnel-edge 主動向 tunnel-cloud 發起請求建立長連線，這樣即使邊緣節點沒有公網IP也能建立邊端和雲端的連線，讓中心和邊緣節點互通，本質就是 tunnel 隧道技術。

2.Edge autonomy（邊緣自治）

這個主要是解決弱網和重啟的。即使有了 Network tunneling，邊緣節點和雲端的網路不穩定是改變不了的事實，動不動斷連還是存在的。邊緣自治功能滿足兩個邊緣場景：
一是中心和邊緣之間斷網，邊緣節點的服務是不受影響的；
二是邊緣節點重啟，重啟之後，邊緣節點上的服務仍然能夠恢復。

這個功能是怎麼實現的？

看看 lite-apiserver 的介紹就明白了。這個元件把邊緣節點請求中心的管理資料全部都快取下來了，利用落盤資料在工作，維持了邊緣服務，即使重啟也能正常提供服務。不過有個問題，邊緣自治的應用也會產生資料，產生的資料如何處理？會不會產生髒資料，影響邊緣服務呢？這個問題留給大家思考。

3.Distributed node health monitoring（分散式健康檢查）

不過我更疑惑了，為什麼中心和邊緣節點斷網了，邊緣節點的服務沒有被驅逐呢？按照Kubernetes的邏輯，邊緣節點NotReady，節點上的服務應該會被驅逐到其他Ready的節點上才對，為什麼沒有產生驅逐呢？難道SuperEdge關閉了邊緣節點的驅逐。經我確認SuperEdge並沒有關閉驅逐，而且在官網開源文件中強調只有在確認邊緣節點異常的情況下才會產生Pod驅逐。

那麼 SuperEdge 是如何確認邊緣節點異常的呢？我後面在 edge-health 的元件介紹中找到了答案。

edge-health 執行在每個邊緣節點上，探測某個區域內邊緣節點的健康性。原理大概是這樣的，在某個區域內，邊緣節點之間是能互相訪問的，然後執行在每個邊緣節點的 edge-health 週期性的互相訪問，確認彼此的健康性，也包括自己。按照大家的探測結果，統計出每個邊緣節點的健康性，要是有XX%節點認為這個節點異常(XX%是healthcheckscoreline 引數配置的，預設100%) ，那麼就把這個結果反饋給中心元件 edge-health admission。

edge-health admission 部署在中心，結合邊緣節點的狀態和 edge-health 的投票結果，決定是否驅逐邊緣服務到其他邊緣節點。通過運用 edge-health，設定好 healthcheckscoreline，只要是邊緣節點不是真正的當機，服務就不會驅逐。一來提高了邊緣服務的可用性，二來很好的擴充套件了 Kubernetes 驅逐在邊緣的運用。

可我仍有個疑問，要是有個邊緣節點確實當機了，服務也被驅逐到了其他邊緣節點，但是後面這個邊緣節點的健康性恢復了，邊緣節點上的服務怎麼處理？

4.Built-in edge orchestration capability

這個功能，個人認為是最具實用性的。也是就由架構圖的application-grid controller和application-grid wrapper 兩個元件聯合提供的ServerGroup能力。

ServiceGroup有什麼用呢？
拿那個連鎖超市有10個營業網點的例子來說，大概提供了兩個功能：

  • 多個營業網點可以同時部署一套特價廣告推銷解決方案；

這個有什麼稀奇的呢？注意是同時，就是說您有一個deployment，給中心叢集提交了一次，就可以同時給10個營業網點，每個網點都部署一套這樣的deployment解決方案。這樣就能做到，管理10個營業網點的特價廣告推銷程式，像管理一個網點的特價廣告推銷程式一樣輕鬆。並且新加入的網點，會自動部署特價廣告推銷解決方案，完全不用管版本、命名的問題了。

  • 多個站點部署的服務有差別，即灰度能力

這個屬於 ServiceGroup 的擴充套件功能，同一套服務在不同地域可能有欄位的差異，或者映象版本不一樣，可以利用DeploymentGrid 的 templatePool 定義不同地域或者站點的模板，利用 Kubernestes Patch 功能，Patch 出基於基礎版本不同執行版本。這樣在某個服務上線前，進行一個地域的灰度，或者定義一套服務在各個站點執行的服務不同，利用 DeploymentGrid 的 templatePool 就可以簡單的進行管理。

  • 同一套解決方案不跨網點訪問；

什麼意思？即使各個網點網路互通，每個網點都部署了特價廣告推銷程式，A網點的程式也不會去訪問B網點的特價廣告推銷服務，只會訪問本網點的服務，實現了流量閉環。

這麼做的好處個人認為有兩個：

  • 實現了網點訪問流量閉環，本網點的服務只能訪問本網點；
  • 促進了邊緣自治，要是一個網點連線不上中心，這個網點完全可以利用自己的服務實現自治，並不會訪問其他網點。

這個功能確實在邊緣的場景中很實用，可以把 application-grid controller和application-grid wrapper 兩個元件獨立的部署在 Kubernetes 叢集中，解決多個網點多套解決方案的管理問題，大家也可以按 ServerGroup的文件 自己體驗體驗。

今天說到這裡，基本把 SuperEdge 的基本功能分析的差不多了，後面有機會在深入剖析SuperEdge內部的原理！

5. 合作和開源

TKE Edge 邊緣容器管理服務的邊緣計算能力核心元件已經開源到 SuperEdge專案，歡迎共建邊緣計算，參與 SuperEdge 開源專案的建設，讓您開發的邊緣能力惠及更多人。以下是SuperEdge開源專案的微信群，環境參與交流討論。

白話邊緣計算解決方案 SuperEdge

SuperEdge版本：

TKE Edge相關文章：

落地案例相關資料：

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

相關文章