Kubernetes存儲系統數據持久化管理方法是什么

本篇內容主要講解“Kubernetes存儲系統數據持久化管理方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Kubernetes存儲系統數據持久化管理方法是什么”吧!

引言

Kubernetes為了能更好的支持有狀態應用的數據存儲問題，除了基本的HostPath和EmptyDir提供的數據持久化方案之外，還提供了PV，PVC和StorageClass資源對象來對存儲進行管理。

PV的全稱是Persistent Volume（持久化卷），是對底層數據存儲的抽象，PV由管理員創建、維護以及配置，它和底層的數據存儲實現方法有關，比如Ceph，NFS，ClusterFS等，都是通過插件機制完成和共享存儲對接。

PVC的全稱是Persistent Volume Claim（持久化卷聲明），我們可以將PV比喻為接口，里面封裝了我們底層的數據存儲，PVC就是調用接口實現數據存儲操作，PVC消耗的是PV的資源。

StorageClass是為了滿足用于對存儲設備的不同需求，比如快速存儲，慢速存儲等，通過對StorageClass的定義，管理員就可以將存儲設備定義為某種資源類型，用戶根據StorageClass的描述可以非常直觀的知道各種存儲資源的具體特性，這樣就可以根據應用特性去申請合適的資源了。

安裝存儲系統

存儲系統的選擇有很多，常見的有NFS、Ceph、GlusterFS、FastDFS等，具體使用什么根據企業情況而定。在這里使用的是NFS，下面簡單介紹一下如何安裝。

（1）安裝服務

$ yum install nfs-utils rpcbind -y

（2）創建共享目錄

$ mkdir /data/k8s -p

（3）配置NFS配置文件

$ vim /etc/exports
/data/k8s *(rw,sync,no_root_squash)

（4）啟動服務

$ 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：所有節點都需要安裝NFS客戶端

PV

PV（Persistent Volume）作為Kubernetes存儲設備，可以由管理員提前配置，也可以通過StorageClass來動態供應。

PV是集群資源，可以通過kubectl explain pv來查看如何配置，主要包括存儲能力，訪問模式，存儲類型，回收信息等關鍵信息。例如：

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

參數說明：

（1）、accessMode：訪問模式，有ReadWriteOnce，ReadOnlyMany，ReadWriteMany。其中：

• ReadWriteOnce：表示具有讀寫權限，但是只能被一個node掛載一次

• ReadOnlyMany：表示具有只讀權限，可以被多個node多次掛載

• ReadWriteMany：表示具有讀寫權限，可以被多個node多次掛載

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

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

• Retain：保留數據，如果要清理需要手動清理數據，默認的策略；

• Delete：刪除，將從Kubernetes中刪除PV對象，以及外部基礎設施中相關的存儲資產，比如AWS EBS, GCE PD, Azure Disk, 或Cinder volume；

