kubernetes系列11—PV和PVC詳解

 

一、認識PV/PVC/StorageClass

1.1 介紹

　　管理存儲是管理計算的一個明顯問題。該PersistentVolume子系統爲用戶和管理員提供了一個API，用於抽象如何根據消費方式提供存儲的詳細信息。爲此，咱們引入了兩個新的API資源：PersistentVolume和PersistentVolumeClaim

　　PersistentVolume（PV）是集羣中由管理員配置的一段網絡存儲。 它是集羣中的資源，就像節點是集羣資源同樣。 PV是容量插件，如Volumes，但其生命週期獨立於使用PV的任何單個pod。 此API對象捕獲存儲實現的詳細信息，包括NFS，iSCSI或特定於雲提供程序的存儲系統。

　　PersistentVolumeClaim（PVC）是由用戶進行存儲的請求。 它相似於pod。 Pod消耗節點資源，PVC消耗PV資源。Pod能夠請求特定級別的資源（CPU和內存）。聲明能夠請求特定的大小和訪問模式（例如，能夠一次讀/寫或屢次只讀）。

　　雖然PersistentVolumeClaims容許用戶使用抽象存儲資源，可是PersistentVolumes對於不一樣的問題，用戶一般須要具備不一樣屬性（例如性能）。羣集管理員須要可以提供各類PersistentVolumes不一樣的方式，而不只僅是大小和訪問模式，而不會讓用戶瞭解這些卷的實現方式。對於這些需求，有StorageClass 資源。

　　StorageClass爲管理員提供了一種描述他們提供的存儲的「類」的方法。 不一樣的類可能映射到服務質量級別，或備份策略，或者由羣集管理員肯定的任意策略。 Kubernetes自己對於什麼類別表明是不言而喻的。 這個概念有時在其餘存儲系統中稱爲「配置文件」。

　　PVC和PV是一一對應的。

 

1.2 生命週期

　　PV是羣集中的資源。PVC是對這些資源的請求，而且還充當對資源的檢查。PV和PVC之間的相互做用遵循如下生命週期：

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

•  供應準備Provisioning---經過集羣外的存儲系統或者雲平臺來提供存儲持久化支持。
  •  - 靜態提供Static：集羣管理員建立多個PV。 它們攜帶可供集羣用戶使用的真實存儲的詳細信息。 它們存在於Kubernetes API中，可用於消費
  •  - 動態提供Dynamic：當管理員建立的靜態PV都不匹配用戶的PersistentVolumeClaim時，集羣可能會嘗試爲PVC動態配置卷。 此配置基於StorageClasses：PVC必須請求一個類，而且管理員必須已建立並配置該類才能進行動態配置。 要求該類的聲明有效地爲本身禁用動態配置。
•  綁定Binding---用戶建立pvc並指定須要的資源和訪問模式。在找到可用pv以前，pvc會保持未綁定狀態。
•  使用Using---用戶可在pod中像volume同樣使用pvc。
•  釋放Releasing---用戶刪除pvc來回收存儲資源，pv將變成「released」狀態。因爲還保留着以前的數據，這些數據須要根據不一樣的策略來處理，不然這些存儲資源沒法被其餘pvc使用。
•  回收Recycling---pv能夠設置三種回收策略：保留（Retain），回收（Recycle）和刪除（Delete）。
  •  - 保留策略：容許人工處理保留的數據。
  •  - 刪除策略：將刪除pv和外部關聯的存儲資源，須要插件支持。
  •  - 回收策略：將執行清除操做，以後能夠被新的pvc使用，須要插件支持。

 注：目前只有NFS和HostPath類型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持刪除(Delete)策略。

 

1.3 PV類型

•  GCEPersistentDisk
•  AWSElasticBlockStore
•  AzureFile
•  AzureDisk
•  FC (Fibre Channel)
•  Flexvolume
•  Flocker
•  NFS
•  iSCSI
•  RBD (Ceph Block Device)
•  CephFS
•  Cinder (OpenStack block storage)
•  Glusterfs
•  VsphereVolume
•  Quobyte Volumes
•  HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
•  Portworx Volumes
•  ScaleIO Volumes
•  StorageOS

 

1.4 PV卷階段狀態

•  Available – 資源還沒有被claim使用
•  Bound – 卷已經被綁定到claim了
•  Released – claim被刪除，卷處於釋放狀態，但未被集羣回收。
•  Failed – 卷自動回收失敗

 

二、演示：建立PV

nfs服務器在上一篇已經部署，詳情請看上一篇博客。

2.1 準備nfs服務

（1）在nfs服務器上先創建存儲卷對應的目錄

?

1 2 3 4 5 6 7 8 9

[root@nfs ~] # cd /data/volumes/ [root@nfs volumes] # mkdir v{1,2,3,4,5} [root@nfs volumes] # ls index.html  v1  v2  v3  v4  v5 [root@nfs volumes] # echo "<h1>NFS stor 01</h1>" > v1/index.html [root@nfs volumes] # echo "<h1>NFS stor 02</h1>" > v2/index.html [root@nfs volumes] # echo "<h1>NFS stor 03</h1>" > v3/index.html [root@nfs volumes] # echo "<h1>NFS stor 04</h1>" > v4/index.html [root@nfs volumes] # echo "<h1>NFS stor 05</h1>" > v5/index.html

　　

（2）修改nfs的配置

?

1 2 3 4 5 6

