想把Docker容器應(yīng)用推到邊緣節(jié)點(diǎn)跑起來，所以嘗試使用了一下兩大公有云邊緣方案：（1）華為云的IEF服務(wù)，（2）阿里云的ACK@Edge服務(wù)。只是體驗(yàn)的總結(jié)，做個(gè)記錄，無(wú)孰優(yōu)孰劣之分，僅技術(shù)交流。如果有什么說的不對(duì)，也別遷怒。

本人的一臺(tái)小電腦，想作為邊緣節(jié)點(diǎn)，然后將Docker鏡像，從云端推至邊緣節(jié)點(diǎn)跑起來。

節(jié)點(diǎn)信息：Jetson Nano，4U4G，ARM64位，Ubuntu18.04系統(tǒng)，帶一個(gè)英偉達(dá)的128核Maxwell架構(gòu)GPU。可以正常執(zhí)行docker，nvidia-docker，cuda程序等功能。

這里嘗試使用并總結(jié)了一下兩大公有云邊緣方案：（1）華為云的IEF服務(wù)，（2）阿里云的ACK@Edge服務(wù)。總結(jié)的不對(duì)的地方，可以知會(huì)我及時(shí)修正。

1、邊緣方案共同點(diǎn)

1. 主打基于“K8s+Docker容器”的事實(shí)標(biāo)準(zhǔn) 進(jìn)行構(gòu)筑的云邊方案。
2. 其中Master在云端，Slaver節(jié)點(diǎn)在邊端。
3. 管理 “邊端節(jié)點(diǎn)/邊端應(yīng)用”是要收費(fèi)的。

2、阿里云ACK@Edge

產(chǎn)品介紹：https://cn.aliyun.com/solution/cloudnative/edgecomputing

主打原生支持kubernetes與docker生態(tài)的云邊方案

2.1 集群使用編排服務(wù)（ROS）進(jìn)行自動(dòng)化

邊緣集群是使用阿里云資源編排服務(wù)（ROS）進(jìn)行部署的，雖說這樣會(huì)使得容器團(tuán)隊(duì)在實(shí)現(xiàn)K8s集群自動(dòng)化時(shí)，定制流程不太方便；但這也是有好處：可以使用真實(shí)的業(yè)務(wù)述求，去改進(jìn)另一個(gè)云服務(wù)（從整個(gè)云來說是正收益的：再難吃的狗糧，自己吃）。

華為云也有編排服務(wù)（AOS），但是華為云的容器集群（CCE），并不使用編排服務(wù)創(chuàng)建復(fù)雜的集群。也許這對(duì)AOS來說，永遠(yuǎn)是個(gè)矛盾的話題：我（AOS）是做自動(dòng)化的，但是你（CCE）說你的自動(dòng)化場(chǎng)景我支撐不了，可是我（AOS）又需要你的場(chǎng)景來完善我的自動(dòng)化能力。。。

2.2  邊端節(jié)點(diǎn)，直接注冊(cè)到Master

有些集群添加節(jié)點(diǎn)是2步：先到master登記，然后slaver節(jié)點(diǎn)連到master進(jìn)行注冊(cè)。（如SGE，或者 華為云邊緣服務(wù)IEF）

有些集群則只需要1步：slaver節(jié)點(diǎn)主動(dòng)連接master進(jìn)行注冊(cè)。（如K8s，或者阿里云的這個(gè)邊緣服務(wù)）

1）獲取注冊(cè)節(jié)點(diǎn)的方法：

個(gè)人感覺，1步操作，更簡(jiǎn)單。節(jié)點(diǎn)主動(dòng)注冊(cè)至Master，也比較符合平常理解。

當(dāng)然阿里云邊緣這個(gè)配置頁(yè)面也有不足：比如這里的配置項(xiàng)，每一個(gè)配置項(xiàng)的作用未做說明（沒說明什么情況下什么插件可以取消，因?yàn)槲冶疽馐窍氡M量少的安裝東西），擔(dān)心失敗又不得不全部選擇。如果這里可以對(duì)參數(shù)做一層UI的封裝渲染，用戶體驗(yàn)會(huì)更好。

事實(shí)上，這里我就趟了幾次坑，在下一章節(jié)描述。

2.3      安裝邊緣節(jié)點(diǎn)，稍有不順

安裝步驟，非常簡(jiǎn)單，一條安裝指令搞定。安裝過程中會(huì)聯(lián)網(wǎng)下載安裝包。

但是安裝的魯棒性略弱，直接描述躺過的坑。

1）   選擇K8s集群的Kube-proxy實(shí)現(xiàn)類型，不要默認(rèn)的ipvs，而應(yīng)選擇 iptables。原因是我的小節(jié)點(diǎn) 內(nèi)核沒有 ip_vs_wrr 模塊，會(huì)導(dǎo)致安裝失敗。

