Kubernetes存儲系統(tǒng)數(shù)據(jù)持久化管理詳解

更新時(shí)間：2022年11月24日 15:53:01 作者：運(yùn)維開發(fā)故事

這篇文章主要為大家介紹了Kubernetes存儲系統(tǒng)數(shù)據(jù)持久化管理詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

引言

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ù)存儲實(shí)現(xiàn)方法有關(guān)，比如Ceph，NFS，ClusterFS等，都是通過插件機(jī)制完成和共享存儲對接。

PVC的全稱是Persistent Volume Claim（持久化卷聲明），我們可以將PV比喻為接口，里面封裝了我們底層的數(shù)據(jù)存儲，PVC就是調(diào)用接口實(shí)現(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）啟動(dòng)服務(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é)點(diǎn)都需要安裝NFS客戶端

PV

PV（Persistent Volume）作為Kubernetes存儲設(shè)備，可以由管理員提前配置，也可以通過StorageClass來動(dòng)態(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)限，但是只能被一個(gè)node掛載一次
ReadOnlyMany：表示具有只讀權(quán)限，可以被多個(gè)node多次掛載
ReadWriteMany：表示具有讀寫權(quán)限，可以被多個(gè)node多次掛載

（2）、capacity：持久卷資源和容量的描述，存儲大小是唯一可設(shè)置或請求的資源。

（3）、persistentVolumeReclaimPolicy：回收策略，也就是釋放持久化卷時(shí)的策略，其有以下幾種：

Retain：保留數(shù)據(jù)，如果要清理需要手動(dòng)清理數(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，表示處于隨時(shí)可用狀態(tài)。PV總共有以下四種狀態(tài)：

Available（可用）：表示可用狀態(tài)，還未被任何 PVC 綁定
Bound（已綁定）：表示 PVC 已經(jīng)被 PVC 綁定
Released（已釋放）：PVC 被刪除，但是資源還未被集群重新聲明
Failed（失?。罕硎驹?PV 的自動(dòng)回收失敗

單純的創(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)建了一個(gè)PVC，其綁定了我們創(chuàng)建的PV，如果此時(shí)我們再創(chuàng)建一個(gè)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在申請的時(shí)候沒有找到合適的PV，所以處于這個(gè)狀態(tài)，這時(shí)候如果我們創(chuàng)建一個(gè)新的并滿足要求的PV，則可以看到這個(gè)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的時(shí)候也不是隨意申領(lǐng)的，它需要符合以下要求：

（1）PVC申領(lǐng)的模式要和PV匹配上，假如PVC的模式是ReadWriteOnce，而PV的模式是ReadWriteMany，則申領(lǐng)部成功。

（2）PVC申領(lǐng)的容量要小于等于PV的容量，否則申請不成功。

（3）一個(gè)PV只能綁定一個(gè)PVC

另外，如果我們的PVC需求的容量小于PV的可用容量，綁定的容量是PV的可用容量。

StorageClass

上面介紹的PV和PVC模式是需要運(yùn)維人員先創(chuàng)建好PV，然后開發(fā)人員定義好PVC進(jìn)行一對一的Bond，但是如果PVC請求成千上萬，那么就需要?jiǎng)?chuàng)建成千上萬的PV，對于運(yùn)維人員來說維護(hù)成本很高，Kubernetes提供一種自動(dòng)創(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，我們就需要一個(gè)nfs-client的自動(dòng)裝載程序，我們稱之為Provisioner，這個(gè)程序會使用我們已經(jīng)配置好的NFS服務(wù)器自動(dòng)創(chuàng)建持久卷，也就是自動(dòng)幫我們創(chuàng)建PV。說明：

自動(dòng)創(chuàng)建的PV會以{pvcName}-${pvName}的目錄格式放到NFS服務(wù)器上；
如果這個(gè)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

每個(gè) StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段，這些字段會在 StorageClass 需要?jiǎng)討B(tài)分配 PersistentVolume 時(shí)會使用到。

在配置StorageClass的時(shí)候，如果沒有指定reclaimPolicy，則默認(rèn)是Delete，除此之外，還有Retain。

StorageClass 對象的命名很重要，用戶使用這個(gè)命名來請求生成一個(gè)特定的類。當(dāng)創(chuàng)建 StorageClass 對象時(shí)，管理員設(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)在，我們就可以使用動(dòng)態(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

可以看到自動(dòng)創(chuàng)建了一個(gè)PV，然后和PVC進(jìn)行綁定。

為了方便使用，有時(shí)候會給集群默認(rèn)設(shè)置一個(gè)StorageClass，以便在需要使用動(dòng)態(tài)存儲，但是未聲明的情況下使用默認(rèn)的動(dòng)態(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)建了一個(gè)未指定 storageClassName 的 PersistentVolumeClaim 時(shí)， DefaultStorageClass 準(zhǔn)入控制器會自動(dòng)向其中添加指向默認(rèn)存儲類的 storageClassName 字段。

請注意，集群上最多只能有一個(gè) 默認(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)建幾個(gè)PV或者PVC，而是后端的存儲系統(tǒng)，比如Ceph，如果使用它作為后端存儲，你必須對其非常熟悉，方便在出問題的時(shí)候好排查，如果你對這些存儲系統(tǒng)都不熟悉，在使用的時(shí)候可能會出現(xiàn)很多問題。

以上就是Kubernetes存儲系統(tǒng)數(shù)據(jù)持久化管理詳解的詳細(xì)內(nèi)容，更多關(guān)于Kubernetes數(shù)據(jù)持久化管理的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: