043.Kubernetes叢集存儲-共享存儲

一共享存儲

1.1 共享存儲作用

Kubernetes對于有狀态的容器應用或者對資料需要持久化的應用，不僅需要将容器内的目錄挂載到主控端的目錄或者emptyDir臨時存儲卷，而且需要更加可靠的存儲來儲存應用産生的重要資料，以便容器應用在重建之後仍然可以使用之前的資料。

1.2 共享存儲資源

為了能夠屏蔽底層存儲實作的細節，便于使用和管理，Kubernetes從1.0版本就引入PersistentVolume（PV）和PersistentVolumeClaim（PVC）兩個資源對象來實作對存儲的管理子系統。

PV是對底層網絡共享存儲的抽象，将共享存儲定義為一種“資源”，比如Node也是一種容器應用可以“消費”的資源。PV由管理者建立和配置，它與共享存儲的具體實作直接相關，例如GlusterFS、iSCSI、RBD或GCE或AWS公有雲提供的共享存儲，通過插件式的機制完成與共享存儲的對接，以供應用通路和使用。

PVC則是使用者對存儲資源的一個“申請”。就像Pod“消費”Node的資源一樣，PVC能夠“消費”PV資源。PVC可以申請特定的存儲空間和通路模式。

若使用PVC“申請”到一定的存儲空間仍然不能滿足應用對儲存設備的需求。比如通常應用程式都會對儲存設備的特性和性能有不同的要求，包括讀寫速度、并發性能、資料備援等更高的要求，是以Kubernetes從1.4版本開始引入了一個新的資源對象StorageClass，用于标記存儲資源的特性和性能。

Kubernetes 1.6版本時，StorageClass和動态資源供應的機制得到了完善，實作了存儲卷的按需建立。通過StorageClass的定義，管理者可以将存儲資源定義為某種類别（Class），正如儲存設備對于自身的配置描述（Profile），例如“快速存儲”“慢速存儲”“有資料備援”“無資料備援”等。使用者根據StorageClass的描述就能夠直覺地得知各種存儲資源的特性，就可以根據應用對存儲資源的需求去申請存儲資源。

Kubernetes從1.9版本開始引入容器存儲接口Container Storage Interface（CSI）機制，目标是在Kubernetes和外部存儲系統之間建立一套标準的存儲管理接口，通過該接口為容器提供存儲服務，類似于CRI（容器運作時接口）和CNI（容器網絡接口）。

二 PV

2.1 PV詳解

PV作為存儲資源，主要包括存儲能力、通路模式、存儲類型、回收政策、後端存儲類型等關鍵資訊的設定。

示例1：如下聲明的PV具有如下屬性：5GiB存儲空間，通路模式為ReadWriteOnce，存儲類型為slow（要求在系統中已存在名為slow的StorageClass），回收政策為Recycle，并且後端存儲類型為nfs（設定了NFS Server的IP位址和路徑）。

[root@k8smaster01 study]# vi nfspv01.yaml

1 apiVersion: v1
  2 kind: PersistentVolume
  3 metadata:
  4   name: pv1
  5 spec:
  6   capacity:
  7     storage: 5Gi
  8   accessModes:
  9   - ReadWriteOnce
 10   persistentVolumeReclaimPolicy: Recycle
 11   storageClassName: slow
 12   nfs:
 13     path: /tmp
 14     server: 172.17.0.2

Kubernetes主要支援的PV類型如下：

AWSElasticBlockStore：AWS公有雲提供的ElasticBlockStore。
AzureFile：Azure公有雲提供的File。
AzureDisk：Azure公有雲提供的Disk。
CephFS：一種開源共享存儲系統。
FC（FibreChannel）：光纖儲存設備。
FlexVolume：一種插件式的存儲機制。
Flocker：一種開源共享存儲系統。
GCEPersistentDisk：GCE公有雲提供的PersistentDisk。
Glusterfs：一種開源共享存儲系統。
HostPath：主控端目錄，僅用于單機測試。
iSCSI：iSCSI儲存設備。
Local：本地儲存設備，從Kubernetes1.7版本引入，到1.14版本時更新為穩定版，目前可以通過指定塊（Block）裝置提供LocalPV，或通過社群開發的sig-storage-local-static-provisioner插件（https://github.com/kubernetes-sigs/sigstorage-local-static-provisioner）來管理LocalPV的生命周期。
NFS：網絡檔案系統。
PortworxVolumes：Portworx提供的存儲服務。
QuobyteVolumes：Quobyte提供的存儲服務。
RBD（CephBlockDevice）：Ceph塊存儲。
ScaleIOVolumes：DellEMC的儲存設備。
StorageOS：StorageOS提供的存儲服務。
VsphereVolume：VMWare提供的存儲系統。

