iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 24
0
DevOps

從開源雲到邊緣運算系列 第 24

[Day 24]K3s 上 PV / PVC 驗證與叢集技術總結分析

本篇是最後一篇k3s的功能測試了,在主功能的簡介測試之中,我們最後以PV/PVC進行遠端分享儲存服務做個結束,本篇會以NFS服務建立、k3s PV/PVC兩個功能做開發,驗證目前k3s是否支援PV/PVC掛載分享是儲存池功能,最後總結一下目前k3s功能上面的訴求,再加入KubernetesKubeEdgek3s研發方向的功能比較,後續會再提供一些實作方向給各位去發想。

NFS Server 服務建立

Server 端

  • 請先準備一台 VM 或是 Container 進行 NFS Server 服務安裝。

安裝套件

  • 功能指令
apt-get update
apt-get install nfs-kernel-server nfs-common -y

新增共享資料夾

  • 功能指令
cd /var
mkdir nfs-k8s

設定服務(共享資料夾)

  • 功能指令
echo "/var/nfs-k8s    *(rw,sync,no_root_squash,no_all_squash)" >> /etc/exports

設定服務(共享資料夾)

  • 功能指令
echo "/var/nfs-k8s    *(rw,sync,no_root_squash,no_all_squash)" >> /etc/exports

重啟服務

  • 功能指令
systemctl restart nfs-kernel-server 

獲取 NFS_Server 服務 IP

  • 功能指令
ifconfig 
  • 這邊的的功能是後續連線時,需要指定NFS_Server的網路位置。

Agent 端

  • k3s Agent 端點都需安裝,使各個k3s_Agent(含 Server)都有NFS_Server連線功能
  • 功能指令
apt-get install nfs-common -y

PV 服務

服務簡介

PV 全名為PersistentVolume,是由 Master 配置於叢集中的一個儲存,透過不同的**Container Storage Interface(CSI)**進行存取使用,可由 NFSCeph等網路儲存系統進行共享,協助網路存儲磁碟的資源分配與Volume切割,設計為叢集中的儲存載體資源,Pod 取用方式類似於一般 PC 對於 NAS/FTP等網路儲存服務一樣。

PV 的生命週期:
Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

服務建立

服務設計

  • 服務描述檔案
apiVersion: v1
kind: PersistentVolume
metadata:
  namespace: default
  name: pv001
spec:
  capacity:
    storage: 5G
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  claimRef:
    namespace: default
    name: pv-claim
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /var/nfs-k8s
    server: 192.168.1.41
  • 執行結果(示意圖)
    https://ithelp.ithome.com.tw/upload/images/20191010/20121071KQYpF5ODSn.png

服務派送

  • 服務派送指令
k3s kubectl create -f ${pv-file}
  • 執行結果(示意圖)
    https://ithelp.ithome.com.tw/upload/images/20191010/20121071UAo9Zu6vCS.png

服務驗證

  • 服務派送指令
k3s kubectl get pv ${pv-name} -o wide
  • 執行結果(示意圖)
    https://ithelp.ithome.com.tw/upload/images/20191010/2012107157MU8r6RVp.png

PVC 服務

服務簡介

PVC 全名為 PersistentVolumeClaim,是一個叢集中請求共享儲存資源的方式,從目前的PV之中找尋可用且最接近請求大小(一定大於等於請求容量)的PV,在叢集中行為類似啟動一個Pod。

PVC 取用 PV

  • PVC 會消耗(取用) PV 資源,PV在叢集中需先存在,而PVC對應規格進行取用,而取用後則將PV & PVC相互綁定,因此總PV數量(PV內設計分享容量)降低,因此在介紹上多半說為PVC 消耗 PV,實際其實為PVC取用PV並綁定無法繳付給其他PVC使用。
  • PVC 可以請求特定大小和進入模式(例如,可以一次讀/寫或多次只讀),這功能需要對應PV的規格,PVPVC兩邊相符合才可進行PVC取用PV的調度流程。

PVC 的生命週期:
Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

服務建立

服務設計

  • 服務描述檔案
apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
  name: pv-claim
  labels:
    app: mysql-pod
  namespace: default
spec:
  accessModes:
   - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  • 執行結果(示意圖)
    https://ithelp.ithome.com.tw/upload/images/20191010/201210717qM5BkpXQY.png

服務派送

  • 服務派送指令
k3s kubectl create -f ${pvc-file}
  • 執行結果(示意圖)
    https://ithelp.ithome.com.tw/upload/images/20191010/20121071gxp6yCQkBv.png

服務驗證

  • 服務派送指令
k3s kubectl get pvc ${pvc-name} -o wide
  • 執行結果(示意圖)
    https://ithelp.ithome.com.tw/upload/images/20191010/20121071fvUgmY6YCL.png

k3s 服務總結

