[[429682]]

本文轉(zhuǎn)載自微信公眾號「運(yùn)維開發(fā)故事」，作者Double_冬&華子。轉(zhuǎn)載本文請聯(lián)系運(yùn)維開發(fā)故事公眾號。

1.背景

邊緣計(jì)算平臺，旨在將邊緣端靠近數(shù)據(jù)源的計(jì)算單元納入到中心云，實(shí)現(xiàn)集中管理，將云服務(wù)部署其上，及時響應(yīng)終端請求。然而，成千上萬的邊緣節(jié)點(diǎn)散布于各地，例如銀行網(wǎng)點(diǎn)、車載節(jié)點(diǎn)、加油站等基于一些邊緣設(shè)備管理場景，服務(wù)器分散在不同城市，無法統(tǒng)一管理，為了優(yōu)化集群部署以及統(tǒng)一管理，特探索邊緣計(jì)算場景方案。

2.邊緣計(jì)算挑戰(zhàn)

邊緣計(jì)算框架在 Kubernetes 系統(tǒng)里，需要解決下面的問題:

• 網(wǎng)絡(luò)斷連時，節(jié)點(diǎn)異常或重啟時，內(nèi)存數(shù)據(jù)丟失，業(yè)務(wù)容器無法恢復(fù);
• 網(wǎng)絡(luò)長時間斷連，云端控制器對業(yè)務(wù)容器進(jìn)行驅(qū)逐;
• 長時間斷連后網(wǎng)絡(luò)恢復(fù)時，邊緣和云端數(shù)據(jù)的一致性保障。
• 網(wǎng)絡(luò)不穩(wěn)定下，K8S client ListWatch機(jī)制下為保證數(shù)據(jù)一致性，在每次重連時都需要同步ReList一次，較大規(guī)模的邊緣節(jié)點(diǎn)數(shù)量加以較不穩(wěn)定的網(wǎng)絡(luò)，將造成巨大的網(wǎng)絡(luò)開銷和API Server的cpu負(fù)擔(dān)，特別是不可靠的遠(yuǎn)距離跨公網(wǎng)場景。

3.方案選型

• KubeEdge
• Superedge
• Openyurt
• k3s

3.1. KubeEdge

3.1.1 架構(gòu)簡介

KubeEdge是首個基于Kubernetes擴(kuò)展的，提供云邊協(xié)同能力的開放式智能邊緣平臺，也是CNCF在智能邊緣領(lǐng)域的首個正式項(xiàng)目。KubeEdge重點(diǎn)要解決的問題是：

• 云邊協(xié)同
• 資源異構(gòu)
• 大規(guī)模
• 輕量化
• 一致的設(shè)備管理和接入體驗(yàn)

KubeEdge的架構(gòu)如下所示：

KubeEdge架構(gòu)上清晰地分為三層，分別是：云端、邊緣和設(shè)備層。

云端

KubeEdge的云端進(jìn)程包含以下2個組件：

• cloudhub部署在云端，接收edgehub同步到云端的信息;
• edgecontroller部署在云端，用于控制Kubernetes API Server與邊緣的節(jié)點(diǎn)、應(yīng)用和配置的狀態(tài)同步。

Kubernetes maser運(yùn)行在云端，用戶可以直接通過kubectl命令行在云端管理邊緣節(jié)點(diǎn)、設(shè)備和應(yīng)用，使用習(xí)慣與Kubernetes原生的完全一致，無需重新適應(yīng)。

邊緣

KubeEdge的邊緣進(jìn)程包含以下5個組件：

• edged是個重新開發(fā)的輕量化Kubelet，實(shí)現(xiàn)Pod，Volume，Node等Kubernetes資源對象的生命周期管理;
• metamanager負(fù)責(zé)本地元數(shù)據(jù)的持久化，是邊緣節(jié)點(diǎn)自治能力的關(guān)鍵;
• edgehub是多路復(fù)用的消息通道，提供可靠和高效的云邊信息同步;
• devicetwin用于抽象物理設(shè)備并在云端生成一個設(shè)備狀態(tài)的映射;
• eventbus訂閱來自于MQTT Broker的設(shè)備數(shù)據(jù)。

