生产用例 | 百台边缘设备上的Kubernetes实践 – 掘金

生产用例 | 百台边缘设备上的Kubernetes实践 – 掘金

本文由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,占用资源更少。

部署简单:对环境依赖少,可离线也可在线部署(不过国内的网络环境不推荐在线部署。),离线部署时,只需要下载一个大约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来管理边缘设备集群。

运维架构简介

下面是一张完整的运维架构图:

在这里插入图片描述

部署k3s集群

由于集群节点一般存在多个,一台台手工安装部署会占用大量的时间,吃力不讨好,因此,我写成了ansible playbook来完成k3s集群的多节点快速自动化部署,如有需要,可以联系yj.zeng@aliyun.com

各个组件版本信息:

  • k3s: v0.9.1

  • docker: 18.09.9

  • helm: v2.14.3

  • OS:CentOS Linux release 7.6.1810 (Core)

  • Ansible: 2.8.3(在多节点下,用来快速批量部署集群节点)

本次实践在Centos 7上完成,由于部署k3s节点需要root用户权限,因此本实践中所有操作均直接使用root用户登录后进行。

获取k3s以及离线镜像包

k3s GitHub主页:

github.com/rancher/k3s…

由于国内访问GitHub的速度很慢,在线安装耗时很长,因此推荐采用离线部署方式部署。

以v0.8.1版本为例,下载下面的两个文件:

  • k3s

  • k3s-airgap-images-amd64.tar

准备工作

假定下载到的文件已经上传到服务器节点的~/packages目录下面。

将k3s二进制文件放置到/usr/local/bin目录下,并赋予可执行权限:

# cp ~/packages/k3s /usr/local/bin/   # chmod +x /usr/local/bin/k3s  

将离线镜像包放置到指定的位置:

# mkdir -p /var/lib/rancher/k3s/agent/images/  # cp ~/packages/k3s-airgap-images-amd64.tar /var/lib/rancher/k3s/agent/images/  

需要在k3s集群所有节点上都放置上面的离线文件。

在部署k3s集群之前,需要对所有节点做如下的基础配置。

如果没有专门的域名服务器提供主机名解析服务,那么在每一台节点的/etc/hosts文件中。写入本节点的IP与主机名映射。

给所有节点安装并配置相同的NTP服务器,保证服务器时间的正确性。

# yum -y install ntp && systemctl start ntpd && systemctl enable ntpd  

为了方便我们直接关闭防火墙服务:

# systemctl stop firewalld && systemctl disable firewalld  

至此,准备工作完成。

部署k3s server节点

提醒:

截止目前,k3s server节点并不支持HA。

k3s server节点安装时,可以选在同时在本地安装一个k3s agent节点用以承载工作负载,如果选择不在server节点上安装agent节点,则除了k3s集成的kuberntes组件(如kubelet、api server)之外,其余的插件、应用均不会被调度到server节点上。

k3s支持使用多种容器运行时环境,server默认以containerd作为运行时,不支持更改。agent节点可以使用contained也可以使用docker,推荐使用docker,因为docker人机更友好,可以方便的管理镜像和容器以及查错。所以如果选择agent节点以docker作为容器运行时,那么必须要提前安装并配置好docker服务。

现在,我们可以启动k3s server节点:

# k3s server \      --docker \      --bind-address=10.0.0.201 \      --cluster-cidr=10.128.0.0/16 \      --service-cidr=10.129.0.0/16 \      --kube-apiserver-arg service-node-port-range=1000-65000 \      --write-kubeconfig=/root/.kube/config \      --write-kubeconfig-mode=644 \      --node-label asrole=worker  

