一、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版本：
TKE Edge相關文章：
- 【TKE 邊緣容器系列】用 edgeadm 一鍵安裝邊緣 K8s 集群和原生 K8s 集群
- 【TKE 邊緣容器系列】從0到N了解 SuperEdge，這些干貨一定要看！【18篇干貨合集】
- 【TKE 邊緣容器系列】打破內網壁壘，從雲端一次添加成百上千的邊緣節點
- 【TKE 邊緣容器系列】SuperEdge 雲邊隧道新特性：從雲端SSH運維邊緣節點
- 【TKE 邊緣容器系列】一文讀懂 SuperEdge 邊緣容器架構與原理
- 【TKE 邊緣容器系列】一文讀懂 SuperEdge 分布式健康檢查邊端
- 【TKE 邊緣容器系列】一文讀懂 SuperEdge 拓撲算法
- 【TKE 邊緣容器系列】一文讀懂 SuperEdge 雲邊隧道
落地案例相關資料：
- 騰訊WeMake工業互聯網平台的邊緣容器化實踐：打造更高效的工業互聯網
- 完爆！用邊緣容器，竟能秒級實現團隊七八人一周的工作量
- 基於邊緣容器技術的工業互聯網平台建設
- 使用TKE Edge部署EdgeX Foundry
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
