生產用例 | 百臺邊緣裝置上的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收發訊息。因此:
-
一部分元件與kubeedge重疊了;
-
部署不方便,kubeedge要求在各個節點上以kubeadmin部署kubernetes叢集(0.6版本,現在已經更新至1.1版本,不知道現在是否有更簡便快捷的形式),對網路環境不好的邊緣側裝置有較大難度;
-
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叢集的多節點快速自動化部署,如有需要,可以聯絡[email protected]。
各個元件版本資訊:
-
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的速度很慢,線上安裝耗時很長,因此推薦採用離線部署方式部署。
以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支援眾多的安裝引數和選型,詳細請參考官方檔案:
完成之後,檢查叢集狀態:
# 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儲存在宿主機系統上