• Recycle：回收，清楚PV中的所有數據，相當于執行rm -rf /pv-volume/*；

創建過后，PV的狀態如下：

$ 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>

當前PV的狀態是Available，表示處于隨時可用狀態。PV總共有以下四種狀態：

• Available（可用）：表示可用狀態，還未被任何 PVC 綁定

• Bound（已綁定）：表示 PVC 已經被 PVC 綁定

• Released（已釋放）：PVC 被刪除，但是資源還未被集群重新聲明

• Failed（失敗）：表示該 PV 的自動回收失敗

單純的創建PV，我們并不能直接使用，需要使用PVC（Persistent Volume Claim）來進行聲明。

PVC

PVC（Persistent Volume Claim）用于表達用戶對存儲的需求，申請PVC會消耗掉PV的資源，可以通過kubectl explain pvc來查看幫助文檔。

在上一節我們創建了PV，現在要申明PVC，如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-test
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

spec參數說明：

（1）、accessModes：主要定義卷所應該擁有的訪問模式

（2）、resources：主要定義卷應該擁有的最小資源

（3）、dataSource：定義如果提供者具有卷快照功能，就會創建卷，并將數據恢復到卷中，反之不創建

（4）、selector：定義綁定卷的標簽查詢

（5）、storageClassName：定義的storageClass的名字

（6）、volumeMode：定義卷的類型

（7）、volumeName：需要綁定的PV的名稱鏈接

創建過后，查看PV和PVC的狀態，如下：

$ 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狀態，Bound的VOLUME是my-pv01，我們再看pv的狀態有Available變為Bound，其CLAIM是default/pvc-test，其中default為namespace名稱。

在上面我們創建了一個PVC，其綁定了我們創建的PV，如果此時我們再創建一個PVC，結果又會如何？我們copy以下上面的PVC文件，將其名稱改一下，如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-test2
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

然后查看PVC的狀態，如下

$ kubectl get pvc
NAME        STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-test    Bound     my-pv01   1Gi        RWO                           3m57s
pvc-test2   Pending                                                      4s

我們可以看到我們剛創建的pvc-test2的STATUS處于Pending狀態，這是由于集群里聲明的PV都使用完了，PVC在申請的時候沒有找到合適的PV，所以處于這個狀態，這時候如果我們創建一個新的并滿足要求的PV，則可以看到這個PVC會處于Bound狀態。如下：

$ 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也在申領PV的時候也不是隨意申領的，它需要符合以下要求：

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

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

（3）一個PV只能綁定一個PVC

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

StorageClass

上面介紹的PV和PVC模式是需要運維人員先創建好PV，然后開發人員定義好PVC進行一對一的Bond，但是如果PVC請求成千上萬，那么就需要創建成千上萬的PV，對于運維人員來說維護成本很高，Kubernetes提供一種自動創建PV的機制，叫StorageClass，它的作用就是創建PV的模板。

具體來說，StorageClass會定義一下兩部分：

• PV的屬性 ，比如存儲的大小、類型等；

• 創建這種PV需要使用到的存儲插件，比如Ceph等；

有了這兩部分信息，Kubernetes就能夠根據用戶提交的PVC，找到對應的StorageClass，然后Kubernetes就會調用 StorageClass聲明的存儲插件，創建出需要的PV。

這里我們以NFS為例，要使用NFS，我們就需要一個nfs-client的自動裝載程序，我們稱之為Provisioner，這個程序會使用我們已經配置好的NFS服務器自動創建持久卷，也就是自動幫我們創建PV。說明：

• 自動創建的PV會以{pvcName}-${pvName}的目錄格式放到NFS服務器上；

• 如果這個PV被回收，則會以archieved-{pvcName}-${pvName}這樣的格式存放到NFS服務器上；

安裝NFS Provisioner

（1）創建ServiceAccount，為NFS Provisioner授權

---
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）創建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

執行完成后，查看NFS Provisioner的狀態，如下：

$ kubectl get po
NAME                                    READY   STATUS    RESTARTS   AGE
nfs-client-prosioner-54d64dfc85-b4ht4   1/1     Running   0          10s

使用StorageClass

上面已經創建好NFS Provisioner，現在我們可以直接創建StroageClass，如下：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs
provisioner: rookieops/nfs

每個 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 這些字段會在 StorageClass 需要動態分配 PersistentVolume 時會使用到。

在配置StorageClass的時候，如果沒有指定reclaimPolicy，則默認是Delete，除此之外，還有Retain。

StorageClass 對象的命名很重要，用戶使用這個命名來請求生成一個特定的類。當創建 StorageClass 對象時，管理員設置 StorageClass 對象的命名和其他參數，一旦創建了對象就不能再對其更新。

使用kubectl apply -f sc.yaml創建StorageClass，創建完成過后如下：

$ kubectl get sc
NAME   PROVISIONER     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs    rookieops/nfs   Delete          Immediate           false                  9m41s

現在，我們就可以使用動態存儲申領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創建情況，如下：

$ 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

可以看到自動創建了一個PV，然后和PVC進行綁定。

為了方便使用，有時候會給集群默認設置一個StorageClass，以便在需要使用動態存儲，但是未聲明的情況下使用默認的動態存儲。設置方式如下：

$ kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

通過向其添加 storageclass.kubernetes.io/is-default-class 注解來將特定的 StorageClass 標記為默認。當集群中存在默認的 StorageClass 并且用戶創建了一個未指定 storageClassName 的 PersistentVolumeClaim 時， DefaultStorageClass 準入控制器會自動向其中添加指向默認存儲類的 storageClassName 字段。

請注意，集群上最多只能有一個 默認 存儲類，否則無法創建沒有明確指定 storageClassName 的 PersistentVolumeClaim。

如果要取消默認StorageClass，只需要把注解設置為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

可以進入容器，到掛載目錄輸出，例如：

$ kubectl exec -it nginx -- /bin/bash
root@nginx:/mnt# echo "test" > /mnt/text.txt

然后到NFS對應的目錄查看是否一致。

$ cd /data/k8s/default-pvc-from-sc-pvc-a4a71b8c-5664-4d1a-b286-9e4adcf6f96a
$ cat text.txt 
test

這表示Pod使用持久化成功。

到此，相信大家對“Kubernetes存儲系統數據持久化管理方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！