2.2 PV配置參數

存儲能力（Capacity）

描述儲存設備具備的能力，目前僅支援對存儲空間的設定（storage=xx），未來可能加入IOPS、吞吐率等名額的設定。

存儲卷模式（VolumeMode）

Kubernetes從1.13版本開始引入存儲卷類型的設定（volumeMode=xxx），可選項包括Filesystem（檔案系統）和Block（塊裝置），預設值為Filesystem。目前有以下PV類型支援塊裝置類型：

AWSElasticBlockStore
AzureDisk
FC
GCEPersistentDisk
iSCSI
Localvolume
RBD（CephBlockDevice）
VsphereVolume（alpha）

示例1：使用塊裝置的PV定義。

[root@k8smaster01 study]# vi blockpv01.yaml

1 apiVersion: v1
  2 kind PersistentVolume
  3 metadata:
  4   name: block-pv
  5 spec:
  6   capacity:
  7     storage: 10Gi
  8   accessNodes:
  9   - ReadWriteOnce
 10   persistentVolumeReclaimPolicy: Retain
 11   volumeMode: Block
 12   fc:
 13     targetWWNs: ["50060e801049cfd1"]
 14     lun: 0
 15     readOnly: false
 16

通路模式（Access Modes）

對PV進行通路模式的設定，用于描述使用者的應用對存儲資源的通路權限，通路模式如下：

ReadWriteOnce（RWO）：讀寫權限，并且隻能被單個Node挂載。
ReadOnlyMany（ROX）：隻讀權限，允許被多個Node挂載。
ReadWriteMany（RWX）：讀寫權限，允許被多個Node挂載。

某些PV可能支援多種通路模式，但PV在挂載時隻能使用一種通路模式，多種通路模式不能同時生效。

存儲類别（Class）PV

可以設定其存儲的類别，通過storageClassName參數指定一個StorageClass資源對象的名稱。具有特定類别的PV隻能與請求了該類别的PVC進行綁定。未設定類别的PV則隻能與不請求任何類别的PVC進行綁定。

回收政策（ReclaimPolicy）

通過PV定義中的persistentVolumeReclaimPolicy字段進行設定，可選項保留（Retain），回收（Recycle）和删除（Delete）。

