k3s生产案例分享：逾百台工控机的应用实践

本文由11月7日晚曾永杰，上海全应科技运维经理的技术分享整理而成。

曾永杰，上海全应科技有限公司运维经理，曾在华为西安研究所云计算部门承担软件测试工程师、项目交付、线上运维等工作职责，当前工作主要为CI/CD流程的建设与维护、应用的容器化改革和容器云平台的运维管理。

欢迎添加k3s中文社区助手微信（微信ID：k3s2019），加入k3s官方中文社区，和大家一起交流k3s使用经验。

项目简介

背 景

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

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

我们公司是国内第一批投身于工业互联网改革浪潮中一员，因此上面提到的问题，也是我们面临的问题。

公司从一开始就采用了微服务化的开发模式，除了平台框架核心应用之外，所有应用都是可插拔的微服务。

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

• 数量大，动辄有数十台、数百台设备；

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

需 求

对于运维角色来讲：

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

• 快速的上线、升级

• 配置的快速更改与应用

逻辑拓扑图

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

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

运维方案选型

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

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简介

什么是k3s?

k3s is 5 less then k8s,直接翻译过来就是k3s比k8s少了5个字符，引申一下就是k3s就是k8s的简化版。可以看做k8s的一个衍生版，特点就是轻量。

k3s的特点有哪些？

apiserver、controller manager、scheduler、kubelet、flannel等组件这到一个进程中（通过指定是server或者agent选项来控制节点上需要启动哪些组件，server相当于k8s的master节点，agent相当于worker节点），占用的内存更少了，整个k3s server进程需要的内存在500MB以下。

$ systemctl status k3s-server
● k3s-server.service - Lightweight Kubernetes
   Loaded: loaded (/usr/lib/systemd/system/k3s-server.service; enabled; vendor preset: disabled)
   Active: active (running) since 一 2019-10-28 11:35:25 CST; 1 weeks 3 days ago
     Docs: https://k3s.io
 Main PID: 1534 (k3s-server)
    Tasks: 0
   Memory: 210.2M
   CGroup: /system.slice/k3s-server.service
           ‣ 1534 /usr/bin/k3s server --docker --bind-address=10.0.0.201 --cluster-cidr=10.128.0.0/16 ...

11月 07 14:21:35 test01-201 k3s[1534]: I1107 14:21:35.426083    1534 trace.go:81] Trace[193609352...ms):
11月 07 14:21:35 test01-201 k3s[1534]: Trace[1936093523]: [575.582721ms] [575.489216ms] Listing f...done
11月 07 14:22:14 test01-201 k3s[1534]: W1107 14:22:14.958361    1534 reflector.go:289] object-"te...978)
11月 07 14:23:32 test01-201 k3s[1534]: W1107 14:23:32.403901    1534 reflector.go:289] object-"te...043)
11月 07 14:23:52 test01-201 k3s[1534]: W1107 14:23:52.762578    1534 reflector.go:289] object-"te...061)
11月 07 14:24:08 test01-201 k3s[1534]: W1107 14:24:08.159614    1534 reflector.go:289] object-"ku...074)
11月 07 14:24:20 test01-201 k3s[1534]: W1107 14:24:20.815875    1534 reflector.go:289] object-"te...086)
11月 07 14:24:21 test01-201 k3s[1534]: W1107 14:24:21.038295    1534 reflector.go:289] object-"te...086)
11月 07 14:26:17 test01-201 k3s[1534]: W1107 14:26:17.367497    1534 reflector.go:289] object-"te...183)
11月 07 14:26:27 test01-201 k3s[1534]: W1107 14:26:27.321999    1534 reflector.go:289] object-"te...192)
Hint: Some lines were ellipsized, use -l to show in full.
[asadmin@test01-201 ~]$

从上面看出k3s server进程当前占用的内存是210MB。

去除了k8s中的一些实验特性、非必须的组件，例如云厂商的驱动、存储插件，k3s在默认状态下只会启动除自身进程之外的两个应用：

• coredns：提供集群内部的DNS解析服务。

• traefik：ingress controller的角色。

k3s server默认使用本地（已集成）的sqllite作为后端数据存储，通讯效率更高一些。

占用资源少：k3s默认使用containerd（server节点，不可更改）作为容器运行时，不在需要中间层的docker engine，占用资源更少。

部署简单：对环境依赖少，可离线也可在线部署（不过国内的网络环境不推荐在线部署。），离线部署时ÿ