網(wǎng)絡(luò)

KubeEdge 邊云網(wǎng)絡(luò)訪問依賴EdgeMesh：

云端是標(biāo)準(zhǔn)的Kubernetes集群，可以使用任意CNI網(wǎng)絡(luò)插件，比如Flannel、Calico;可以部署任意Kubernetes原生組件，比如Kubelet、KubeProxy;同時云端部署KubeEdge云上組件CloudCore，邊緣節(jié)點(diǎn)上運(yùn)行KubeEdge邊緣組件EdgeCore，完成邊緣節(jié)點(diǎn)向云上集群的注冊。

EdgeMesh包含兩個組件：EdgeMesh-Server和每個節(jié)點(diǎn)上的EdgeMesh-Agent。

EdgeMesh-Server工作原理：

• EdgeMesh-Server運(yùn)行在云上節(jié)點(diǎn)，具有一個公網(wǎng)IP，監(jiān)聽來自EdgeMesh-Agent的連接請求，并協(xié)助EdgeMesh-Agent之間完成UDP打洞，建立P2P連接;
• 在EdgeMesh-Agent之間打洞失敗的情況下，負(fù)責(zé)中繼EdgeMesh-Agent之間的流量，保證100%的流量中轉(zhuǎn)成功率。

EdgeMesh-Agent工作原理：

• EdgeMesh-Agent的DNS模塊，是內(nèi)置的輕量級DNS Server，完成Service域名到ClusterIP的轉(zhuǎn)換。
• EdgeMesh-Agent的Proxy模塊，負(fù)責(zé)集群的Service服務(wù)發(fā)現(xiàn)與ClusterIP的流量劫持。
• EdgeMesh-Agent的Tunnel模塊，在啟動時，會建立與EdgeMesh-Server的長連接，在兩個邊緣節(jié)點(diǎn)上的應(yīng)用需要通信時，會通過EdgeMesh-Server進(jìn)行UDP打洞，嘗試建立P2P連接，一旦連接建立成功，后續(xù)兩個邊緣節(jié)點(diǎn)上的流量不需要經(jīng)過EdgeMesh-Server的中轉(zhuǎn)，進(jìn)而降低網(wǎng)絡(luò)時延。

3.1.2 實(shí)踐

根據(jù)官方文檔《Deploying using Keadm | KubeEdge》進(jìn)行部署測試

類型	ip	系統(tǒng)版本	架構(gòu)	集群版本	端口開放
云端	47.108.201.47	Ubuntu 18.04.5 LTS	amd64	k8s-v1.19.8 + kubeedge-v1.8.1	開放端口 10000-10005
邊緣	172.31.0.153	Ubuntu 18.04.5 LTS	arm64	kubeedge-v1.8.1

實(shí)踐結(jié)論：

根據(jù)官方文檔部署，邊緣節(jié)點(diǎn)可以正常加入集群，可以正常部署服務(wù)至邊緣節(jié)點(diǎn)，部署edgemesh測試服務(wù)訪問，邊緣可以通過svc訪問云端服務(wù)，但是云端無法通過svc訪問邊緣，邊緣節(jié)點(diǎn)服務(wù)之間無法通過svc進(jìn)行訪問。

3.2. Superedge

3.2.1 架構(gòu)簡介

SuperEdge是騰訊推出的Kubernetes-native邊緣計(jì)算管理框架。相比openyurt以及kubeedge，SuperEdge除了具備Kubernetes零侵入以及邊緣自治特性，還支持獨(dú)有的分布式健康檢查以及邊緣服務(wù)訪問控制等高級特性，極大地消減了云邊網(wǎng)絡(luò)不穩(wěn)定對服務(wù)的影響。

整體架構(gòu)：

組件功能總結(jié)如下：

云端組件

云端除了邊緣集群部署的原生Kubernetes master組件(cloud-kube-APIServer，cloud-kube-controller以及cloud-kube-scheduler)外，主要管控組件還包括：