在先前我們測試了許多kubernetes相關的服務功能,我們一路從Node、Pod、Deployment、Service、RollingUpdate、Node_Affinity、Pod_Affinity,加上本篇的 PV/PVC,,在kubernetesk3s之中功能基本上相同,但基於k3s支援ARM架構的看法,所以目前k3s的輕量化是前往邊緣端協助自建雲,在邊緣自建型態的輕量化叢集上提供快速安裝部署的方案,有在玩樹莓派(RaspberryPi)的不訪可以參考目前的k3s拉~(國外好像有大神用5片RaspberryPi實作了叢集),後續有要研究的捧油,叢集遠端控制從Web_GUI開始的話,也是後續輕量化簡易叢集的一個方案,可搭配kubernetes_DashBoard&&Rancher_DashBoard(~~個人大推~~~~),這邊做簡單的總結,相望大家繼續往下研究拉~。

大神的網址(跪下膜拜):https://blog.alexellis.io/test-drive-k3s-on-raspberry-pi/


雲端到邊緣叢集設計比較

總結測試功能比較圖

https://ithelp.ithome.com.tw/upload/images/20191010/20121071NDjIGclP3B.png

叢集設計架構比較

kubernetes

雲端叢集最大化的始祖,功能上都是相依著他開發的,目前盡在雲端的較為高階主機上進行搭建,主要項目為:提高運算服務穩定性不間斷軟體服務維運網路儲存備份服務資料指定服務所需資源設計副本機制提供備援服務解決網路服務吞吐延遲功能,而這些功能多半需要大型算力主機維運服務,在調度多個節點上的Pod的服務調度器(kubernetes_controller),其需要強大的硬體資源做後援,而在接收調度服務與後續維運cluster節點上,其也需要承接多種/多個Pod服務;而kubernetes上,目前也只支援區網節點添加與驗證機制(有錯請糾正),意指所有的cluster節點都在同一個區網之中,在Internet對外網路中,仍沒有對應的服務鏈結處理方案(撇除VPN跨域連線機制),在架構上其主要方向為雲端服務維運叢集性質,對於邊緣運算顯然是個未有個開發方案。

kubeEdge

這叢集架構是華為(Haiwei)所提出的,設計上從原生的kubernetes出發,藉由原kubernetes的調度機制,協助叢集節點(Edge_Node)上Pod調度使用,並在API-Server轉介出一個接口,透過通訊轉譯將API-Server資料轉換成WebSocket提供外部連線使用,在Master(Controller)節點實作一個需要註冊的節點外殼層,並在透過WebSocket進行節點認證與註冊使用,提供一個節點在外部網路進行註冊的功能方案(外網註冊邊緣節點真的會通!!!),在註冊之後進行Edge_NodeMaster_Node之間的WebSocket通道開通達成兩端通訊橋梁建立,將邊緣端的節點資料進行定期發送確認生命狀態,並在原本需要受到Master端管控的節點進行修改,透過儲存以派送到該節點的資料進行資料庫轉存,在邊節點端(Edge_Node)進行自我維運的功能,在原生kubernetes上需要不斷的同步資料的cluster節點,改變成一個可自我監控維運的節點,在Cloud端斷線時Edge端可自我監測Pod執行狀態並重新啟動,而當CloudEdge重新連線則更新目前服務,而其他改變也修改了kubernetes之上的功能,如:ReplicaSet邊緣節點不使用副本降低服務消耗資源、Service架構使用HostPort直接使用主機埠號,不需進行Service設計即可直接使用Pod內的服務,相較於kubernetes的叢集架構,它提供了一個外部網路節點加入機制雲端管控邊緣節點機制邊緣端自我生命監測維運機制邊緣端服務直接提供對外使用降低邊緣運算資源損耗的關閉副本機制Pod內服務直接對外維運使用

k3s

Rancher_Lab所提出的k3s叢集的功能與用途的分析上,我們首先看到的是它具有kubernetes_certified,意指的他在架構上基本上Followkubernetes的開發演進之中,他即是對於目前ARM架構支援叢集化搭建的叢集,相較於原生kubernetesMaster_Node之上需要關閉Swap2G_Ram2Core_CPU的相關基礎設施的限制之下,他可以在ARM架構的Raspberry_Pi_3_B+之上進行Master節點搭建,並以快速與輕量化的搭建方式,讓使用者快速安裝與部屬節點,對於目前的kubernetes中需要以kubeadmkubectlkubeletDocker相關套件進行服務支撐,k3s在精簡功能的封裝下在40MB安裝包完成內建containerdkubectlkubeletFlannel_CNICore_DNS等服務,而在眾多輕量級系統記憶體(RAM)記憶體寸土寸金的狀況下,對於記憶體的使用也是相對較低的約40MB(k8s_Master約1GB),並在此優化之下提供使用者進行相依套件套用服務,如:使用Docker置換containerdFlannel_CNI改其他CNI等,而在功能精簡的情況下,他的調度功能在前幾篇的功能驗證之下,發現對於kubernetes的功能基本上都可使用,並且在架構轉換後仍可使用kubernetes_DashBoardRancher_DashBoard進行納管監控的功能,在輕量化叢集的設計中,在現階段算是完美的取勝(讚嘆Rancher_Lab)。


上一篇
[Day 23]K3s 部署 - Affinity 功能校驗 - Pod 篇
下一篇
[Day 25] Project EVE介紹
系列文
從開源雲到邊緣運算30

尚未有邦友留言

立即登入留言