2）安裝配置階段，我把kube-proxy和flannel這2插件刪了，只保留了coredns插件時(shí)，最終安裝會(huì)失敗。原因是coredns插件會(huì)依賴前面2個(gè)插件（這里可以考慮提前檢查并提示用戶）。

3）manageRuntime選項(xiàng)，是指“是否重新安裝Docker”的意思。默認(rèn)配置，會(huì)在安裝過程將我節(jié)點(diǎn)上好用的Docker給卸載了，但是新的Docker又是安裝失敗。

4）重新配置，這次選擇不重裝Docker。結(jié)果還是失敗：Unsupport cgroup driver cgroupfs…

經(jīng)詢問是 cgroup 會(huì)有內(nèi)存泄漏的問題，所以cgroupdriver需要選擇 systemd 類型。

這里重新配置Docker的runtime配置為使用 systemd，具體見：https://help.aliyun.com/knowledge_detail/123771.html?spm=5176.11065259.1996646101.searchclickresult.f1d02d4c5FAW9m

最終節(jié)點(diǎn)注冊(cè)至云端：

這里也要提一下，卸載功能，還是非常方便的。一條 reset命令，節(jié)點(diǎn)就恢復(fù)原樣了。

2.4   應(yīng)用管理簡(jiǎn)單，完全兼容K8s

創(chuàng)建應(yīng)用，就是普通的K8s參數(shù)，對(duì)于懂K8s的人來說無(wú)難度。

也能通過 kubectl 查詢?nèi)萜餍畔ⅲ迷u(píng)。

2.5 CloudShell太好用了吧

一般云服務(wù)，想了解集群的情況，除了使用Console，還會(huì)有cli命令行。

ACK@Edge使用原生的 Kubectl 作為其 cli。并且還提供了一個(gè)叫做 CloudShell 的控制臺(tái)，直接可以使用，直呼太好用了吧！

點(diǎn)擊上面的按鈕，就直接可以使用 k8s 的客戶端cli，一個(gè)字：方便。

都不用下載安裝（因?yàn)椴煌腒8s版本，需要下載不同版本的cli，所以這里不用下載就能用，體驗(yàn)不錯(cuò)）

2.6 遠(yuǎn)程執(zhí)行 exec -it，支持

可以直接從云端，登錄邊緣容器查詢or調(diào)試，挺好用的。

2.7  費(fèi)用按照節(jié)點(diǎn)大小收

管理費(fèi)用，按照邊緣節(jié)點(diǎn)大小進(jìn)行收費(fèi)：

基本上，我這個(gè)4核的ARM節(jié)點(diǎn)，一個(gè)月：4核 * 0.2元 * 30天 = 24元。感覺還行~

不過，這里也需要指出，ACK@Edge在云端必須要有一臺(tái)額外ECS，這也會(huì)消耗一筆費(fèi)用（按4U8G算，是1.4/小時(shí)）。同時(shí)，Pro版集群管理費(fèi)用0.64 /小時(shí)（標(biāo)準(zhǔn)版免費(fèi)），也是一筆開銷。

3、華為云IEF

產(chǎn)品介紹：https://www.huaweicloud.com/product/ief.html

也是主打原生支持kubernetes與docker生態(tài)的云邊方案

3.1 邊緣集群不需提前創(chuàng)建，隨時(shí)可用

因?yàn)榧菏沁壿嫷模圆⒉恍枰崆皠?chuàng)建，也就省略了一個(gè)大步驟。

至少擁有邊緣集群這件事上，華為云不需要任何等待。阿里云的 ACK@edge創(chuàng)建一個(gè)邊緣集群，需要等好久~

有利有弊吧，如果華為IEF，也可以提供 kubectl 或者其他cli的話，那么顯然不需要?jiǎng)?chuàng)建集群Master，更方便實(shí)惠。（說明云服務(wù)實(shí)現(xiàn)邏輯多租的能力更強(qiáng)）。

3.2 邊端節(jié)點(diǎn)，先登記，再注冊(cè)

IEF屬于2步注冊(cè)節(jié)點(diǎn)門派，新增節(jié)點(diǎn)需要2步：

1）云端Master先登記。

然后2）邊端節(jié)點(diǎn)，進(jìn)行實(shí)際的連接注冊(cè)。

3.3 安裝、卸載，挺方便

按照下載的2個(gè)文件，以及提供的命令，進(jìn)行安裝操作。過程中需要聯(lián)網(wǎng)下載安裝包，整體比較順利。當(dāng)節(jié)點(diǎn)上的agent啟動(dòng)&注冊(cè)至云端時(shí)，云端的節(jié)點(diǎn)狀態(tài)就變?yōu)镺K。

遇到的問題，主要就是一開始選了GPU卡，導(dǎo)致節(jié)點(diǎn)安裝失敗。然后重新安裝會(huì)一直失敗，原因是節(jié)點(diǎn)的加解密的物料，沒有清理干凈。需要手動(dòng)刪除所有殘留。