• tunnel-cloud：負(fù)責(zé)維持與邊緣節(jié)點(diǎn)tunnel-edge的網(wǎng)絡(luò)隧道，目前支持TCP/HTTP/HTTPS協(xié)議。
• application-grid controller：服務(wù)訪問控制ServiceGroup對應(yīng)的Kubernetes Controller，負(fù)責(zé)管理DeploymentGrids以及ServiceGrids CRDs，并由這兩種CR生成對應(yīng)的Kubernetes deployment以及service，同時自研實(shí)現(xiàn)服務(wù)拓?fù)涓兄?，使得服?wù)閉環(huán)訪問。
• edge-admission：通過邊端節(jié)點(diǎn)分布式健康檢查的狀態(tài)報(bào)告決定節(jié)點(diǎn)是否健康，并協(xié)助cloud-kube-controller執(zhí)行相關(guān)處理動作(打taint)。

邊緣組件

邊端除了原生Kubernetes worker節(jié)點(diǎn)需要部署的kubelet，kube-proxy外，還添加了如下邊緣計(jì)算組件：

• lite-apiserver：邊緣自治的核心組件，是cloud-kube-apiserver的代理服務(wù)，緩存了邊緣節(jié)點(diǎn)組件對APIServer的某些請求，當(dāng)遇到這些請求而且與cloud-kube-apiserver網(wǎng)絡(luò)存在問題的時候會直接返回給client端。
• edge-health：邊端分布式健康檢查服務(wù)，負(fù)責(zé)執(zhí)行具體的監(jiān)控和探測操作，并進(jìn)行投票選舉判斷節(jié)點(diǎn)是否健康。
• tunnel-edge：負(fù)責(zé)建立與云端邊緣集群tunnel-cloud的網(wǎng)絡(luò)隧道，并接受API請求，轉(zhuǎn)發(fā)給邊緣節(jié)點(diǎn)組件(kubelet)。
• application-grid wrapper：與application-grid controller結(jié)合完成ServiceGrid內(nèi)的閉環(huán)服務(wù)訪問(服務(wù)拓?fù)涓兄?。

3.2.2 實(shí)踐

根據(jù)官方文檔《superedge/README_CN.md at main · superedge/superedge (github.com)》部署測試

類型	ip	系統(tǒng)版本	架構(gòu)	集群版本	端口開放
云端	47.108.201.47	Ubuntu 18.04.5 LTS	amd64	k8s-v1.19.8 + kubeedge-v1.8.1	開放端口 10000-10005
邊緣	172.31.0.153	Ubuntu 18.04.5 LTS	arm64	kubeedge-v1.8.1

實(shí)踐結(jié)論：

根據(jù)官方文檔部署，邊緣節(jié)點(diǎn)可以正常加入集群，但是無法部署服務(wù)至邊緣節(jié)點(diǎn)，提了issue未回復(fù)，其他測試未再進(jìn)行

3.3. Openyurt

3.3.1. 架構(gòu)簡介

OpenYurt的架構(gòu)設(shè)計(jì)比較簡潔，采用的是無侵入式對Kubernetes進(jìn)行增強(qiáng)。在云端(K8s Master)上增加Yurt Controller Manager, Yurt App Manager以及Tunnel Server組件。而在邊緣端(K8s Worker)上增加了YurtHub和Tunnel Agent組件。從架構(gòu)上看主要增加了如下能力來適配邊緣場景：

