一文讀懂 SuperEdge 邊緣容器架構與原理
前言
superedge是騰訊推出的Kubernetes-native邊緣計算管理框架。相比openyurt以及kubeedge，superedge除了具有Kubernetes零侵入以及邊緣自治特性，還支持獨有的分佈式健康檢查以及邊緣服務訪問控制等高級特性，極大地消減了雲邊網絡不穩定對服務的影響，同時也很大程度上方便了邊緣集羣服務的發佈與治理node
特性
- 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邊緣節點的統一操做和維護
總體架構
組件功能總結以下：git
雲端組件
雲端除了邊緣集羣部署的原生Kubernetes master組件(cloud-kube-apiserver，cloud-kube-controller以及cloud-kube-scheduler)外，主要管控組件還包括：github
- tunnel-cloud：負責維持與邊緣節點tunnel-edge的網絡隧道，目前支持TCP/HTTP/HTTPS協議
- application-grid controller：服務訪問控制ServiceGroup對應的Kubernetes Controller，負責管理DeploymentGrids以及ServiceGrids CRDs，並由這兩種CR生成對應的Kubernetes deployment以及service，同時自研實現服務拓撲感知，使得服務閉環訪問
- edge-admission：經過邊端節點分佈式健康檢查的狀態報告決定節點是否健康，並協助cloud-kube-controller執行相關處理動做(打taint)
邊緣組件
邊端除了原生Kubernetes worker節點須要部署的kubelet，kube-proxy外，還添加了以下邊緣計算組件：api
- lite-apiserver：邊緣自治的核心組件，是cloud-kube-apiserver的代理服務，緩存了邊緣節點組件對apiserver的某些請求，當遇到這些請求並且與cloud-kube-apiserver網絡存在問題的時候會直接返回給client端
- edge-health：邊端分佈式健康檢查服務，負責執行具體的監控和探測操做，並進行投票選舉判斷節點是否健康
- tunnel-edge：負責創建與雲端邊緣集羣tunnel-cloud的網絡隧道，並接受API請求，轉發給邊緣節點組件(kubelet)
- application-grid wrapper：與application-grid controller結合完成ServiceGrid內的閉環服務訪問(服務拓撲感知)
功能概述
應用部署&服務訪問控制
superedge能夠支持原生Kubernetes的全部工做負載的應用部署，包括：緩存
- deployment
- statefulset
- daemonset
- job
- cronjob
而對於邊緣計算應用來講，具有以下獨特色：網絡
- 邊緣計算場景中，每每會在同一個集羣中管理多個邊緣站點，每一個邊緣站點內有一個或多個計算節點
- 同時但願在每一個站點中都運行一組有業務邏輯聯繫的服務，每一個站點內的服務是一套完整的功能，能夠爲用戶提供服務
- 因爲受到網絡限制，有業務聯繫的服務之間不但願或者不能跨站點訪問
爲了解決上述問題，superedge創新性地構建了ServiceGroup概念，方便用戶便捷地在共屬同一個集羣的不一樣機房或區域中各自部署一組服務，而且使得各個服務間的請求在本機房或本地域內部便可完成(閉環)，避免了服務跨地域訪問架構
ServiceGroup中涉及幾個關鍵概念：app
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功能：負載均衡
# step1: labels edge nodes
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
node0 Ready <none> 16d v1.16.7
node1 Ready <none> 16d v1.16.7
node2 Ready <none> 16d v1.16.7
# nodeunit1(nodegroup and servicegroup zone1)
$ kubectl --kubeconfig config label nodes node0 zone1=nodeunit1
# nodeunit2(nodegroup and servicegroup zone1)
$ kubectl --kubeconfig config label nodes node1 zone1=nodeunit2
$ kubectl --kubeconfig config label nodes node2 zone1=nodeunit2
# step2: deploy echo DeploymentGrid
$ cat <<EOF | kubectl --kubeconfig config apply -f -
apiVersion: superedge.io/v1
kind: DeploymentGrid
metadata:
name: deploymentgrid-demo
namespace: default
spec:
gridUniqKey: zone1
template:
replicas: 2
selector:
matchLabels:
appGrid: echo
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
appGrid: echo
spec:
containers:
- image: gcr.io/kubernetes-e2e-test-images/echoserver:2.2
name: echo
ports:
- containerPort: 8080
protocol: TCP
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
resources: {}
EOF
deploymentgrid.superedge.io/deploymentgrid-demo created
# note that there are two deployments generated and deployed into both nodeunit1 and nodeunit2
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
deploymentgrid-demo-nodeunit1 2/2 2 2 5m50s
deploymentgrid-demo-nodeunit2 2/2 2 2 5m50s
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploymentgrid-demo-nodeunit1-65bbb7c6bb-6lcmt 1/1 Running 0 5m34s 172.16.0.16 node0 <none> <none>
deploymentgrid-demo-nodeunit1-65bbb7c6bb-hvmlg 1/1 Running 0 6m10s 172.16.0.15 node0 <none> <none>
deploymentgrid-demo-nodeunit2-56dd647d7-fh2bm 1/1 Running 0 5m34s 172.16.1.12 node1 <none> <none>
deploymentgrid-demo-nodeunit2-56dd647d7-gb2j8 1/1 Running 0 6m10s 172.16.2.9 node2 <none> <none>
# step3: deploy echo ServiceGrid
$ cat <<EOF | kubectl --kubeconfig config apply -f -
apiVersion: superedge.io/v1
kind: ServiceGrid
metadata:
name: servicegrid-demo
namespace: default
spec:
gridUniqKey: zone1
template:
selector:
appGrid: echo
ports:
- protocol: TCP
port: 80
targetPort: 8080
EOF
servicegrid.superedge.io/servicegrid-demo created
# note that there is only one relevant service generated
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 192.168.0.1 <none> 443/TCP 16d
servicegrid-demo-svc ClusterIP 192.168.6.139 <none> 80/TCP 10m
# step4: access servicegrid-demo-svc(service topology and closed-looped)
# execute on onde0
$ curl 192.168.6.139|grep "node name"
node name: node0
# execute on node1 and node2
$ curl 192.168.6.139|grep "node name"
node name: node2
$ curl 192.168.6.139|grep "node name"
node name: node1
經過上面的例子總結ServiceGroup以下：框架
- NodeUnit和NodeGroup以及ServiceGroup都是一種概念，具體來講實際使用中對應關係以下：
- NodeUnit是具備相同label key以及value的一組邊緣節點
- NodeGroup是具備相同label key的一組NodeUnit(不一樣value)
- ServiceGroup具體由兩種CRD構成：DepolymentGrid以及ServiceGrid，具有相同的gridUniqKey
- gridUniqKey值與NodeGroup的label key對應，也即ServiceGroup是與NodeGroup一一對應，而NodeGroup對應多個NodeUnit，同時NodeGroup中的每個NodeUnit都會部署ServiceGroup對應deployment，這些deployment(deploymentgridName-NodeUnit命名)經過nodeSelector親和性固定某個NodeUnit上，並經過服務拓撲感知限制在該NodeUnit內訪問
分佈式健康檢查
邊緣計算場景下，邊緣節點與雲端的網絡環境十分複雜，鏈接並不可靠，在原生Kubernetes集羣中，會形成apiserver和節點鏈接的中斷，節點狀態的異常，最終致使pod的驅逐和endpoint的缺失，形成服務的中斷和波動，具體來講原生Kubernetes處理以下：
- 失聯的節點被置爲ConditionUnknown狀態，並被添加NoSchedule和NoExecute的taints
- 失聯的節點上的pod被驅逐，並在其餘節點上進行重建
- 失聯的節點上的pod從Service的Endpoint列表中移除
所以，邊緣計算場景僅僅依賴邊端和apiserver的鏈接狀況是不足以判斷節點是否異常的，會由於網絡的不可靠形成誤判，影響正常服務。而相較於雲端和邊緣端的鏈接，顯然邊端節點之間的鏈接更爲穩定，具備必定的參考價值，所以superedge提出了邊緣分佈式健康檢查機制。該機制中節點狀態斷定除了要考慮apiserver的因素外，還引入了節點的評估因素，進而對節點進行更爲全面的狀態判斷。經過這個功能，可以避免因爲雲邊網絡不可靠形成的大量的pod遷移和重建，保證服務的穩定
具體來講，主要經過以下三個層面加強節點狀態判斷的準確性：
- 每一個節點按期探測其餘節點健康狀態
- 集羣內全部節點按期投票決定各節點的狀態
- 雲端和邊端節點共同決定節點狀態
而分佈式健康檢查最終的判斷處理以下：
| 節點最終狀態 | 雲端斷定正常 | 雲端斷定異常 |
|---|---|---|
| 節點內部斷定正常 | 正常 | 再也不調度新的pod到該節點(NoSchedule taint) |
| 節點內部斷定異常 | 正常 | 驅逐存量pod；從Endpoint列表摘除pod；再也不調度新的pod到該節點 |
邊緣自治
對於邊緣計算的用戶來講，他們除了想要享受Kubernetes自身帶來的管理運維的便捷以外，同時也想具有弱網環境下的容災能力，具體來講，以下：
- 節點即便和master失聯，節點上的業務能繼續運行
- 保證若是業務容器異常退出或者掛掉，kubelet 能繼續拉起
- 還要保證節點重啓後，業務能繼續從新被拉起來
- 用戶在廠房內部署的是微服務，須要保證節點重啓後，同一個廠房內的微服務能夠訪問
而對於標準的Kubernentes，若是節點斷網失聯而且發生異常重啓的行爲後，現象以下：
- 失聯的節點狀態置爲ConditionUnknown狀態
- 失聯的節點上的業務進程異常退出後，容器能夠被拉起
- 失聯的節點上的 Pod IP 從 Endpoint 列表中摘除
- 失聯的節點發生重啓後，容器所有消失不會被拉起
superedge自研的邊緣自治就是爲了解決上述問題的，具體來講邊緣自治能達到以下效果：
- 節點會被置爲ConditionUnknown狀態，可是服務依舊可用(pod不會被驅逐以及從endpoint列表中剔除)
- 多節點斷網狀況下，Pod 業務正常運行，微服務能力正常提供
- 多節點斷網狀況下並重啓後，Pod 會被從新拉起並正常運行
- 多節點斷網狀況下並重啓後，全部的微服務能夠被正常訪問
其中，對於前兩點來講能夠經過上述介紹的分佈式健康檢查機制來實現，然後續兩點能夠經過lite-apiserver，網絡快照以及DNS解決方案實現，以下：
lite-apiserver機制
superedge經過在邊端加了一層鏡像lite-apiserver組件，使得全部邊端節點對於雲端kube-apiserver的請求，都會指向lite-apiserver組件：
而lite-apiserver其實就是個代理，緩存了一些kube-apiserver請求，當遇到這些請求並且與apiserver不通的時候就直接返回給client：
總的來講：對於邊緣節點的組件，lite-apiserver提供的功能就是kube-apiserver，可是一方面lite-apiserver只對本節點有效，另外一方面資源佔用不多。在網絡通暢的狀況下，lite-apiserver組件對於節點組件來講是透明的；而當網絡異常狀況，lite-apiserver組件會把本節點須要的數據返回給節點上組件，保證節點組件不會受網絡異常狀況影響
網絡快照
經過lite-apiserver能夠實現邊緣節點斷網狀況下重啓後pod能夠被正常拉起，可是根據原生Kubernetes原理，拉起後的pod ip會發生改變，這在某些狀況下是不能容許的，爲此superedge設計了網絡快照機制保障邊緣節點重啓，pod拉起後ip保存不變。具體來講就是將節點上組件的網絡信息按期快照，並在節點重啓後進行恢復
本地DNS解決方案
經過lite-apiserver以及網絡快照機制能夠保障邊緣節點斷網狀況下重啓後，Pod會被從新拉起並正常運行，同時微服務也運行正常。而服務之間相互訪問就會涉及一個域名解析的問題：一般來講在集羣內部咱們使用coredns來作域名解析，且通常部署爲Deployment形式，可是在邊緣計算狀況下，節點之間多是不在一個局域網，極可能是跨可用區的，這個時候coredns服務就可能訪問不通。爲了保障dns訪問始終正常，superedge設計了專門的本地dns解決方案，以下：
本地dns採用DaemonSet方式部署coredns，保證每一個節點都有可用的coredns，同時修改每一個節點上kubelet的啓動參數--cluster-dns，將其指向本機私有IP(每一個節點都相同)。這樣就保證了即便在斷網的狀況下也能進行域名解析。
總的來講，superedge是以lite-apiserver機制爲基礎，並結合分佈式健康檢查機制、網絡快照以及本地coredns，保證了邊緣容器集羣在弱網環境下的網絡可靠性。另外隨着邊緣自治的級別越高，所須要的組件會愈來愈多
雲邊隧道
最後介紹一下superedge的雲邊隧道，雲邊隧道主要用於：代理雲端訪問邊緣節點組件的請求，解決雲端沒法直接訪問邊緣節點的問題（邊緣節點沒有暴露在公網中）
架構圖以下所示：
實現原理爲：
- 邊緣節點上tunnel-edge主動鏈接雲端tunnel-cloud service，tunnel-cloud service根據負載均衡策略將請求轉到tunnel-cloud的具體pod上
- tunnel-edge與tunnel-cloud創建grpc鏈接後，tunnel-cloud會把自身的podIp和tunnel-edge所在節點的nodeName的映射寫入DNS(tunnel dns)。grpc鏈接斷開以後，tunnel-cloud會刪除相關podIp和節點名的映射
而整個請求的代理轉發流程以下：
- apiserver或者其它雲端的應用訪問邊緣節點上的kubelet或者其它應用時，tunnel-dns經過DNS劫持(將host中的節點名解析爲tunnel-cloud的podIp)把請求轉發到tunnel-cloud的pod上
- tunnel-cloud根據節點名把請求信息轉發到節點名對應的與tunnel-edge創建的grpc鏈接上
- tunnel-edge根據接收的請求信息請求邊緣節點上的應用
總結
本文依次介紹了開源邊緣計算框架SuperEdge的特性，總體架構以及主要功能和原理。其中分佈式健康檢查以及邊緣集羣服務訪問控制ServiceGroup是SuperEdge獨有的特性功能。分佈式健康檢查很大程度避免了因爲雲邊網絡不可靠形成的大量pod遷移和重建，保證了服務的穩定；而ServiceGroup則極大地方便了用戶在共屬同一個集羣的不一樣機房或區域中各自部署一組服務，而且使得各個服務間的請求在本機房或本地域內部便可完成(閉環)，避免了服務跨地域訪問。除此以外還有邊緣自治以及雲邊隧道等功能。
總體來講，SuperEdge採用無侵入的方式構建邊緣集羣，在原有Kubernetes組件保留不變的基礎上新增了一些組件完成邊緣計算的功能，既保留了Kubernetes強大的編排系統，同時也具有完善的邊緣計算能力。
- 1. 一文讀懂 SuperEdge 邊緣容器架構與原理
- 2. 一文讀懂 SuperEdge 雲邊隧道
- 3. 一文讀懂 SuperEdge 分佈式健康檢查 (邊端)
- 4. HDFS原理 | 一文讀懂HDFS架構與設計
- 5. 一文讀懂JSONP原理
- 6. 邊緣計算與邊緣容器的起源
- 7. 【從0到1學習邊緣容器系列1】之 邊緣計算與邊緣容器的起源
- 8. 一文看懂Docker容器技術與原理
- 9. 從概念到現狀，一文讀懂邊緣計算
- 10. 一文帶你讀懂邊緣計算是什麼
- 更多相關文章...
- • BASE原理與最終一致性 - NoSQL教程
- • Docker 架構 - Docker教程
- • Docker容器實戰(六) - 容器的隔離與限制
- • Docker容器實戰(七) - 容器眼光下的文件系統
-
每一个你不满意的现在，都有一个你没有努力的曾经。