生產用例 | 百臺邊緣設備上的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

一、在邊緣計算中，每每涉及到訪問硬件資源，如何從容器內部訪問硬件資源？

Linux系統中，全部的硬件資源都體現爲/dev/目錄下面的一個設備，所以只要可以訪問/dev/目錄下面的設備文件便可，有的同窗會說，那是否是將/dev/目錄掛載到容器裏面就能夠了呢？通過個人實踐證實不行，由於掛載到容器裏面，即使容器裏面是以root用戶運行，然是仍舊有可能沒法訪問一些特殊資源文件，也就是說容器中的「root」用戶與宿主機的root用戶在訪問權限上仍是有差異。只須要將容器的運行模式設置爲「privileged」便可，以下：

resources:
  limits:
    cpu: 300m
    memory: 512Mi
  requests:
    cpu: 50m
    memory: 256Mi
securityContext:
  privileged: true
複製代碼

二、如何備份集羣數據？

k3s集羣數據所有存儲在/var/lib/rancher下面，在/etc/rancher、/etc/kubernetes下面會存儲一些配置文件和證書，所以咱們能夠週期性備份這幾個目錄的數據便可。也能夠給k3s server節點掛載一個高可靠性的存儲設備。

三、節點宕機怎麼恢復？

對於agent節點，邊緣節點只負責一個小區域的業務，單個節點宕機對整個集羣業務影響頗有限，只須要從新啓動將節點加入集羣中便可恢復業務運行。對於server節點，若是有數據備份，能夠用數據備份進行恢復（將備份數據放置到對應的目錄從新按照原有參數啓動server節點服務便可），若是沒有備份，那麼從新安裝一個server節點，更改agent節點的啓動參數中的token，從新將agent註冊到新的server節點，可是由於集羣數據丟失，可能須要從新安裝應用，所以儘量對server節點的數據進行週期性備份並妥善存儲保管。

四、k3s是否能夠外部存儲系統？

固然是能夠的，若是涉及到應用必需要訪問持久化存儲，那麼也能夠像kubernetes同樣給其接入外部存儲系統，可是不推薦這麼作，由於邊緣設備通常比較分散，網絡環境也不穩定，外接存儲系統會致使性能打折扣，所以建議：

• 對於必須將數據存儲在外部存儲上的應用，能夠經過nodeSelector限制其到某幾個特定的比較可靠穩定的節點上，而後接入外部存儲系統；

• 對於daemonset類型的應用，非關鍵核心數據能夠經過hostPath存儲在宿主機系統上