参数说明:

  • –docker: k3s server组件以containerd作为容器运行时。可以顺便在k3s server节点上启动一个agent节点,agent节点可以使用docker作为容器运行时,这样k3s server节点也可以当做工作节点用。当然也可以不在server节点上启动agent节点(添加参数–disable-agent即可)。

  • –bind-address:k3s监听的IP地址,非必选,默认是localhost。

  • –cluster-cidr:与kubernetes一样,也就是pod所在网络平面,非必选,默认是10.42.0.0/16.

  • –service-cidr:与kubernetes一样,服务所在的网络平面,非必选,默认是10.43.0.0/16.

  • –kube-apiserver-arg:额外的api server配置参数,具体可以参考kuberntes官方网站了解支持的配置选项,非必选。

  • –write-kubeconfig:安装时顺便写一个kubeconfig文件,方便使用kubectl工具直接访问。如果不加此参数,则默认的配置文件路径为/etc/rancher/k3s/k3s.yaml,默认只有root用户能读。

  • –write-kubeconfig-mode:与–write-kubeconfig一起使用,指定kubeconfig文件的权限。

  • –node-label:顺便给节点打上一个asrole=worker的label,非必选。

k3s支持众多的安装参数和选型,详细请参考官方文档:

rancher.com/docs/k3s/la…

完成之后,检查集群状态:

# k3s kubectl get nodes  NAME         STATUS   ROLES    AGE   VERSION  test01-201   Ready    master   11m   v1.15.4-k3s.1  

可见节点已经呈就绪状态。

检查pod的状态:

# k3s kubectl get po --all-namespaces  NAMESPACE     NAME                         READY   STATUS      RESTARTS   AGE  kube-system   helm-install-traefik-fhr87   0/1     Completed   0          3m4s  kube-system   svclb-traefik-zlgwx          3/3     Running     0          54s  kube-system   coredns-66f496764-x9svh      1/1     Running     0          3m4s  kube-system   traefik-d869575c8-kvwbc      0/1     Running     0          54s  

可以看到,系统命名空间下所有的应用都已经启动了,server节点已经就绪,接下来可以部署k3s agent工作节点了。

在上面的命令中,我们均是以k3s kubectl开头的命令,是否可以直接使用kubectl客户端呢?当然可以,只需要下载一个对应版本的kubectl二进制文件放到系统的path中,赋予可执行权限即可,使用起来与使用kubernetes集群一模一样!

由于上面的命令是在前台执行的,一旦断开SSH链接或者终止shell进程,k3s server就停止运行了,因此我们给他配置一个systemd服务,用以像管理系统服务一样管理k3s server节点。

创建文件/usr/lib/systemd/system/k3s-server.service,内容为:

[Unit]  Description=Lightweight Kubernetes  Documentation=https://k3s.io  After=network-online.target    [Service]  Type=notify  EnvironmentFile=/etc/systemd/system/k3s.service.env  ExecStart=/usr/local/bin/k3s server --docker --bind-address=10.0.0.201 --cluster-cidr=10.128.0.0/16 --service-cidr=10.129.0.0/16 --kube-apiserver-arg service-node-port-range=1000-65000  KillMode=process  Delegate=yes  LimitNOFILE=infinity  LimitNPROC=infinity  LimitCORE=infinity  TasksMax=infinity  TimeoutStartSec=0  Restart=always  RestartSec=5s    [Install]  WantedBy=multi-user.target  

然后设置服务开机自启:

# systemctl enable k3s-server  

CTRL+C结束在前台执行的命令,我们看到服务文件中引用了一个环境变量文件/etc/systemd/system/k3s.service.env,这个文件并不存在需要先创建一个然后才能启动服务:

# touch /etc/systemd/system/k3s.service.env  # systemctl start k3s-server  

查看服务状态:

