云+X案例展 | 传播类：k3s基于逾百台工控机的应用实践
隨著國(guó)家政策的導(dǎo)向，互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的普及，工業(yè)、能源行業(yè)的智能化改造已經(jīng)進(jìn)行的如火如荼，傳統(tǒng)行業(yè)的特點(diǎn)是信息化、智能化水平嚴(yán)重落后于其他行業(yè)，在進(jìn)行信息化、智能化改造的過(guò)程中，首先第一步，就是要獲取底層系統(tǒng)的全方位的數(shù)據(jù)。
為此，需要部署大量的邊緣設(shè)備來(lái)采集數(shù)據(jù)、分析數(shù)據(jù)，通過(guò)這些數(shù)據(jù)進(jìn)行建模，大量的邊緣設(shè)備一般離散的分布在不同機(jī)房、廠區(qū)、甚至是不同的地理區(qū)域，這對(duì)運(yùn)維人員來(lái)講是令人恐懼的事情，維護(hù)這些設(shè)備，管理其上運(yùn)行的應(yīng)用變得極其困難。
全應(yīng)科技是國(guó)內(nèi)第一批投身于工業(yè)互聯(lián)網(wǎng)改革浪潮中一員，因此上面提到的問(wèn)題，也是其面臨的問(wèn)題。全應(yīng)科技從一開(kāi)始就采用了微服務(wù)化的開(kāi)發(fā)模式，除了平臺(tái)框架核心應(yīng)用之外，所有應(yīng)用都是可插拔的微服務(wù)。
與業(yè)務(wù)平臺(tái)不同的是，邊緣設(shè)備具有下面的特點(diǎn)：
-
數(shù)量大，動(dòng)輒有數(shù)十臺(tái)、數(shù)百臺(tái)設(shè)備；
-
單點(diǎn)故障影響小，一個(gè)設(shè)備只負(fù)責(zé)一小塊區(qū)域的數(shù)據(jù)采集、分析與計(jì)算，因此單臺(tái)設(shè)備的故障導(dǎo)致的局部數(shù)據(jù)的缺失，數(shù)據(jù)分析層面也進(jìn)行了數(shù)據(jù)清洗，因此，單點(diǎn)故障對(duì)全局業(yè)務(wù)影響不大。
需求?
對(duì)于運(yùn)維角色來(lái)講：
-
管理這些邊緣設(shè)備，保持邊緣設(shè)備上運(yùn)行的服務(wù)的高可用性；
-
快速的上線、升級(jí)
-
配置的快速更改與應(yīng)用
邏輯拓?fù)鋱D
下面的圖形簡(jiǎn)單描述了項(xiàng)目基礎(chǔ)設(shè)施層的拓?fù)?#xff1a;
其中，每一個(gè)邊緣側(cè)設(shè)備上運(yùn)行的業(yè)務(wù)會(huì)和中樞業(yè)務(wù)系統(tǒng)通訊，邊緣側(cè)所有設(shè)備在單獨(dú)的一個(gè)網(wǎng)絡(luò)平面中。
運(yùn)維方案選型
在決定運(yùn)維方式時(shí)，考慮過(guò)下面的幾種方式：
Ansible
我們?cè)谶吘墏?cè)設(shè)備上運(yùn)行的應(yīng)用大部分都是純Java應(yīng)用，再加上一部分Python應(yīng)用，因此部署和啟動(dòng)非常簡(jiǎn)單，外加上supervisord應(yīng)用實(shí)現(xiàn)了應(yīng)用的基本高可用方案。在公司還沒(méi)有進(jìn)行容器化轉(zhuǎn)型之前，我們采用傳統(tǒng)的部署形式部署微服務(wù)，就是配置好宿主機(jī)的系統(tǒng)環(huán)境，直接將應(yīng)用部署在宿主機(jī)系統(tǒng)上，在這種情況下，我們只需要解決的問(wèn)題是大批量設(shè)備部署和維護(hù)的問(wèn)題，因?yàn)椴还苁遣渴疬€是更新升級(jí)、配置，所有邊緣側(cè)使用Ansible可以較好的滿足這一條件。
但是這種方法也有缺點(diǎn)，需要維護(hù)一套甚至多套ansible playbook，邊緣側(cè)設(shè)備所在的網(wǎng)絡(luò)條件比較差，異常狀況也比較差，經(jīng)常掉電重啟或者斷網(wǎng)，使用ansible 容易造成各個(gè)節(jié)點(diǎn)的配置不同步。
kubeedge
kubeedge是由華為基于kubernetes開(kāi)發(fā)并開(kāi)源，專門(mén)用于邊緣容器編排的運(yùn)維方案，其基本架構(gòu)如下：
從上面的架構(gòu)圖中可以看到，kubeedge實(shí)現(xiàn)了一個(gè)邊緣側(cè)完整的框架，對(duì)我們公司來(lái)講，我們自行實(shí)現(xiàn)了例如“DeviceTwin”、“EventBus”、“ServiceBus”以及基于MQTT收發(fā)消息。因此：
一部分組件與kubeedge重疊了；
部署不方便，kubeedge要求在各個(gè)節(jié)點(diǎn)上以kubeadmin部署kubernetes集群（0.6版本，現(xiàn)在已經(jīng)更新至1.1版本，不知道現(xiàn)在是否有更簡(jiǎn)便快捷的形式），對(duì)網(wǎng)絡(luò)環(huán)境不好的邊緣側(cè)設(shè)備有較大難度；
kubeedge組件與kubernetes組件基本一致，對(duì)于邊緣設(shè)備寸土寸金的資源來(lái)說(shuō)，不太友好。
通過(guò)實(shí)踐，第2點(diǎn)和第3點(diǎn)原因直接打消了我采用kubeedge的念頭。
K3s
去除了k8s中的一些實(shí)驗(yàn)特性、非必須的組件，例如云廠商的驅(qū)動(dòng)、存儲(chǔ)插件，k3s在默認(rèn)狀態(tài)下只會(huì)啟動(dòng)除自身進(jìn)程之外的兩個(gè)應(yīng)用：
coredns：提供集群內(nèi)部的DNS解析服務(wù)。
-
traefik：ingress controller的角色。
-
k3s server默認(rèn)使用本地（已集成）的sqllite作為后端數(shù)據(jù)存儲(chǔ)，通訊效率更高一些。
占用資源少：k3s默認(rèn)使用containerd（server節(jié)點(diǎn)，不可更改）作為容器運(yùn)行時(shí)，不在需要中間層的docker engine，占用資源更少。
部署簡(jiǎn)單：對(duì)環(huán)境依賴少，可離線也可在線部署（不過(guò)國(guó)內(nèi)的網(wǎng)絡(luò)環(huán)境不推薦在線部署。），離線部署時(shí)，只需要下載一個(gè)大約40MB的二進(jìn)制文件和一個(gè)200MB不到的離線鏡像包，啟動(dòng)k3s節(jié)點(diǎn)幾乎是秒級(jí)的。
上手無(wú)代價(jià)：
-
使用k3s與kubernetes習(xí)慣完全一致，對(duì)于使用kubernetes的人來(lái)講使用k3s沒(méi)有任何代價(jià)；
-
支持部署helm tiller服務(wù)端（盡管tiller端會(huì)在helm 3.x版本中被干掉），直接使用原有charts部署應(yīng)用無(wú)障礙；
擴(kuò)縮容方便：增刪節(jié)點(diǎn)極其方便，幾乎是分鐘以內(nèi)就可以完成；
兼容arm架構(gòu)設(shè)備：對(duì)于部分有此種類(lèi)型的設(shè)備的集群友好。
k3s架構(gòu)圖k3s集群的所有數(shù)據(jù)存儲(chǔ)在server（master）節(jié)點(diǎn)本地的SQLite數(shù)據(jù)庫(kù)中，當(dāng)然也支持存儲(chǔ)在諸如MySQL、etcd中，都是支持按照需求在部署節(jié)點(diǎn)時(shí)選擇配置的。server節(jié)點(diǎn)與agent節(jié)點(diǎn)之間采用tunnel隧道通信，增強(qiáng)了安全性，同時(shí)也提升了效率。agent與server節(jié)點(diǎn)即使斷開(kāi)網(wǎng)絡(luò)連接，也不影響相互各自的業(yè)務(wù)。
因此通過(guò)上面的對(duì)比和實(shí)踐驗(yàn)證，決定采用k3s來(lái)管理邊緣設(shè)備集群。
完整的運(yùn)維架構(gòu)圖使用Rancher管理k3s集群
在Rancher上添加一個(gè)集群，然后按照步驟將該集群導(dǎo)入到Rancher平臺(tái)中，可以使用Rancher管理和維護(hù)集群：
挖掘優(yōu)秀案例，啟迪各行各業(yè)，推動(dòng)“云+行業(yè)”健康發(fā)展。?CSDN云計(jì)算第二階段云+X 案例征集火熱報(bào)名中?
總結(jié)
以上是生活随笔為你收集整理的云+X案例展 | 传播类：k3s基于逾百台工控机的应用实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 华为智能IP网络，加速联接智能化转型
- 下一篇： 突破性能极限——阿里云神龙最新ASPLO