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

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)**進行存取使用，可由 NFS、Ceph等網路儲存系統進行共享，協助網路存儲磁碟的資源分配與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

• 執行結果(示意圖)
  

服務派送

• 服務派送指令

k3s kubectl create -f ${pv-file}

• 執行結果(示意圖)
  

服務驗證

• 服務派送指令

k3s kubectl get pv ${pv-name} -o wide

• 執行結果(示意圖)
  

PVC 服務

服務簡介

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

PVC 取用 PV

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

• 執行結果(示意圖)
  

服務派送

• 服務派送指令

k3s kubectl create -f ${pvc-file}

• 執行結果(示意圖)
  

服務驗證

• 服務派送指令

k3s kubectl get pvc ${pvc-name} -o wide

• 執行結果(示意圖)
  

k3s 服務總結

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

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

雲端到邊緣叢集設計比較

總結測試功能比較圖

叢集設計架構比較

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_Node與Master_Node之間的WebSocket通道開通達成兩端通訊橋梁建立，將邊緣端的節點資料進行定期發送確認生命狀態，並在原本需要受到Master端管控的節點進行修改，透過儲存以派送到該節點的資料進行資料庫轉存，在邊節點端(Edge_Node)進行自我維運的功能，在原生kubernetes上需要不斷的同步資料的cluster節點，改變成一個可自我監控維運的節點，在Cloud端斷線時Edge端可自我監測Pod執行狀態並重新啟動，而當Cloud與Edge重新連線則更新目前服務，而其他改變也修改了kubernetes之上的功能，如：ReplicaSet邊緣節點不使用副本降低服務消耗資源、Service架構使用HostPort直接使用主機埠號，不需進行Service設計即可直接使用Pod內的服務，相較於kubernetes的叢集架構，它提供了一個外部網路節點加入機制、雲端管控邊緣節點機制、邊緣端自我生命監測維運機制、邊緣端服務直接提供對外使用、降低邊緣運算資源損耗的關閉副本機制、Pod內服務直接對外維運使用。

k3s

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