# systemctl status k3s-server  ● k3s-server.service - Lightweight Kubernetes     Loaded: loaded (/usr/lib/systemd/system/k3s-server.service; disabled; vendor preset: disabled)     Active: active (running) since 五 2019-10-11 09:37:09 CST; 15min ago       Docs: https://k3s.io   Main PID: 10841 (k3s-server)      Tasks: 0     Memory: 223.3M     CGroup: /system.slice/k3s-server.service             ‣ 10841 /usr/local/bin/k3s server --docker --bind-address=10.0.0.201 --cluster-cidr=10.128.0.0/16 --service-cidr=10.129.0.0/16 --...    10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.920359   10841 event.go:258] Event(v1.ObjectReference{Kind:"Node", Namespace:"", Nam...  10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.927021   10841 controller_utils.go:1036] Caches are synced for persistent vo...ntroller  10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.934842   10841 controller_utils.go:1036] Caches are synced for attach detach controller  10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.940745   10841 controller_utils.go:1036] Caches are synced for garbage colle...ntroller  10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.956261   10841 controller_utils.go:1036] Caches are synced for garbage colle...ntroller  10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.956292   10841 garbagecollector.go:137] Garbage collector: all resource moni... garbage  10月 11 09:37:22 test01-201 k3s[10841]: I1011 09:37:22.959183   10841 controller_utils.go:1036] Caches are synced for cidrallocator controller  10月 11 09:37:23 test01-201 k3s[10841]: I1011 09:37:23.292627   10841 controller.go:606] quota admission added evaluator for: jobs.batch  10月 11 09:38:02 test01-201 k3s[10841]: I1011 09:38:02.930061   10841 event.go:258] Event(v1.ObjectReference{Kind:"Node", Namespace...NotReady  10月 11 09:38:02 test01-201 k3s[10841]: E1011 09:38:02.970568   10841 daemon_controller.go:302] kube-system/svclb-traefik failed wi...Link:"/a  Hint: Some lines were ellipsized, use -l to show in full.  

提醒:如果出现错误,可以通过journalctl -u k3s-server查看日志。

部署k3s agent节点

在server节点部署完成之后,在server节点的/var/lib/rancher/k3s/server/目录下面生成一个node-token文件,该文件存储了k3s agent节点加入集群时所需的token。

在server节点上,获取token:

# cat /var/lib/rancher/k3s/server/node-token   K10e3dc328c9e2cbb07c195542da31ab435dbe0182b1c99c613f460097b5173dbc7::node:0595ee334f5d2847542b5b1c9300f363    

在作为k3s agent节点的系统中,以root用户执行下面的命令启动k3s agent节点,但是,因为我们采用了docker作为agent节点的容器运行时,所以我们先将离线镜像导入到docker中:

# docker load -i ~/packages/k3s-airgap-images-amd64.tar   fb61a074724d: Loading layer [==================================================>]  479.7kB/479.7kB  ed9e1db7c0e6: Loading layer [==================================================>]  40.16MB/40.16MB  Loaded image: coredns/coredns:1.3.0  faf7c252da57: Loading layer [==================================================>]    236kB/236kB  d27d00a62b62: Loading layer [==================================================>]  71.48MB/71.48MB  Loaded image: traefik:1.7.12  d9ff549177a9: Loading layer [==================================================>]  4.671MB/4.671MB  d635f458a6f8: Loading layer [==================================================>]  7.586MB/7.586MB  9ce3955d3fa8: Loading layer [==================================================>]  73.36MB/73.36MB  6c5cc370be91: Loading layer [==================================================>]  4.608kB/4.608kB  Loaded image: rancher/klipper-helm:v0.1.5  767f936afb51: Loading layer [==================================================>]  4.672MB/4.672MB  d9f07b03cc3c: Loading layer [==================================================>]  1.786MB/1.786MB  4d018801281b: Loading layer [==================================================>]  3.072kB/3.072kB  Loaded image: rancher/klipper-lb:v0.1.1  e17133b79956: Loading layer [==================================================>]  744.4kB/744.4kB  Loaded image: k8s.gcr.io/pause:3.1  

然后执行下面的命令安装k3s-agent节点

# k3s agent \      --docker \      --server https://10.0.0.201:6443 \      --token K10e3dc328c9e2cbb07c195542da31ab435dbe0182b1c99c613f460097b5173dbc7::node:0595ee334f5d2847542b5b1c9300f363 \      --node-ip=10.0.0.202 \      --node-label asrole=worker  

参数说明:

  • –docker:k3s agent以docker作为容器运行时。

  • –server:k3s server节点监听的url,必选参数。

  • –token:k3s server安装时生成的token,必选参数。

  • –node-ip:k3s agent节点的IP地址,非必选参数。

  • –node-label:同样给k3s agent节点打上一个asrole=worker的标签,非必选参数。

稍等一会儿,在server节点上查看agent节点是否已经加入到了集群中:

