云+X案例展 | 传播类:k3s基于逾百台工控机的应用实践

本案例由Rancher投递并参与评选,CSDN云计算独家全网首发;更多关于【 云+X 案例征集】的相关信息, 点击了解详情丨挖掘展现更多优秀案例,为不同行业领域带来启迪,进而推动整个“云+行业”的健康发展。

随着国家政策的导向,互联网基础设施的普及,工业、能源行业的智能化改造已经进行的如火如荼,传统行业的特点是信息化、智能化水平严重落后于其他行业,在进行信息化、智能化改造的过程中,首先第一步,就是要获取底层系统的全方位的数据。

为此,需要部署大量的边缘设备来采集数据、分析数据,通过这些数据进行建模,大量的边缘设备一般离散的分布在不同机房、厂区、甚至是不同的地理区域,这对运维人员来讲是令人恐惧的事情,维护这些设备,管理其上运行的应用变得极其困难。

全应科技是国内第一批投身于工业互联网改革浪潮中一员,因此上面提到的问题,也是其面临的问题。全应科技从一开始就采用了微服务化的开发模式,除了平台框架核心应用之外,所有应用都是可插拔的微服务。

与业务平台不同的是,边缘设备具有下面的特点:

  • 数量大,动辄有数十台、数百台设备;

  • 单点故障影响小,一个设备只负责一小块区域的数据采集、分析与计算,因此单台设备的故障导致的局部数据的缺失,数据分析层面也进行了数据清洗,因此,单点故障对全局业务影响不大。

需求 

对于运维角色来讲:

  • 管理这些边缘设备,保持边缘设备上运行的服务的高可用性;

  • 快速的上线、升级

  • 配置的快速更改与应用

逻辑拓扑图

下面的图形简单描述了项目基础设施层的拓扑:

其中,每一个边缘侧设备上运行的业务会和中枢业务系统通讯,边缘侧所有设备在单独的一个网络平面中。

运维方案选型

在决定运维方式时,考虑过下面的几种方式:

Ansible

我们在边缘侧设备上运行的应用大部分都是纯Java应用,再加上一部分Python应用,因此部署和启动非常简单,外加上supervisord应用实现了应用的基本高可用方案。在公司还没有进行容器化转型之前,我们采用传统的部署形式部署微服务,就是配置好宿主机的系统环境,直接将应用部署在宿主机系统上,在这种情况下,我们只需要解决的问题是大批量设备部署和维护的问题,因为不管是部署还是更新升级、配置,所有边缘侧使用Ansible可以较好的满足这一条件。

但是这种方法也有缺点,需要维护一套甚至多套ansible playbook,边缘侧设备所在的网络条件比较差,异常状况也比较差,经常掉电重启或者断网,使用ansible 容易造成各个节点的配置不同步。

kubeedge

kubeedge是由华为基于kubernetes开发并开源,专门用于边缘容器编排的运维方案,其基本架构如下:

从上面的架构图中可以看到,kubeedge实现了一个边缘侧完整的框架,对我们公司来讲,我们自行实现了例如“DeviceTwin”、“EventBus”、“ServiceBus”以及基于MQTT收发消息。因此:

  1. 一部分组件与kubeedge重叠了;

  2. 部署不方便,kubeedge要求在各个节点上以kubeadmin部署kubernetes集群(0.6版本,现在已经更新至1.1版本,不知道现在是否有更简便快捷的形式),对网络环境不好的边缘侧设备有较大难度;

  3. 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管理和维护集群:

发布了237 篇原创文章 · 获赞 1108 · 访问量 68万+

猜你喜欢

转载自blog.csdn.net/FL63Zv9Zou86950w/article/details/103778471