本文由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主頁：

https://github.com/rancher/k3s/releases

由于國內訪問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支持眾多的安裝參數和選型，詳細請參考官方文檔：

https://rancher.com/docs/k3s/latest/en/installation/

完成之后，檢查集群狀態：

# 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存儲在宿主機系統上