# k3s kubectl get nodes  NAME         STATUS   ROLES    AGE   VERSION  test01-201   Ready    master   12h   v1.15.4-k3s.1  test02-202   Ready    worker   11h   v1.15.4-k3s.1  

可以看到节点已经成功加入到了集群中。

同样给agent节点配置成systemd可以管理的系统服务,创建/usr/lib/systemd/system/k3s-agent.service,内容如下:

[Unit]  Description=Lightweight Kubernetes  Documentation=https://k3s.io  After=network-online.target    [Service]  Type=notify  EnvironmentFile=/etc/systemd/system/k3s.service.env  ExecStart=/usr/local/bin/k3s agent --docker --server https://10.0.0.201:6443 --token K10e3dc328c9e2cbb07c195542da31ab435dbe0182b1c99c613f460097b5173dbc7::node:0595ee334f5d2847542b5b1c9300f363 --node-ip=10.0.0.202 --node-label asrole=worker  KillMode=process  Delegate=yes  LimitNOFILE=infinity  LimitNPROC=infinity  LimitCORE=infinity  TasksMax=infinity  TimeoutStartSec=0  Restart=always  RestartSec=5s    [Install]  WantedBy=multi-user.target  

我们终止前台执行的命令,执行下面的命令通过systemd重新启动服务:

# touch /etc/systemd/system/k3s.service.env  # systemctl daemon-reload && systemctl enable k3s-agent  # systemctl enable k3s-agent  Created symlink from /etc/systemd/system/multi-user.target.wants/k3s-agent.service to /usr/lib/systemd/system/k3s-agent.service.  # systemctl start k3s-agent  # systemctl status k3s-agent  ● k3s-agent.service - Lightweight Kubernetes     Loaded: loaded (/usr/lib/systemd/system/k3s-agent.service; enabled; vendor preset: disabled)     Active: active (running) since 五 2019-10-11 10:05:12 CST; 1min 30s ago       Docs: https://k3s.io   Main PID: 13631 (k3s-agent)      Tasks: 0     Memory: 149.0M     CGroup: /system.slice/k3s-agent.service             ‣ 13631 /usr/local/bin/k3s agent --docker --server https://10.0.0.201:6443 --token K10e3dc328c9e2cbb07c195542da31ab435dbe0182b1c9...    10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.074705   13631 cpu_manager.go:156] [cpumanager] reconciling every 10s  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.074731   13631 policy_none.go:42] [cpumanager] none policy: Start  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.079218   13631 plugin_manager.go:116] Starting Kubelet Plugin Manager  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.350068   13631 kube.go:134] Node controller sync successful  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.350282   13631 vxlan.go:120] VXLAN config: VNI=1 Port=0 GBP=false DirectRouting=false  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.353705   13631 flannel.go:75] Wrote subnet file to /run/flannel/subnet.env  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.353740   13631 flannel.go:79] Running backend.  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.353767   13631 vxlan_network.go:60] watching for new subnet leases  10月 11 10:05:13 test02-202 k3s[13631]: I1011 10:05:13.412763   13631 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume s...  10月 11 10:05:14 test02-202 k3s[13631]: I1011 10:05:14.215209   13631 reconciler.go:150] Reconciler: start to sync state  Hint: Some lines were ellipsized, use -l to show in full.  

可以看到k3s agent节点已经成功启动了。

如果还需要加入新的agent节点到集群中,可以按照上述方式配置启动新节点,完成后,新节点自动加入到集群中。

部署应用

通过helm部署应用

一般情况下,我们会通过helm chart安装应用和升级应用,在k3s集群中,同样可以采用helm来安装部署应用。

下载helm的客户端二进制文件后,放置到/usr/local/bin目录下并赋予可执行权限。执行下面的命令初始化helm客户端:

