本案例由Rancher投遞并參與評選，CSDN云計算獨家全網首發；更多關于【云+X 案例征集】的相關信息，點擊了解詳情丨挖掘展現更多優秀案例，為不同行業領域帶來啟迪，進而推動整個“云+行業”的健康發展。

隨著國家政策的導向，互聯網基礎設施的普及，工業、能源行業的智能化改造已經進行的如火如荼，傳統行業的特點是信息化、智能化水平嚴重落后于其他行業，在進行信息化、智能化改造的過程中，首先第一步，就是要獲取底層系統的全方位的數據。

為此，需要部署大量的邊緣設備來采集數據、分析數據，通過這些數據進行建模，大量的邊緣設備一般離散的分布在不同機房、廠區、甚至是不同的地理區域，這對運維人員來講是令人恐懼的事情，維護這些設備，管理其上運行的應用變得極其困難。

全應科技是國內第一批投身于工業互聯網改革浪潮中一員，因此上面提到的問題，也是其面臨的問題。全應科技從一開始就采用了微服務化的開發模式，除了平臺框架核心應用之外，所有應用都是可插拔的微服務。

與業務平臺不同的是，邊緣設備具有下面的特點：

• 數量大，動輒有數十臺、數百臺設備；

• 單點故障影響小，一個設備只負責一小塊區域的數據采集、分析與計算，因此單臺設備的故障導致的局部數據的缺失，數據分析層面也進行了數據清洗，因此，單點故障對全局業務影響不大。

需求?

對于運維角色來講：

• 管理這些邊緣設備，保持邊緣設備上運行的服務的高可用性；

• 快速的上線、升級

• 配置的快速更改與應用

邏輯拓撲圖

下面的圖形簡單描述了項目基礎設施層的拓撲：

其中，每一個邊緣側設備上運行的業務會和中樞業務系統通訊，邊緣側所有設備在單獨的一個網絡平面中。

運維方案選型

在決定運維方式時，考慮過下面的幾種方式：

Ansible

我們在邊緣側設備上運行的應用大部分都是純Java應用，再加上一部分Python應用，因此部署和啟動非常簡單，外加上supervisord應用實現了應用的基本高可用方案。在公司還沒有進行容器化轉型之前，我們采用傳統的部署形式部署微服務，就是配置好宿主機的系統環境，直接將應用部署在宿主機系統上，在這種情況下，我們只需要解決的問題是大批量設備部署和維護的問題，因為不管是部署還是更新升級、配置，所有邊緣側使用Ansible可以較好的滿足這一條件。

但是這種方法也有缺點，需要維護一套甚至多套ansible playbook，邊緣側設備所在的網絡條件比較差，異常狀況也比較差，經常掉電重啟或者斷網，使用ansible 容易造成各個節點的配置不同步。

kubeedge

kubeedge是由華為基于kubernetes開發并開源，專門用于邊緣容器編排的運維方案，其基本架構如下：

從上面的架構圖中可以看到，kubeedge實現了一個邊緣側完整的框架，對我們公司來講，我們自行實現了例如“DeviceTwin”、“EventBus”、“ServiceBus”以及基于MQTT收發消息。因此：

一部分組件與kubeedge重疊了；

部署不方便，kubeedge要求在各個節點上以kubeadmin部署kubernetes集群（0.6版本，現在已經更新至1.1版本，不知道現在是否有更簡便快捷的形式），對網絡環境不好的邊緣側設備有較大難度；

kubeedge組件與kubernetes組件基本一致，對于邊緣設備寸土寸金的資源來說，不太友好。

通過實踐，第2點和第3點原因直接打消了我采用kubeedge的念頭。

K3s

去除了k8s中的一些實驗特性、非必須的組件，例如云廠商的驅動、存儲插件，k3s在默認狀態下只會啟動除自身進程之外的兩個應用：

coredns：提供集群內部的DNS解析服務。

• traefik：ingress controller的角色。

• k3s server默認使用本地（已集成）的sqllite作為后端數據存儲，通訊效率更高一些。

占用資源少：k3s默認使用containerd（server節點，不可更改）作為容器運行時，不在需要中間層的docker engine，占用資源更少。

部署簡單：對環境依賴少，可離線也可在線部署（不過國內的網絡環境不推薦在線部署。），離線部署時，只需要下載一個大約40MB的二進制文件和一個200MB不到的離線鏡像包，啟動k3s節點幾乎是秒級的。

上手無代價：

• 使用k3s與kubernetes習慣完全一致，對于使用kubernetes的人來講使用k3s沒有任何代價；

• 支持部署helm tiller服務端（盡管tiller端會在helm 3.x版本中被干掉），直接使用原有charts部署應用無障礙；

擴縮容方便：增刪節點極其方便，幾乎是分鐘以內就可以完成；

兼容arm架構設備：對于部分有此種類型的設備的集群友好。

k3s架構圖

k3s集群的所有數據存儲在server（master）節點本地的SQLite數據庫中，當然也支持存儲在諸如MySQL、etcd中，都是支持按照需求在部署節點時選擇配置的。server節點與agent節點之間采用tunnel隧道通信，增強了安全性，同時也提升了效率。agent與server節點即使斷開網絡連接，也不影響相互各自的業務。

因此通過上面的對比和實踐驗證，決定采用k3s來管理邊緣設備集群。

完整的運維架構圖

使用Rancher管理k3s集群

在Rancher上添加一個集群，然后按照步驟將該集群導入到Rancher平臺中，可以使用Rancher管理和維護集群：

挖掘優秀案例，啟迪各行各業，推動“云+行業”健康發展。?CSDN云計算第二階段云+X 案例征集火熱報名中

?

總結

以上是生活随笔為你收集整理的云+X案例展 | 传播类：k3s基于逾百台工控机的应用实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。