• YurtHub: 代理各個邊緣組件到K8s Master的通信請求，同時把請求返回的元數(shù)據(jù)持久化在節(jié)點(diǎn)磁盤。當(dāng)云邊網(wǎng)絡(luò)不穩(wěn)定時，則利用本地磁盤數(shù)據(jù)來用于邊緣業(yè)務(wù)的生命周期管控。同時云端的Yurt Controller Manager會管控邊緣業(yè)務(wù)Pod的驅(qū)逐策略。
• Tunnel Server/Tunnel Agent: 每個邊緣節(jié)點(diǎn)上的Tunnel Agent將主動與云端Tunnel Server建立雙向認(rèn)證的加密的gRPC連接，同時云端將通過此連接訪問到邊緣節(jié)點(diǎn)及其資源。
• Yurt App Manager：引入的兩個CRD資源: NodePool 和 UnitedDeployment. 前者為位于同一區(qū)域的節(jié)點(diǎn)提供批量管理方法。后者定義了一種新的邊緣應(yīng)用模型以節(jié)點(diǎn)池維度來管理工作負(fù)載。

3.3.2 實(shí)踐

只根據(jù)官方文檔了解其架構(gòu)，未進(jìn)行部署測試。

3.4. K3s

3.4.1 架構(gòu)簡介

K3S是CNCF官方認(rèn)證的Kubernetes發(fā)行版，開源時間較KubeEdge稍晚。K3S專為在資源有限的環(huán)境中運(yùn)行Kubernetes的研發(fā)和運(yùn)維人員設(shè)計(jì)，目的是為了在x86、ARM64和ARMv7D架構(gòu)的邊緣節(jié)點(diǎn)上運(yùn)行小型的Kubernetes集群。K3S的整體架構(gòu)如下所示：

事實(shí)上，K3S就是基于一個特定版本Kubernetes(例如：1.13)直接做了代碼修改。K3S分Server和Agent，Server就是Kubernetes管理面組件 + SQLite和Tunnel Proxy，Agent即Kubernetes的數(shù)據(jù)面 + Tunnel Proxy。

為了減少運(yùn)行Kubernetes所需的資源，K3S對原生Kubernetes代碼做了以下幾個方面的修改：

• 刪除舊的、非必須的代碼。K3S不包括任何非默認(rèn)的、Alpha或者過時的Kubernetes功能。除此之外，K3S還刪除了所有非默認(rèn)的Admission Controller，in-tree的cloud provider和存儲插件;
• 整合打包進(jìn)程。為了節(jié)省內(nèi)存，K3S將原本以多進(jìn)程方式運(yùn)行的Kubernetes管理面和數(shù)據(jù)面的多個進(jìn)程分別合并成一個來運(yùn)行;
• 使用containderd替換Docker，顯著減少運(yùn)行時占用空間;
• 引入SQLite代替etcd作為管理面數(shù)據(jù)存儲，并用SQLite實(shí)現(xiàn)了list/watch接口，即Tunnel Proxy;
• 加了一個簡單的安裝程序。K3S的所有組件(包括Server和Agent)都運(yùn)行在邊緣，因此不涉及云邊協(xié)同。如果K3S要落到生產(chǎn)，在K3S之上應(yīng)該還有一個集群管理方案負(fù)責(zé)跨集群的應(yīng)用管理、監(jiān)控、告警、日志、安全和策略等。

3.4.2 實(shí)踐

官方文檔：https://docs.rancher.cn/docs/k3s/installation/install-options/_index

運(yùn)維架構(gòu)圖

節(jié)點(diǎn)信息

k3s server—192.168.15.252

k3s agent—192.168.15.251

注意點(diǎn)：server一定要有免密登錄agent權(quán)限!!!

總體思路

K3S部署Kubernetes集群，創(chuàng)建集群的https證書，Helm部署rancher，通過rancher的UI界面手動導(dǎo)入Kubernetes集群，使用Kubernetes集群。

使用腳本安裝 Docker

安裝GPG證書 
curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add - 
#寫入軟件源信息 
sudo add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable" 
sudo apt-get -y update 
#安裝Docker-CE 
sudo apt-get -y install docker-ce 

Kubernetes部署

在rancher中文文檔中推薦了一種更輕量的Kubernetes集群搭建方式:K3S，安裝過程非常簡單，只需要服務(wù)器能夠訪問互聯(lián)網(wǎng)，執(zhí)行相應(yīng)的命令就可以了。