# k3s kubectl -n kube-system create serviceaccount tiller  serviceaccount/tiller created  # k3s kubectl create clusterrolebinding tiller \  >   --clusterrole=cluster-admin \  >   --serviceaccount=kube-system:tiller  clusterrolebinding.rbac.authorization.k8s.io/tiller created  # helm init --service-account tiller \  > --tiller-image registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.14.3 --skip-refresh  Creating /root/.helm   Creating /root/.helm/repository   Creating /root/.helm/repository/cache   Creating /root/.helm/repository/local   Creating /root/.helm/plugins   Creating /root/.helm/starters   Creating /root/.helm/cache/archive   Creating /root/.helm/repository/repositories.yaml   Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com   Adding local repo with URL: http://127.0.0.1:8879/charts   $HELM_HOME has been configured at /root/.helm.    Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.    Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.  To prevent this, run `helm init` with the --tiller-tls-verify flag.  For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation  

查看helm信息:

# helm version --short  Client: v2.14.3+g0e7f3b6  Server: v2.14.3+g0e7f3b6  

可见helm的服务端已经在集群中创建成功了,下面就可以使用helm chart安装应用了。在此我们进行演示:

#  helm repo add edge https://xxxx.xxxx.com  "edge" has been added to your repositories  # helm install edge/iotgateway  NAME:   idolized-wombat  LAST DEPLOYED: Fri Oct 11 11:26:04 2019  NAMESPACE: default  STATUS: DEPLOYED  ...  

查看pod的情况:

# k3s kubectl get po -o wide  NAME               READY   STATUS    RESTARTS   AGE     IP           NODE         NOMINATED NODE   READINESS GATES  iotgateway-6c242   1/1     Running   0          2m42s   10.0.0.201   test01-201   <none>           <none>  iotgateway-pqsx2   1/1     Running   0          2m38s   10.0.0.202   test02-202   <none>           <none>    

可见应用已经创建成功。

使用Rancher管理k3s集群

在Rancher上添加一个集群,然后按照步骤将该集群导入到Rancher平台中,可以使用Rancher管理和维护集群:

在这里插入图片描述

FAQ

1、在边缘计算中,往往涉及到访问硬件资源,如何从容器内部访问硬件资源?

Linux系统中,所有的硬件资源都体现为/dev/目录下面的一个设备,因此只要能够访问/dev/目录下面的设备文件即可,有的同学会说,那是不是将/dev/目录挂载到容器里面就可以了呢?经过我的实践证明不行,因为挂载到容器里面,即便容器里面是以root用户运行,然是仍旧有可能无法访问一些特殊资源文件,也就是说容器中的“root”用户与宿主机的root用户在访问权限上还是有差别。只需要将容器的运行模式设置为“privileged”即可,如下:

resources:    limits:      cpu: 300m      memory: 512Mi    requests:      cpu: 50m      memory: 256Mi  securityContext:    privileged: true  

2、如何备份集群数据?

k3s集群数据全部存储在/var/lib/rancher下面,在/etc/rancher、/etc/kubernetes下面会存储一些配置文件和证书,因此我们可以周期性备份这几个目录的数据即可。也可以给k3s server节点挂载一个高可靠性的存储设备。

3、节点宕机怎么恢复?

对于agent节点,边缘节点只负责一个小区域的业务,单个节点宕机对整个集群业务影响很有限,只需要重新启动将节点加入集群中即可恢复业务运行。对于server节点,如果有数据备份,可以用数据备份进行恢复(将备份数据放置到对应的目录重新按照原有参数启动server节点服务即可),如果没有备份,那么重新安装一个server节点,更改agent节点的启动参数中的token,重新将agent注册到新的server节点,但是因为集群数据丢失,可能需要重新安装应用,因此尽可能对server节点的数据进行周期性备份并妥善存储保管。

4、k3s是否可以外部存储系统?

当然是可以的,如果涉及到应用必须要访问持久化存储,那么也可以像kubernetes一样给其接入外部存储系统,但是不推荐这么做,因为边缘设备一般比较分散,网络环境也不稳定,外接存储系统会导致性能打折扣,因此建议:

  • 对于必须将数据存储在外部存储上的应用,可以通过nodeSelector限制其到某几个特定的比较可靠稳定的节点上,然后接入外部存储系统;

  • 对于daemonset类型的应用,非关键核心数据可以通过hostPath存储在宿主机系统上