Kubernetes存儲系統(tǒng)數(shù)據(jù)持久化管理詳解
引言
Kubernetes為了能更好的支持有狀態(tài)應(yīng)用的數(shù)據(jù)存儲問題,除了基本的HostPath和EmptyDir提供的數(shù)據(jù)持久化方案之外,還提供了PV,PVC和StorageClass資源對象來對存儲進(jìn)行管理。
PV的全稱是Persistent Volume(持久化卷),是對底層數(shù)據(jù)存儲的抽象,PV由管理員創(chuàng)建、維護(hù)以及配置,它和底層的數(shù)據(jù)存儲實現(xiàn)方法有關(guān),比如Ceph,NFS,ClusterFS等,都是通過插件機(jī)制完成和共享存儲對接。
PVC的全稱是Persistent Volume Claim(持久化卷聲明),我們可以將PV比喻為接口,里面封裝了我們底層的數(shù)據(jù)存儲,PVC就是調(diào)用接口實現(xiàn)數(shù)據(jù)存儲操作,PVC消耗的是PV的資源。
StorageClass是為了滿足用于對存儲設(shè)備的不同需求,比如快速存儲,慢速存儲等,通過對StorageClass的定義,管理員就可以將存儲設(shè)備定義為某種資源類型,用戶根據(jù)StorageClass的描述可以非常直觀的知道各種存儲資源的具體特性,這樣就可以根據(jù)應(yīng)用特性去申請合適的資源了。
安裝存儲系統(tǒng)
存儲系統(tǒng)的選擇有很多,常見的有NFS、Ceph、GlusterFS、FastDFS等,具體使用什么根據(jù)企業(yè)情況而定。在這里使用的是NFS,下面簡單介紹一下如何安裝。
(1)安裝服務(wù)
$ yum install nfs-utils rpcbind -y
(2)創(chuàng)建共享目錄
$ mkdir /data/k8s -p
(3)配置NFS配置文件
$ vim /etc/exports /data/k8s *(rw,sync,no_root_squash)
(4)啟動服務(wù)
$ systemctl start rpcbind $ systemctl start nfs $ systemctl enable rpcbind $ systemctl enable nfs
(5)測試
$ showmount -e 192.168.205.128 Export list for 192.168.205.128: /data/k8s *
PS:所有節(jié)點都需要安裝NFS客戶端
PV
PV(Persistent Volume)作為Kubernetes存儲設(shè)備,可以由管理員提前配置,也可以通過StorageClass來動態(tài)供應(yīng)。
PV是集群資源,可以通過kubectl explain pv來查看如何配置,主要包括存儲能力,訪問模式,存儲類型,回收信息等關(guān)鍵信息。例如:
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv01
labels:
storage: pv
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 1Gi
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data/k8s
server: 192.168.205.128
參數(shù)說明:
(1)、accessMode:訪問模式,有ReadWriteOnce,ReadOnlyMany,ReadWriteMany。其中:
- ReadWriteOnce:表示具有讀寫權(quán)限,但是只能被一個node掛載一次
- ReadOnlyMany:表示具有只讀權(quán)限,可以被多個node多次掛載
- ReadWriteMany:表示具有讀寫權(quán)限,可以被多個node多次掛載
(2)、capacity:持久卷資源和容量的描述,存儲大小是唯一可設(shè)置或請求的資源。
(3)、persistentVolumeReclaimPolicy:回收策略,也就是釋放持久化卷時的策略,其有以下幾種:
- Retain:保留數(shù)據(jù),如果要清理需要手動清理數(shù)據(jù),默認(rèn)的策略;
- Delete:刪除,將從Kubernetes中刪除PV對象,以及外部基礎(chǔ)設(shè)施中相關(guān)的存儲資產(chǎn),比如AWS EBS, GCE PD, Azure Disk, 或Cinder volume;
- Recycle:回收,清楚PV中的所有數(shù)據(jù),相當(dāng)于執(zhí)行rm -rf /pv-volume/*;
創(chuàng)建過后,PV的狀態(tài)如下:
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
my-pv01 1Gi RWO Recycle Available 5s
$ kubectl describe pv my-pv01
Name: my-pv01
Labels: storage=pv
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass:
Status: Available
Claim:
Reclaim Policy: Recycle
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: NFS (an NFS mount that lasts the lifetime of a pod)
Server: 192.168.205.128
Path: /data/k8s
ReadOnly: false
Events: <none>
當(dāng)前PV的狀態(tài)是Available,表示處于隨時可用狀態(tài)。PV總共有以下四種狀態(tài):
- Available(可用):表示可用狀態(tài),還未被任何 PVC 綁定
- Bound(已綁定):表示 PVC 已經(jīng)被 PVC 綁定
- Released(已釋放):PVC 被刪除,但是資源還未被集群重新聲明
- Failed(失?。罕硎驹?PV 的自動回收失敗
單純的創(chuàng)建PV,我們并不能直接使用,需要使用PVC(Persistent Volume Claim)來進(jìn)行聲明。
PVC
PVC(Persistent Volume Claim)用于表達(dá)用戶對存儲的需求,申請PVC會消耗掉PV的資源,可以通過kubectl explain pvc來查看幫助文檔。
在上一節(jié)我們創(chuàng)建了PV,現(xiàn)在要申明PVC,如下:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-test
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
spec參數(shù)說明:
(1)、accessModes:主要定義卷所應(yīng)該擁有的訪問模式
(2)、resources:主要定義卷應(yīng)該擁有的最小資源
(3)、dataSource:定義如果提供者具有卷快照功能,就會創(chuàng)建卷,并將數(shù)據(jù)恢復(fù)到卷中,反之不創(chuàng)建
(4)、selector:定義綁定卷的標(biāo)簽查詢
(5)、storageClassName:定義的storageClass的名字
(6)、volumeMode:定義卷的類型
(7)、volumeName:需要綁定的PV的名稱鏈接
創(chuàng)建過后,查看PV和PVC的狀態(tài),如下:
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-test Bound my-pv01 1Gi RWO 2s $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE my-pv01 1Gi RWO Recycle Bound default/pvc-test 20m
我們從上面可以看到pvc處于Bound狀態(tài),Bound的VOLUME是my-pv01,我們再看pv的狀態(tài)有Available變?yōu)锽ound,其CLAIM是default/pvc-test,其中default為namespace名稱。
在上面我們創(chuàng)建了一個PVC,其綁定了我們創(chuàng)建的PV,如果此時我們再創(chuàng)建一個PVC,結(jié)果又會如何?我們copy以下上面的PVC文件,將其名稱改一下,如下:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-test2
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
然后查看PVC的狀態(tài),如下
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-test Bound my-pv01 1Gi RWO 3m57s pvc-test2 Pending 4s
我們可以看到我們剛創(chuàng)建的pvc-test2的STATUS處于Pending狀態(tài),這是由于集群里聲明的PV都使用完了,PVC在申請的時候沒有找到合適的PV,所以處于這個狀態(tài),這時候如果我們創(chuàng)建一個新的并滿足要求的PV,則可以看到這個PVC會處于Bound狀態(tài)。如下:
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE my-pv01 1Gi RWO Recycle Bound default/pvc-test 27m my-pv02 1Gi RWO Recycle Available 5s $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-test Bound my-pv01 1Gi RWO 6m50s pvc-test2 Bound my-pv02 1Gi RWO 2m57s
PVC也在申領(lǐng)PV的時候也不是隨意申領(lǐng)的,它需要符合以下要求:
(1)PVC申領(lǐng)的模式要和PV匹配上,假如PVC的模式是ReadWriteOnce,而PV的模式是ReadWriteMany,則申領(lǐng)部成功。
(2)PVC申領(lǐng)的容量要小于等于PV的容量,否則申請不成功。
(3)一個PV只能綁定一個PVC
另外,如果我們的PVC需求的容量小于PV的可用容量,綁定的容量是PV的可用容量。
StorageClass
上面介紹的PV和PVC模式是需要運維人員先創(chuàng)建好PV,然后開發(fā)人員定義好PVC進(jìn)行一對一的Bond,但是如果PVC請求成千上萬,那么就需要創(chuàng)建成千上萬的PV,對于運維人員來說維護(hù)成本很高,Kubernetes提供一種自動創(chuàng)建PV的機(jī)制,叫StorageClass,它的作用就是創(chuàng)建PV的模板。
具體來說,StorageClass會定義一下兩部分:
- PV的屬性 ,比如存儲的大小、類型等;
- 創(chuàng)建這種PV需要使用到的存儲插件,比如Ceph等;
有了這兩部分信息,Kubernetes就能夠根據(jù)用戶提交的PVC,找到對應(yīng)的StorageClass,然后Kubernetes就會調(diào)用 StorageClass聲明的存儲插件,創(chuàng)建出需要的PV。
這里我們以NFS為例,要使用NFS,我們就需要一個nfs-client的自動裝載程序,我們稱之為Provisioner,這個程序會使用我們已經(jīng)配置好的NFS服務(wù)器自動創(chuàng)建持久卷,也就是自動幫我們創(chuàng)建PV。說明:
- 自動創(chuàng)建的PV會以{pvcName}-${pvName}的目錄格式放到NFS服務(wù)器上;
- 如果這個PV被回收,則會以archieved-{pvcName}-${pvName}這樣的格式存放到NFS服務(wù)器上;
安裝NFS Provisioner
(1)創(chuàng)建ServiceAccount,為NFS Provisioner授權(quán)
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-clusterrole
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: nfs-client-provisioner-clusterrolebinding
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-clusterrole
apiGroup: rbac.authorization.k8s.io
(2)創(chuàng)建NFS Provisioner
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-prosioner
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-prosioner
template:
metadata:
labels:
app: nfs-client-prosioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-prosioner
image: registry.cn-hangzhou.aliyuncs.com/rookieops/nfs-client-provisioner:4.0
imagePullPolicy: IfNotPresent
volumeMounts:
- name: nfs-client-root
mountPath: /data/pv
env:
- name: PROVISIONER_NAME
value: rookieops/nfs
- name: NFS_SERVER
value: 192.168.205.128
- name: NFS_PATH
value: /data/k8s
volumes:
- name: nfs-client-root
nfs:
server: 192.168.205.128
path: /data/k8s
執(zhí)行完成后,查看NFS Provisioner的狀態(tài),如下:
$ kubectl get po NAME READY STATUS RESTARTS AGE nfs-client-prosioner-54d64dfc85-b4ht4 1/1 Running 0 10s
使用StorageClass
上面已經(jīng)創(chuàng)建好NFS Provisioner,現(xiàn)在我們可以直接創(chuàng)建StroageClass,如下:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs provisioner: rookieops/nfs
每個 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段, 這些字段會在 StorageClass 需要動態(tài)分配 PersistentVolume 時會使用到。
在配置StorageClass的時候,如果沒有指定reclaimPolicy,則默認(rèn)是Delete,除此之外,還有Retain。
StorageClass 對象的命名很重要,用戶使用這個命名來請求生成一個特定的類。當(dāng)創(chuàng)建 StorageClass 對象時,管理員設(shè)置 StorageClass 對象的命名和其他參數(shù),一旦創(chuàng)建了對象就不能再對其更新。
使用kubectl apply -f sc.yaml創(chuàng)建StorageClass,創(chuàng)建完成過后如下:
$ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE nfs rookieops/nfs Delete Immediate false 9m41s
現(xiàn)在,我們就可以使用動態(tài)存儲申領(lǐng)PVC,如下:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-from-sc
spec:
accessModes:
- ReadWriteOnce
storageClassName: nfs
resources:
requests:
storage: 1Gi
使用kubectl apply -f pvc-from-sc.yaml,查看PVC創(chuàng)建情況,如下:
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-from-sc Bound pvc-a4a71b8c-5664-4d1a-b286-9e4adcf6f96a 1Gi RWO nfs 8s $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-a4a71b8c-5664-4d1a-b286-9e4adcf6f96a 1Gi RWO Delete Bound default/pvc-from-sc nfs 86s
可以看到自動創(chuàng)建了一個PV,然后和PVC進(jìn)行綁定。
為了方便使用,有時候會給集群默認(rèn)設(shè)置一個StorageClass,以便在需要使用動態(tài)存儲,但是未聲明的情況下使用默認(rèn)的動態(tài)存儲。設(shè)置方式如下:
$ kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
通過向其添加 storageclass.kubernetes.io/is-default-class 注解來將特定的 StorageClass 標(biāo)記為默認(rèn)。當(dāng)集群中存在默認(rèn)的 StorageClass 并且用戶創(chuàng)建了一個未指定 storageClassName 的 PersistentVolumeClaim 時, DefaultStorageClass 準(zhǔn)入控制器會自動向其中添加指向默認(rèn)存儲類的 storageClassName 字段。
請注意,集群上最多只能有一個 默認(rèn) 存儲類,否則無法創(chuàng)建沒有明確指定 storageClassName 的 PersistentVolumeClaim。
如果要取消默認(rèn)StorageClass,只需要把注解設(shè)置為flase即可,如下:
$ kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
如果我們要在Pod中使用PVC,則直接如下聲明:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
volumeMounts:
- name: nfs-pvc
mountPath: /mnt
restartPolicy: Never
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: pvc-from-sc
可以進(jìn)入容器,到掛載目錄輸出,例如:
$ kubectl exec -it nginx -- /bin/bash root@nginx:/mnt# echo "test" > /mnt/text.txt
然后到NFS對應(yīng)的目錄查看是否一致。
$ cd /data/k8s/default-pvc-from-sc-pvc-a4a71b8c-5664-4d1a-b286-9e4adcf6f96a $ cat text.txt test
這表示Pod使用持久化成功。
總結(jié)
在Kubernetes中,雖然我們建議使用無狀態(tài)應(yīng)用,但是對于有些特殊應(yīng)用,數(shù)據(jù)持久化還是必不可少的。數(shù)據(jù)持久化的難度不在于創(chuàng)建幾個PV或者PVC,而是后端的存儲系統(tǒng),比如Ceph,如果使用它作為后端存儲,你必須對其非常熟悉,方便在出問題的時候好排查,如果你對這些存儲系統(tǒng)都不熟悉,在使用的時候可能會出現(xiàn)很多問題。
以上就是Kubernetes存儲系統(tǒng)數(shù)據(jù)持久化管理詳解的詳細(xì)內(nèi)容,更多關(guān)于Kubernetes數(shù)據(jù)持久化管理的資料請關(guān)注腳本之家其它相關(guān)文章!
- kubernetes數(shù)據(jù)持久化StorageClass動態(tài)供給實現(xiàn)詳解
- Kubernetes?controller?manager運行機(jī)制源碼解析
- Kubernetes Informer數(shù)據(jù)存儲Index與Pod分配流程解析
- Kubernetes scheduler啟動監(jiān)控資源變化解析
- Kubernetes ApiServer三大server權(quán)限與數(shù)據(jù)存儲解析
- Kubernetes Visitor設(shè)計模式及發(fā)送pod創(chuàng)建請求解析
- kubernetes數(shù)據(jù)持久化PV?PVC深入分析詳解
相關(guān)文章
Kubernetes?權(quán)限管理認(rèn)證鑒權(quán)詳解
這篇文章主要為大家介紹了Kubernetes?權(quán)限管理認(rèn)證鑒權(quán)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11
ES業(yè)務(wù)數(shù)據(jù)遷移遇到的精度問題BUG
這篇文章主要為大家介紹了ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問題,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-06-06
解決k8s namespace 一直處于 Terminating 狀態(tài)的問題
這篇文章主要介紹了k8s namespace 一直處于 Terminating 狀態(tài)的解決方法,以下的 tool 為 Terminating 狀態(tài)的 namespace,下面相關(guān)的一些操作記得將 tool 修改成自己的 namespace 名稱,需要的朋友可以參考下2022-10-10
K8s中的臨時容器Ephemeral?Containers使用
這篇文章主要介紹了K8s中的臨時容器Ephemeral?Containers使用,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-07-07
Kubernetes中使用PersistentVolume掛載云盤方式
這篇文章主要介紹了Kubernetes中使用PersistentVolume掛載云盤方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-02-02