k3s server主機(jī)執(zhí)行命令，執(zhí)行完成后獲取master主機(jī)的K3S_TOKEN用于agent節(jié)點(diǎn)安裝(默認(rèn)路徑:/var/lib/rancher/k3s/server/node-token)。

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn  INSTALL_K3S_EXEC="--docker" sh -s - server 

k3s agent主機(jī)執(zhí)行命令，加入K3S集群。

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC="--docker" K3S_URL=https://192.168.15.252:6443 K3S_TOKEN=K10bb35019b1669197e06f97b6c14bb3b3c7c7076cd20afe1f550d6793d02b9eed8::server:9599c8b3ffbbd38b7721207183cd6a62 sh - 

http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh是國內(nèi)的加速地址，可以正常執(zhí)行。

執(zhí)行完畢后，在server服務(wù)器上驗(yàn)證是否安裝K3S集群成功。

4. 對比

上述四種開源方案，其中KubeEdge、SuperEdge、OpenYurt，遵循如下部署模型：

是一種完全去中心化的部署模式，管理面部署在云端，邊緣節(jié)點(diǎn)無需太多資源就能運(yùn)行Kubernetes的agent，云邊通過消息協(xié)同。從Kubernetes的角度看，邊緣節(jié)點(diǎn) + 云端才是一個完整的Kubernetes集群。這種部署模型能夠同時滿足“設(shè)備邊緣”和“基礎(chǔ)設(shè)施邊緣”場景的部署要求。

所以先基于這三種方案對比如下：

項(xiàng)目	華為KubeEdge	阿里OpenYurt	騰訊SuperEdge
是否CNCF項(xiàng)目	是(孵化項(xiàng)目)	是(沙箱項(xiàng)目)	否
開源時間	2018.11	2020.5	2020.12
侵入式修改Kubernetes	是	否	否
和Kubernetes無縫轉(zhuǎn)換	無	有	未知
邊緣自治能力	有(無邊緣健康檢測能力)	有(無邊緣健康檢測能力)	有(安全及流量消耗待優(yōu)化)
邊緣單元化	不支持	支持	支持(只支持Deployment)
是否輕量化	是(節(jié)點(diǎn)維度待確認(rèn))	否	否
原生運(yùn)維監(jiān)控能力	部分支持	全量支持	全量支持(證書管理及連接管理待優(yōu)化)
云原生生態(tài)兼容	部分兼容	完整兼容	完整兼容
系統(tǒng)穩(wěn)定性挑戰(zhàn)	大(接入設(shè)備數(shù)量過多)	大(大規(guī)模節(jié)點(diǎn)并且云邊長時間斷網(wǎng)恢復(fù))	大(大規(guī)模節(jié)點(diǎn)并且云邊長時間斷網(wǎng)恢復(fù))
設(shè)備管理能力	有(有管控流量和業(yè)務(wù)流量耦合問題)	無	無

初步結(jié)論：

對比這三種方案，KubeEdge和OpenYurt/SuperEdge的架構(gòu)設(shè)計(jì)差異比較大，相比而言O(shè)penYurt/SuperEdge的架構(gòu)設(shè)計(jì)更優(yōu)雅一些。而OpenYurt和SuperEdge架構(gòu)設(shè)計(jì)相似，SuperEdge的開源時間晚于OpenYurt，項(xiàng)目成熟度稍差。但是根據(jù)業(yè)界已經(jīng)落地的生產(chǎn)方案，KubeEdge使用度及成熟度較高，同時OpenYurt/SuperEdge 開源時間較晚，還未進(jìn)入CNCF孵化項(xiàng)目，同時結(jié)合實(shí)踐過程中的測試情況，考慮KubeEdge。

接下來，再針對KubeEdge和K3s進(jìn)行對比：

K3S的部署模型如下所示：

K3S會在邊緣運(yùn)行完整的Kubernetes集群，這意味著K3S并不是一個去中心化的部署模型，每個邊緣都需要額外部署Kubernetes管理面，因此該部署模型只適合資源充足的“基礎(chǔ)設(shè)施邊緣”場景，并不適用于資源較少的“設(shè)備邊緣”的場景;同時集群之間網(wǎng)絡(luò)需要打通;為了管理邊緣Kubernetes集群還需要在上面疊加一層多集群管理組件。