[root@nfs volumes] # vim /etc/exports /data/volumes/v1        192.168.130.0 /24 (rw,no_root_squash) /data/volumes/v2        192.168.130.0 /24 (rw,no_root_squash) /data/volumes/v3        192.168.130.0 /24 (rw,no_root_squash) /data/volumes/v4        192.168.130.0 /24 (rw,no_root_squash) /data/volumes/v5        192.168.130.0 /24 (rw,no_root_squash)

　　

（3）查看nfs的配置

?

1 2 3 4 5 6

[root@nfs volumes] # exportfs -arv exporting 192.168.130.0 /24 : /data/volumes/v5 exporting 192.168.130.0 /24 : /data/volumes/v4 exporting 192.168.130.0 /24 : /data/volumes/v3 exporting 192.168.130.0 /24 : /data/volumes/v2 exporting 192.168.130.0 /24 : /data/volumes/v1

　　

（4）是配置生效

?

1 2 3 4 5 6 7

[root@nfs volumes] # showmount -e Export list for nfs: /data/volumes/v5 192.168.130.0 /24 /data/volumes/v4 192.168.130.0 /24 /data/volumes/v3 192.168.130.0 /24 /data/volumes/v2 192.168.130.0 /24 /data/volumes/v1 192.168.130.0 /24

　　

2.2 在master上建立PV

（1）編寫yaml文件，並建立pv

建立5個pv，存儲大小各不相同，是否可讀也不相同

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

[root@master volumes] # vim pv-damo.yaml apiVersion: v1 kind: PersistentVolume metadata:    name: pv001    labels:      name: pv001 spec:    nfs:      path: /data/volumes/v1      server: nfs    accessModes: [ "ReadWriteMany" , "ReadWriteOnce" ]    capacity:      storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata:    name: pv002    labels:      name: pv002 spec:    nfs:      path: /data/volumes/v2      server: nfs    accessModes: [ "ReadWriteOnce" ]    capacity:      storage: 5Gi --- apiVersion: v1 kind: PersistentVolume metadata:    name: pv003    labels:      name: pv003 spec:    nfs:      path: /data/volumes/v3      server: nfs    accessModes: [ "ReadWriteMany" , "ReadWriteOnce" ]    capacity:      storage: 20Gi --- apiVersion: v1 kind: PersistentVolume metadata:    name: pv004    labels:      name: pv004 spec:    nfs:      path: /data/volumes/v4      server: nfs    accessModes: [ "ReadWriteMany" , "ReadWriteOnce" ]    capacity:      storage: 10Gi --- apiVersion: v1 kind: PersistentVolume metadata:    name: pv005    labels:      name: pv005 spec:    nfs:      path: /data/volumes/v5      server: nfs    accessModes: [ "ReadWriteMany" , "ReadWriteOnce" ]    capacity:      storage: 15Gi [root@master volumes] # kubectl apply -f pv-damo.yaml persistentvolume /pv001 created persistentvolume /pv002 created persistentvolume /pv003 created persistentvolume /pv004 created persistentvolume /pv005 created

　　

（2）查詢驗證

?

1 2 3 4 5 6 7

[root@master ~] # kubectl get pv NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE pv001     5Gi        RWO,RWX        Retain           Available                                      9s pv002     5Gi        RWO            Retain           Available                                      9s pv003     5Gi        RWO,RWX        Retain           Available                                      9s pv004     10Gi       RWO,RWX        Retain           Available                                      9s pv005     15Gi       RWO,RWX        Retain           Available                                      9s

　　

三、建立PVC，綁定PV

（1）編寫yaml文件，並建立pvc

建立一個pvc，須要6G存儲；因此不會匹配pv00一、pv00二、pv003

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

[root@master volumes] # vim vol-pvc-demo.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata:    name: mypvc    namespace: default spec:    accessModes: [ "ReadWriteMany" ]    resources:      requests:        storage: 6Gi --- apiVersion: v1 kind: Pod metadata:    name: vol-pvc    namespace: default spec:    volumes:    - name: html      persistentVolumeClaim:        claimName: mypvc    containers:    - name: myapp      image: ikubernetes /myapp :v1      volumeMounts:      - name: html        mountPath: /usr/share/nginx/html/ [root@master volumes] # kubectl apply -f vol-pvc-demo.yaml persistentvolumeclaim /mypvc created pod /vol-pvc created

　　

（2）查詢驗證：pvc已經綁定到pv004上

?

1 2 3 4 5 6 7 8 9 10

[root@master ~] # kubectl get pvc NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE mypvc     Bound     pv004     10Gi       RWO,RWX                       24s [root@master ~] # kubectl get pv NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON    AGE pv001     5Gi        RWO,RWX        Retain           Available                                            1m pv002     5Gi        RWO            Retain           Available                                            1m pv003     5Gi        RWO,RWX        Retain           Available                                            1m pv004     10Gi       RWO,RWX        Retain           Bound       default /mypvc                            1m pv005     15Gi       RWO,RWX        Retain           Available                                            1m

　　

（3）查詢業務驗證

?

1 2 3 4 5

[root@master ~] # kubectl get pods -o wide NAME      READY     STATUS    RESTARTS   AGE       IP             NODE vol-pvc   1 /1       Running   0          59s       10.244.2.117   node2 [root@master ~] # curl 10.244.2.117 <h1>NFS stor 04< /h1 >