保留：保留資料，需要手工處理。
回收空間：簡單清除檔案的操作（例如執行rm-rf/thevolume/*指令）。
删除：與PV相連的後端存儲完成Volume的删除操作（如AWSEBS、GCEPD、AzureDisk、OpenStackCinder等裝置的内部Volume清理）。

目前，隻有NFS和HostPath兩種類型的存儲支援Recycle政策；

AWSEBS、GCEPD、Azure Disk和Cinder volumes支援Delete政策。

挂載參數（MountOptions）

在将PV挂載到一個Node上時，根據後端存儲的特點，可能需要設定額外的挂載參數，可以根據PV定義中的mountOptions字段進行設定。

示例2：對一個類型為gcePersistentDisk的PV設定挂載參數。

[root@k8smaster01 study]# vi gccpv01.yaml

1 apiVersion: "v1"
  2 kind: "PersistentVolume"
  3 metadata:
  4   name: gce-disk-1
  5 spec:
  6   capacity:
  7     storage: "10Gi"
  8   accessModes:
  9   - "ReadWriteOnce"
 10   mountOptions:
 11   - hard
 12   - nolock
 13   - nfsvers=3
 14   gcePersistentDisk:
 15     fsType: "ext4"
 16     pdName: "gce-disk-1"
 17

提示：以下PV類型支援設定挂載參數：

AWSElasticBlockStore
AzureDisk
AzureFile
CephFS
Cinder(OpenStackblockstorage)
GCEPersistentDisk
Glusterfs
NFS
QuobyteVolumes
RBD(CephBlockDevice)
StorageOS
VsphereVolume
iSCSI

節點親和性（NodeAffinity）

PV可以設定節點親和性來限制隻能通過某些Node通路Volume，可以在PV定義中的nodeAffinity字段進行設定。使用這些Volume的Pod将被排程到滿足條件的Node上。

示例3：

[root@k8smaster01 study]# vi affpv01.yaml

1 apiVersion: v1
  2 kind: PersistentVolume
  3 metadata:
  4   name: example-local-pv
  5 spec:
  6   capacity:
  7     storage: 5Gi
  8   accessModes:
  9   - ReadWriteOnce
 10   persistentVolumeReclaimPolicy: Delete
 11   storageClassName: local-storage
 12   local:
 13     path: /mnt/disks/ssd1
 14   nodeAffinity:
 15     required:
 16       nodeSelectorTerms:
 17       - mathExpressions:
 18         - key: kubernetes.io/hostname
 19           operator: In
 20           values:
 21           - my-node
 22

注意：這個參數僅用于Local類型的存儲卷。

三 PVC詳解

3.1 PVC使用

PVC作為使用者對存儲資源的需求申請，主要包括存儲空間請求、通路模式、PV選擇條件和存儲類别等資訊的設定。

示例1：申明PVC，具有如下屬性：申請8GiB存儲空間，通路模式為ReadWriteOnce，PV選擇條件為包含标簽“release=stable”并且包含條件為“environment In [dev]”的标簽，存儲類别為“slow”（要求在系統中已存在名為slow的StorageClass）。

[root@k8smaster01 study]# vi myclaim01.yaml

1 kind: PersistentVolumeClaim
  2 apiVersion: v1
  3 metadata:
  4   name: myclaim
  5 spec:
  6   accessModes:
  7   - ReadWriteOnce
  8   resources:
  9     requests:
 10       storage: 8Gi
 11   storageClassName: slow
 12   selector:
 13     matchLabels:
 14       release: "stable"
 15     matchExpressions:
 16     - {key: enviroment, operator: In, values: [dev] }
 17

3.2 PVC配置詳解

PVC的關鍵配置參數說明如下：

資源請求（Resources）：描述對存儲資源的請求，目前僅支援request.storage的設定，即存儲空間大小。
通路模式（AccessModes）：PVC也可以設定通路模式，用于描述使用者應用對存儲資源的通路權限。其三種通路模式的設定與PV的設定相同。
存儲卷模式（VolumeModes）：PVC也可以設定存儲卷模式，用于描述希望使用的PV存儲卷模式，包括檔案系統和塊裝置。
PV選擇條件（Selector）：通過對LabelSelector的設定，可使PVC對于系統中已存在的各種PV進行篩選。系統将根據标簽選出合适的PV與該PVC進行綁定。選擇條件可以使用matchLabels和matchExpressions進行設定，如果兩個字段都設定了，則Selector的邏輯将是兩組條件同時滿足才能完成比對。
存儲類别（Class）：PVC在定義時可以設定需要的後端存儲的類别（通過storageClassName字段指定），以減少對後端存儲特性的詳細資訊的依賴。隻有設定了該Class的PV才能被系統選出，并與該PVC進行綁定。PVC也可以不設定Class需求。如果storageClassName字段的值被設定為空（storageClassName=""），則表示該PVC不要求特定的Class，系統将隻選擇未設定Class的PV與之比對和綁定。PVC也可以完全不設定storageClassName字段，此時将根據系統是否啟用了名為DefaultStorageClass的admissioncontroller進行相應的操作。
未啟用DefaultStorageClass：等效于PVC設定storageClassName的值為空（storageClassName=""），即隻能選擇未設定Class的PV與之比對和綁定。
啟用DefaultStorageClass：要求叢集管理者已定義預設的StorageClass。如果在系統中不存在預設的StorageClass，則等效于不啟用DefaultStorageClass的情況。如果存在預設的StorageClass，則系統将自動為PVC建立一個PV（使用預設StorageClass的後端存儲），并将它們進行綁定。

提示：設定預設StorageClass的方法為，在StorageClass的定義中加上一個annotation“storageclass.kubernetes.io/isdefault-class=true”。如果将多個StorageClass都定義為default，則由于不唯一，系統将無法為PVC建立相應的PV。

注意，PVC和PV都受限于Namespace，PVC在選擇PV時受到Namespace的限制，隻有相同Namespace中的PV才可能與PVC綁定。Pod在引用PVC時同樣受Namespace的限制，隻有相同Namespace中的PVC才能挂載到Pod内。當Selector和Class都進行了設定時，系統将選擇兩個條件同時滿足的PV與之比對。另外，如果資源供應使用的是動态模式，即沒有預先定義PV，僅通過StorageClass交給系統自動完成PV的動态建立，那麼PVC再設定Selector時，系統将無法為其供應任何存儲資源。

在啟用動态供應模式的情況下，一旦使用者删除了PVC，與之綁定的PV也将根據其預設的回收政策“Delete”被删除。如果需要保留PV（使用者資料），則在動态綁定成功後，使用者需要将系統自動生成PV的回收政策從“Delete”改成“Retain”。

四 PV和PVC生命周期管理

4.1 PV生命周期

某個PV在生命周期中可能處于以下4個階段（Phaes）之一。

Available：可用狀态，還未與某個PVC綁定。
Bound：已與某個PVC綁定。
Released：綁定的PVC已經删除，資源已釋放，但沒有被叢集回收。
Failed：自動資源回收失敗。

4.2 PVC生命周期

将PV看作可用的存儲資源，PVC則是對存儲資源的需求，PV和PVC的互相關系遵循如下所示關系：

4.3 資源供應

Kubernetes支援兩種資源的供應模式：靜态模式（Static）和動态模式（Dynamic），資源供應的目的就是建立好PV。

靜态模式：叢集管理者手工建立許多PV，在定義PV時需要将後端存儲的特性進行設定。
動态模式：叢集管理者無須手工建立PV，而是通過StorageClass的設定對後端存儲進行描述，标記為某種類型。此時要求PVC對存儲的類型進行聲明，系統将自動完成PV的建立及與PVC的綁定。

注意；PVC可以聲明Class為""，說明該PVC禁止使用動态模式。

4.4 資源綁定

在使用者定義好PVC之後，系統将根據PVC對存儲資源的請求（存儲空間和通路模式）在已存在的PV中選擇一個滿足PVC要求的PV，一旦找到，就将該PV與使用者定義的PVC進行綁定，使用者的Pod應用就可以使用這個PVC了。

如果在系統中沒有滿足PVC要求的PV，PVC則會無限期處于Pending狀态，直到等到系統管理者建立了一個符合其要求的PV。

PV一旦綁定到某個PVC上，就會被這個PVC獨占，不能再與其他PVC進行綁定了。在這種情況下，當PVC申請的存儲空間比PV的少時，整個PV的空間就都能夠為PVC所用，可能會造成資源的浪費。

如果資源供應使用的是動态模式，則系統在為PVC找到合适的StorageClass後，将自動建立一個PV并完成與PVC的綁定。

4.5 資源使用

Pod使用Volume的定義，将PVC挂載到容器内的某個路徑進行使用。Volume的類型為persistentVolumeClaim。在容器應用挂載了一個PVC後，就能被持續獨占使用。

不過，多個Pod可以挂載同一個PVC，由應用程式自身考慮多個執行個體共同通路一塊存儲空間的問題。

4.6 資源釋放

當使用者對存儲資源使用完畢後，使用者可以删除PVC，與該PVC綁定的PV将會被标記為“已釋放”，但還不能立刻與其他PVC進行綁定。通過之前PVC寫入的資料可能還被留在儲存設備上，隻有在清除之後該PV才能再次使用。

4.7 資源回收

對于PV，可以設定回收政策，用于設定與之綁定的PVC釋放資源之後如何處理遺留資料的問題。隻有PV的存儲空間完成回收，才能供新的PVC綁定和使用。

靜态資源供應模式下，PV、PVC、StorageClass及Pod使用PVC的原理釋義說明：

動态資源供應模式下，PV、PVC、StorageClass及Pod使用PVC的原理釋義說明：

提示：更多StorageClass見《044.叢集存儲-StorageClass》。

更多存儲類型參考：https://www.cnblogs.com/Irving/p/9847060.html