相關(guān)對比如下：

項(xiàng)目	KubeEdge	K3s
是否CNCF項(xiàng)目	是	是
開源時間	2018.11	2019.2
架構(gòu)	云管邊	邊緣托管
邊緣自治能力	支持	暫無
云邊協(xié)同	支持	依賴多集群管理
原生運(yùn)維監(jiān)控能力	部分支持	支持
與原生K8s關(guān)系	k8s+addons	裁剪k8s
iot設(shè)備管理能力	支持	octopus

5. 總體結(jié)論

KubeEdge的一大亮點(diǎn)是云邊協(xié)同，KubeEdge 通過 Kubernetes 標(biāo)準(zhǔn) API 在云端管理邊緣節(jié)點(diǎn)、設(shè)備和工作負(fù)載的增刪改查。邊緣節(jié)點(diǎn)的系統(tǒng)升級和應(yīng)用程序更新都可以直接從云端下發(fā)，提升邊緣的運(yùn)維效率。但是云邊協(xié)同訪問需要借助EdgeMesh組件，其中包含server端和agent端，劫持了dns訪問流量，進(jìn)行轉(zhuǎn)發(fā)，增加了網(wǎng)絡(luò)復(fù)雜度，同時實(shí)際測試過程中發(fā)現(xiàn)邊緣端服務(wù)之間無法通過svc進(jìn)行訪問。而k3s雖然不涉及到云邊協(xié)同能力，但是針對加油站業(yè)務(wù)場景，可以將業(yè)務(wù)進(jìn)行拆分為中心端和邊緣端，中心側(cè)業(yè)務(wù)復(fù)雜下發(fā)解碼任務(wù)等，邊緣側(cè)只負(fù)責(zé)解碼分析產(chǎn)生事件，并進(jìn)行展示，也可以做到另一個層面的云邊協(xié)同，相比于KubeEdge云邊協(xié)同的訪問方案來講，不用部署額外組件，減少了網(wǎng)絡(luò)復(fù)雜度，出問題也好排查。

KubeEdge的另一大亮點(diǎn)是邊緣節(jié)點(diǎn)離線自治，KubeEdge 通過消息總線和元數(shù)據(jù)本地存儲實(shí)現(xiàn)了節(jié)ku點(diǎn)的離線自治。用戶期望的控制面配置和設(shè)備實(shí)時狀態(tài)更新都通過消息同步到本地存儲，這樣節(jié)點(diǎn)在離線情況下即使重啟也不會丟失管理元數(shù)據(jù)，并保持對本節(jié)點(diǎn)設(shè)備和應(yīng)用的管理能力。而K3s在邊緣節(jié)點(diǎn)是一套完整集群，所以及時和中心端網(wǎng)絡(luò)斷聯(lián)，也同樣并不影響當(dāng)前業(yè)務(wù)的運(yùn)行。

從輕量化的角度來看，k3s二進(jìn)制文件大小50M，edgecore80M。資源消耗，由于k3s在邊緣端是一套完整集群，所以資源消耗對比KubeEdge要高，但是針對加油站場景，邊緣服務(wù)器內(nèi)存配置較高，所以這一塊也能接受。

從運(yùn)維角度來看，k3s維護(hù)跟原生k8s類似，不增加額外組件，唯一難點(diǎn)是多集群管理，這一塊可以調(diào)研rancher及其他多集群管理方案，同時golive2.0也支持一個部署同時部署至多集群。而KubeEdge如果要接入多個加油站，需要namespace隔離，部署涉及到加污點(diǎn)，容忍，同時需要支持一個部署包同時部署多個namespace，而且KubeEdge為了云邊訪問，額外加入EdgeMesh組件，轉(zhuǎn)發(fā)流量，增加了網(wǎng)絡(luò)復(fù)雜度，遇到問題，不易排查。 

所以綜合對比來看，建議選用k3s。