當(dāng)然，卸載也非常方便，一條uninstall命令就可以干凈地還原節(jié)點(diǎn)，這一點(diǎn)必須好評(píng)點(diǎn)贊。

3.4 英偉達(dá)GPU也有級(jí)別

可憐我的邊緣節(jié)點(diǎn)，帶的英偉達(dá)GPU屬于是最低端的GPU（Jetson Nano平臺(tái)，帶128核的Maxwell架構(gòu)的GPU），不過它也是可以執(zhí)行cuda，nvidia-docker等基本功能的，基本屬于麻雀雖小五臟俱全那種。按理來說，Docker功能都正常，應(yīng)該支持才對(duì)。

不過在IEF里面，這種GPU是不支持的（至少在登記的時(shí)候）。嗯，它要求邊緣節(jié)點(diǎn)帶T4，P4這種比較高級(jí)的英偉達(dá)GPU。額，IOT邊緣節(jié)點(diǎn)表示要不起。

所以在登記邊緣節(jié)點(diǎn)的時(shí)候，只能選擇為不帶GPU的節(jié)點(diǎn)。

3.5 應(yīng)用管理簡(jiǎn)單方便

基本上，應(yīng)用啟動(dòng)、管理等界面，與CCE服務(wù)（華為托管版K8s）的Deployment一致，比較好理解。

3.6 遠(yuǎn)程執(zhí)行 exec -it ？不支持

K8s很牛逼的一個(gè)功能，就是使用 exec -it 直接從Master登錄到任意節(jié)點(diǎn)的App容器里面，查看&執(zhí)行調(diào)試功能。

不過IEF暫時(shí)未提供該功能，想使用exec -it，需要自己登錄到邊緣節(jié)點(diǎn)上面執(zhí)行Docker命令。目前Master云端這邊是不支持的。相對(duì)而言，這一點(diǎn)不是很方便，畢竟邊緣節(jié)點(diǎn)在后期并不一定容易登錄（比如它跑在某些奇怪的邊緣）。

當(dāng)然，如果能從云端Master遠(yuǎn)程連接節(jié)點(diǎn)進(jìn)行操作，那也還是方便的。不過這個(gè)也還暫不支持。目前想操作App，只能自己主動(dòng)連到邊緣節(jié)點(diǎn)。

另外提一點(diǎn)：IEF目前不兼容 kubectl 客戶端，也未提供自己的 cli 操作工具。

3.7 費(fèi)用按照App數(shù)量收

收費(fèi)模式是按照App數(shù)量來算的，如下：

按照我4核的節(jié)點(diǎn)，上面跑4個(gè)容器好了。

一個(gè)月：4App * 1.56元 * 24H * 30天 = 4492元。普通開發(fā)者直呼要不起~

（雖然有套餐包可以買，不過算下來一個(gè)容器基本 1000元/月 的價(jià)格）

3.8 其他

IEF提供了豐富的消息管理能力，比如MQTT，EventBus什么的。不過因?yàn)闆]有需求用到這些功能，所以并未嘗試使用。

另外，還提供了邊緣函數(shù)服務(wù)，同樣原因未使用。

4、對(duì)比總結(jié)

僅對(duì)操作過的特性做個(gè)對(duì)比表格

（不是完整能力的對(duì)比，所以聞過則喜，聞過則喜，聞過則喜）

總結(jié)：

• 如果管理的邊緣節(jié)點(diǎn)較多，那么按照節(jié)點(diǎn)數(shù)量進(jìn)行收費(fèi)會(huì)更劃算。
• 如果集群管理App容器較多（2個(gè)以上），感覺還是按照節(jié)點(diǎn)數(shù)量收費(fèi)更劃算。
• 如果邊緣節(jié)點(diǎn)資源真的非常有限，那么安裝定制過的agent，更省資源。
• 如果需要端側(cè)設(shè)備等更精細(xì)粒度管理，可以選擇適合自己的款式。
• 判斷自己是否需要Kubernetes標(biāo)準(zhǔn)API能力，選擇合適的款式。

就我個(gè)人使用場(chǎng)景來說，系統(tǒng)實(shí)現(xiàn)是否侵入的修改K8s并不關(guān)心，但兼容K8s標(biāo)準(zhǔn)API，則是個(gè)強(qiáng)需求。原因是：我已有的系統(tǒng)，調(diào)用K8s的API啟動(dòng)容器功能已經(jīng)寫好了。那么當(dāng)場(chǎng)景拓展為要投任務(wù)到邊緣節(jié)點(diǎn)，至少不用重新開發(fā)調(diào)用API。

本文為作者原創(chuàng)投稿文章，原文地址: https://bbs.huaweicloud.com/blogs/246358