## 前言 [superedge](https://github.com/superedge/superedge)是騰訊推出的Kubernetes-native邊緣計算管理框架。相比[openyurt](https://github.com/alibaba/openyurt)以及[kubeedge](https://github.com/kubeedge/kubeedge)，superedge除了具備Kubernetes零侵入以及邊緣自治特性，還支援獨有的分散式健康檢查以及邊緣服務訪問控制等高階特性，極大地消減了雲邊網路不穩定對服務的影響，同時也很大程度上方便了邊緣叢集服務的釋出與治理 ## 特性 - **Kubernetes-native**：superedge在原生Kubernetes基礎上進行了擴充套件，增加了邊緣計算的某幹元件，對Kubernetes完全無侵入；另外通過簡單部署superedge核心元件就可以使原生Kubernetes叢集開啟邊緣計算功能；另外零侵入使得可以在邊緣叢集上部署任何Kubernetes原生工作負載(deployment, statefulset, daemonset, and etc) - **邊緣自治**：superedge提供L3級別的邊緣自治能力，當邊端節點與雲端網路不穩定或者斷連時，邊緣節點依舊可以正常執行，不影響已經部署的邊緣服務 - **分散式健康檢查**：superedge提供邊端分散式健康檢查能力，每個邊緣節點會部署edge-health，同一個邊緣叢集中的邊緣節點會相互進行健康檢查，對節點進行狀態投票。這樣即便雲邊網路存在問題，只要邊緣端節點之間的連線正常，就不會對該節點進行驅逐；另外，分散式健康檢查還支援分組，把叢集節點分成多個組(同一個機房的節點分到同一個組中)，每個組內的節點之間相互檢查，這樣做的好處是避免叢集規模增大後節點之間的資料互動特別大，難以達成一致；同時也適應邊緣節點在網路拓撲上天然就分組的情形。整個設計避免了由於雲邊網路不穩定造成的大量的pod遷移和重建，保證了服務的穩定 - **服務訪問控制**：superedge自研了ServiceGroup實現了基於邊緣計算的服務訪問控制。基於該特性只需構建DeploymentGrid以及ServiceGrid兩種Custom Resource，就可以便捷地在共屬同一個叢集的不同機房或區域中各自部署一組服務，並且使得各個服務間的請求在本機房或本地域內部即可完成(閉環)，避免了服務跨地域訪問。利用該特性可以極大地方便邊緣叢集服務的釋出與治理 - **雲邊隧道**：superedge支援自建隧道(目前支援TCP, HTTP and HTTPS)打通不同網路環境下的雲邊連線問題。實現對無公網IP邊緣節點的統一操作和維護 ## 整體架構  元件功能總結如下： ### 雲端元件 雲端除了邊緣叢集部署的原生Kubernetes master元件(cloud-kube-apiserver，cloud-kube-controller以及cloud-kube-scheduler)外，主要管控元件還包括： - [**tunnel-cloud**](https://github.com/superedge/superedge/blob/main/docs/components/tunnel.md)：負責維持與邊緣節點[**tunnel-edge**](https://github.com/superedge/superedge/blob/main/docs/components/tunnel.md)的網路隧道，目前支援TCP/HTTP/HTTPS協議 - [**application-grid controller**](https://github.com/superedge/superedge/blob/main/docs/components/service-group.md)：服務訪問控制ServiceGroup對應的Kubernetes Controller，負責管理DeploymentGrids以及ServiceGrids CRDs，並由這兩種CR生成對應的Kubernetes deployment以及service，同時自研實現服務拓撲感知，使得服務閉環訪問 - [**edge-admission**](https://github.com/superedge/superedge/blob/main/docs/components/edge-health.md)：通過邊端節點分散式健康檢查的狀態報告決定節點是否健康，並協助cloud-kube-controller執行相關處理動作(打taint) ### 邊緣元件 邊端除了原生Kubernetes worker節點需要部署的kubelet，kube-proxy外，還添加了如下邊緣計算元件： - [**lite-apiserver**](https://github.com/superedge/superedge/blob/main/docs/components/lite-apiserver.md)：邊緣自治的核心元件，是cloud-kube-apiserver的代理服務，快取了邊緣節點元件對apiserver的某些請求，當遇到這些請求而且與cloud-kube-apiserver網路存在問題的時候會直接返回給client端 - [**edge-health**](https://github.com/superedge/superedge/blob/main/docs/components/edge-health.md)：邊端分散式健康檢查服務，負責執行具體的監控和探測操作，並進行投票選舉判斷節點是否健康 - [**tunnel-edge**](https://github.com/superedge/superedge/blob/main/docs/components/tunnel.md)：負責建立與雲端邊緣叢集[**tunnel-cloud**](https://github.com/superedge/superedge/blob/main/docs/components/tunnel.md)的網路隧道，並接受API請求，轉發給邊緣節點元件(kubelet) - **application-grid wrapper**：與application-grid controller結合完成ServiceGrid內的閉環服務訪問(服務拓撲感知) ## 功能概述 ### 應用部署&服務訪問控制 superedge可以支援原生Kubernetes的所有工作負載的應用部署，包括： - deployment - statefulset - daemonset - job - cronjob **而對於邊緣計算應用來說，具備如下獨特點：** - 邊緣計算場景中，往往會在同一個叢集中管理多個邊緣站點，每個邊緣站點內有一個或多個計算節點 - 同時希望在每個站點中都執行一組有業務邏輯聯絡的服務，每個站點內的服務是一套完整的功能，可以為使用者提供服務 - 由於受到網路限制，有業務聯絡的服務之間不希望或者不能跨站點訪問 為了解決上述問題，superedge創新性地構建了ServiceGroup概念，方便使用者便捷地在共屬同一個叢集的不同機房或區域中各自部署一組服務，並且使得各個服務間的請求在本機房或本地域內部即可完成(閉環)，避免了服務跨地域訪問 **ServiceGroup中涉及幾個關鍵概念：**  #### NodeUnit - NodeUnit通常是位於同一邊緣站點內的一個或多個計算資源例項，需要保證同一NodeUnit中的節點內網是通的 - ServiceGroup組中的服務執行在一個NodeUnit之內 - ServiceGroup允許使用者設定服務在一個NodeUnit中執行的pod(belongs to deployment)數量 - ServiceGroup能夠把服務之間的呼叫限制在本NodeUnit內 #### NodeGroup - NodeGroup包含一個或者多個 NodeUnit - 保證在集合中每個NodeUnit上均部署ServiceGroup中的服務 - 當叢集中增加NodeUnit時會自動將ServiceGroup中的服務部署到新增NodeUnit #### ServiceGroup - ServiceGroup包含一個或者多個業務服務 - 適用場景： - 業務需要打包部署； - 需要在每一個NodeUnit中均執行起來並且保證pod數量 - 需要將服務之間的呼叫控制在同一個 NodeUnit 中，不能將流量轉發到其他NodeUnit上 - 注意：ServiceGroup是一種抽象資源概念，一個叢集中可以建立多個ServiceGroup 下面以一個具體例子說明ServiceGroup功能： ```yaml # step1: labels edge nodes $ kubectl get nodes NAME STATUS ROLES AGE VERSION node0 R