Kubernetes部署Minio叢集存儲的選擇,使用DirectPV CSI作為分布式存儲的最佳實踐
個人了解淺談
1. 關于在kubernetes上部署分布式存儲服務,K8s存儲的選擇
-
非雲環境部署K8s Pod時存儲的選擇
在非雲環境部署Kubernets時,一般采用的都是本地的直連式存儲和檔案系統,如hostpath、或者local卷,即使是利用K8s存儲的PV卷,都需要本地已經有提前準備好的塊存儲或者已經建立好檔案目錄,若利用local卷還會有親和性問題的限制,node節點故障時,會因為local卷和node的綁定關系導緻pod排程失敗。
-
使用CSI存儲接口作為K8s的存儲
K8s也支援利用網絡存儲,如NAS、NFS等方式給k8s提供存儲資源,但是網絡存儲首先需要事先在每台節點部署網絡存儲服務不僅增加了複雜性,另外不可避免的問題就是網絡存儲服務具有單點故障,若服務出現問題不可用,将導緻資料丢失,影響到k8s的所有pod的資料。
2. 使用DirectPV作為部署k8s minio叢集存儲的最佳實踐
DirectPV
DirectPV是一個分布式持久卷管理器,是用于直連存儲(DAS)的容器存儲接口(CSI)驅動程式。
K8s hostpath、local和本地靜态配置都有的痛點即需要事先在node節點準備好可用的塊存儲或檔案系統,例如對插入的硬碟,或者磁盤陣列做分區格式化,檔案系統則需提前建立好k8s即将利用的挂載目錄,并且兩種方法都會有親和性限制,無法做到讓k8s自身的去排程讓資料卷分布在不同的node節點上。
在傳統的基于SAN或NASCSI 驅動程式(網絡 PV)上部署minio叢集的局限性
若利用傳統的SAN或者NAS的CSI存儲驅動(網絡PV)來為minio叢集提供存儲,minio叢集本身就分布式存儲和保障高可用的特點,不僅會在資料路徑中增加另一層複制/擦除編碼和額外的網絡躍點。這種額外的分解層還會導緻複雜性增加和性能下降的問題。
DirectPV優勢
而DirectPV正是為了解決這些問題,DirectPV做到了跨服器發現可用存儲資源、跨服器格式化存儲、建立供k8s PV使用的存儲池,由k8s API通過DirectPV CSI排程存儲資源為POD配置設定直連式存儲PV,分布式地在node節點建立符合PVC申請要求的PV。DirectPV建立的存儲資源統一由部署DirectPV的節點監視和維護。
通俗點講,即在master節點部署後DirectPV後,隻需在node節點插入硬碟或者組建磁盤陣列,後續的格式化隻需在安裝了DirectPV的master節點上操作,node節點無需後續操作,PV由k8s自行排程和建立,并由PV卷将資料持久化。
DirectPV局限性
DirectPV本質上是利用節點磁盤建立并挂載了一個挂載分區供k8s pod使用,始終還是規避不了節點單點故障和硬碟損壞的問題,并且資料的持久化受到由DirectPV配置設定的PV卷的限制。
minio叢集特性
-
分布式
minio叢集将資料分布在每個minio叢集節點上,每個叢集節點至少擁有4個驅動器,資料被均勻分布在每個叢集節點的驅動器上,一半的驅動器空間用于資料備份利用,一半的空間用于存儲。
-
高可用
minio叢集的高可用特性,即驅動器隻要有總數的N/2線上,即可完整的同步和還原資料,解決了硬碟單點故障導緻資料丢失的問題。隻要minio的叢集節點數量夠多,也能規避minio叢集節點故障大面積的驅動器掉線導緻存儲資料丢失的問題。
DirectPV結合Minio叢集突破DirectPV的局限性
每個minio叢集節點上由K8s排程,而每個叢集節點的驅動器使用的PV由DirectPV排程,也就是說驅動器實際使用的存儲資源是由DirectPV随機的從屬于K8s的DirectPV存儲池中配置設定出來的,那實際的資料會随機的分布在node節點上的硬碟上。
-
硬碟單點故障
若是k8s node節點本身使用的是JOBD存儲,那自然已經沒有硬碟單點故障的問題,即使沒有使用JOBD存儲,因為minio叢集存儲的資料是分布式地在各個不同minio叢集節點的驅動器上,本質上就是在各個k8
s node節點的不同硬碟上,隻要node節點硬碟數量夠多,很大程度上可以規避硬碟單點故障的問題
-
k8s node節點單點故障
同樣的,node節點上故障時将會有大量的PV不可用,進而導緻minio叢集驅動器大量的掉線,規避該問題的方法既是存在有大量的k8s node節點,保證明際的驅動器資料分布在不同的節點硬碟上
2. 部署實踐
2.1. 安裝使用DirectPV
DirectPV設計為輕量級,可擴充到1000個驅動器中的10個。它由三個元件組成:控制器、節點驅動程式、使用者界面
-
控制器
在進行卷聲明時,控制器會從無池驅動器統一調配卷。DirectPV知道pod的關聯限制,并将卷從本地驅動器配置設定到pod。請注意,每個群集隻運作一個活動的controller執行個體
-
節點驅動程式
節點驅動程式實作卷管理功能,例如發現、格式化、裝載和監視節點上的驅動器。每個存儲伺服器上都運作一個節點驅動程式執行個體。
-
使用者界面
存儲管理者可以使用kubectl CLI插件來選擇、管理和監視驅動器。基于Web的UI目前正在開發中。
2.2. 在K8s Master節點上部署Directpv
安裝先決條件
- 已經安裝Krew插件工具(參考博文:安裝Kubernetes Krew工具)
- Node節點有可用的磁盤
# 安裝directpv插件(未科學上網可能會下載下傳失敗,親測嘗試多次後即可成功)
kubectl krew install directpv
# 使用directpv插件在k8s叢集安裝directpv的元件
kubectl directpv install
# 檢視directpv資訊
kubectl directpv info
# 檢視可用的驅動器
kubectl directpv drives ls
# 選擇供directpv管理的驅動器進行格式化後加入存儲池{a...c}=a,b,c、{1...3}=1,2,3
kubectl directpv drives format --drives /dev/sd{a...f} --nodes directpv-{1...4}
#執行完畢後等待一會,使用kubectl directpv drives ls可用看到驅動器狀态為Ready,即可供PVC聲明使用
#--drives後接實踐磁盤分區位置,部落客的為:/dev/sd{b...c}
#--nodes後接k8s node節點的名稱,部落客的為:node0{1...2}
2.3. 使用DirectPV案例
2.3.1. 建立PVC
vim pvc-direct.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-pvc-2
namespace: default
spec:
storageClassName: directpv-min-io #Directpv使用的SC,directpv-min-io,在安裝directpv時自動建立
accessModes:
- ReadWriteOnce #注意directpv不支援多節點寫入模式
resources:
requests:
storage: 1024Mi #申請PV空間大小
kubectl create -f pvc-direct.yaml
2.3.2 建立使用Directpv PVC的Pod
vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: csipod-2
spec:
volumes:
- name: pvc-storage
persistentVolumeClaim:
claimName: csi-pvc-2 #指定使用剛剛建立的PVC:csi-pvc-2
containers:
- image: busybox:1.28
name: box
args: [/bin/sh, -c, while true; do echo "$(date)" >> /tmp/1.log && sleep 10; done]
resources:
requests:
cpu: 100m
volumeMounts:
- name: pvc-storage
mountPath: /tmp #PV挂載至容器裡的/tmp目錄
kubectl create -f pod.yaml
2.4. 檢視實際PV建立的位置
2.4.1. PV在Pod實際排程的節點上被建立,首先檢視Pod被排程到node2節點
2.4.2. 确認配置設定的pvc的名稱
2.4.3. 進入node2節點檢視到有兩個硬碟被用于directpv的存儲池,切換到/var/lib/direct-csi/mnt/
2.4.4. 使用tree指令檢視到pvc實際被建立在了38296a09-bc76-47f0-8861-d5bd52ff1855下
2.5. 測試挂載的PV
2.5.1. 在pv下建立檔案
2.5.2. 檢視pod的tmp目錄确認
2.5. 使用Directpv CSI建立PV提供給minio叢集使用
2.5.1. 使用Deployment部署minio叢集
- 每個驅動器需要對應一個PVC,即一個叢集至少建立四個PVC
- 這裡執行個體使用單節點minio叢集
2.5.2. 建立PVC
vim minio-pv.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-data-d0
namespace: default
spec:
accessModes:
- ReadWriteOnce
storageClassName: directpv-min-io
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-data-d1
namespace: default
spec:
accessModes:
- ReadWriteOnce
storageClassName: directpv-min-io
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-data-d2
namespace: default
spec:
accessModes:
- ReadWriteOnce
storageClassName: directpv-min-io
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-data-d3
namespace: default
spec:
accessModes:
- ReadWriteOnce
storageClassName: directpv-min-io
resources:
requests:
storage: 1Gi
kubectl create -f minio-pv.yaml
成功建立PVC
2.5.3. 建立Deployment
vim minio-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: minio
namespace: default
spec:
selector:
matchLabels:
name: minio
replicas: 1
template:
metadata:
labels:
name: minio
spec:
containers:
- name: minio
env:
- name: MINIO_ROOT_USER
value: minioadmin
- name: MINIO_ROOT_PASSWORD
value: miniopassword
image: docker.io/minio/minio
args:
- server
- /data0
- /data1
- /data2
- /data3
- --console-address
- ":9090"
ports:
- containerPort: 9000
- containerPort: 9090
volumeMounts:
- name: data0
mountPath: /data0
- name: data1
mountPath: /data1
- name: data2
mountPath: /data2
- name: data3
mountPath: /data3
volumes:
- name: data0
persistentVolumeClaim:
claimName: pvc-data-d0
- name: data1
persistentVolumeClaim:
claimName: pvc-data-d1
- name: data2
persistentVolumeClaim:
claimName: pvc-data-d2
- name: data3
persistentVolumeClaim:
claimName: pvc-data-d3
kubectl create -f minio-deployment.yaml
2.5.4. directpv成功配置設定PV給pod使用
pod成功建立
2.5.5. 暴露Minio叢集通路端口(pod内部端口為9090,主控端即k8s叢集端口為30513)
2.5.7. 登入minio控制台(使用浏覽器:http://{k8s-address}:30513通路)
- 賬号:minioadmin
- 密碼:miniopassword
2.5.8. 确認驅動器
手動建立使用DirectPV CSI的PVC部署K8s Minio叢集的實踐分享至此完畢,使用Depolyment方式部署的Minio叢集維護起來相對麻煩,而最佳實踐使用MinIO Operator工具建立Minio叢集,是最推薦的方式。