kubernetes系列(十四) - 儲存之PersistentVolume

寶樹吶發表於2020-07-10

1. PersistentVolume(PV)簡介

1.1 為什麼需要Persistent Volume(PV)

在講PersistentVolume(PV)之前，我們需要先講一下Volume

Volume詳情可見上一章： kubernetes系列(十三) - 儲存之Volume

Volume是被定義在pod上的(emptyDir或者hostPath)，屬於計算資源的一部分。所以Volume是有侷限性的，因為在實際的運用過程中，我們通常會先定義一個網路儲存，然後從中劃出一個網盤並掛接到虛擬機器上。

為了遮蔽底層儲存實現的細節，讓使用者方便使用，同時讓管理員方便管理。Kubernetes從V1.0版本就引入了PersistentVolume(PV)和與之相關聯的PersistentVolumeClaim(PVC)兩個資源物件來實現對儲存的管理

1.2 PersistentVolume(PV)和Volume的區別

PV可以被理解成kubernetes叢集中的某個網路儲存對應的一塊儲存，它與Volume類似，但是有如下的區別：

PV只能是網路儲存，不屬於任何Node，但是可以在每個Node上訪問
PV不是被定義在pod上，而是獨立在pod之外被定義的。
- 意味著pod被刪除了，PV仍然存在，這點與Volume不同

1.3 PV和PVC更具體的概念和關係

1.3.1 PersistentVolume(PV)

PersistentVolume(PV)是由管理員設定的儲存，它是群集的一部分。就像節點是叢集中的資源一樣，PV也是叢集中的資源。PV是Volume之類的卷外掛，但具有獨立於使用PV的Pod的生命週期。此API物件包含儲存實現的細節，即NFS、iSCSl或特定於雲供應商的儲存系統。

1.3.2 PersistentVolumeClaim(PVC)

PersistentVolumeClaim(PVC)是使用者儲存的請求。它與Pod相似。Pod消耗節點資源，PVC消耗PV資源。Pod可以請求特定級別的資源（CPU和記憶體）。宣告可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或只讀多次模式掛載）

1.3.3 PV和PVC的關係和圖解

pvc是一種pv的請求方案，PVC定義我當前需要什麼樣型別的PV，然後會自動在當前存在的pv中選取一個匹配度最高的pv

一個PVC只能繫結一個PV！！

2. PersistentVolume(PV)的分類

2.1 靜態PV

簡單來說

由叢集管理員手動建立的一些PV

完整的概念

叢集管理員建立一些PV。它們帶有可供群集使用者使用的實際儲存的細節。它們存在於KubernetesAPl中，可用於消費。

2.2 動態PV

簡單來說

配置了允許動態PV的策略後，如果當前存在的PV無法滿足PVC的要求，則會動態建立PV.

動態PV瞭解即可

完整的概念

當管理員建立的靜態PV都不匹配使用者的PersistentVolumeClaim時，叢集可能會嘗試動態地為PVC建立卷。此配置基於StorageClasses,所以要啟用基於儲存級別的動態儲存配置要求：

PVC必須請求StorageClasses
管理員必須建立並配置StorageClasses才能進行動態建立
宣告該類為“”可以有效地禁用其動態配置
叢集管理員需要啟用API server上的DefaultStorageClass[准入控制器]。例如，通過確保DefaultStorageClass位於API server 元件的--admission-control標誌，使用逗號分隔的有序值列表中，可以完成此操作

3. PersistentVolumeClaim(PVC)的保護

PVC保護的目的是確保由pod正在使用的PVC不會從系統中移除，因為如果被移除的話可能會導致資料丟失當啟用PVC保護alpha功能時，如果使用者刪除了一個pod正在使用的PVC，則該PVC不會被立即刪除。PVC的刪除將被推遲，直到PVC不再被任何 pod使用

4. PersistentVolume(PV)支援的底層儲存型別

PersistentVolume型別以外掛形式實現. kubernetes目前支援以下型別(排名不分先後):

跟上一集中的volume支援的型別差不多

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 VMware Photon Portworx Volumes Scalelo Volumes StorageOS

5. PersistentVolume(PV)的資源清單

5.1 資源清單示例

apiVersion: v1 
kind: PersistentVolume 
metadata:
  name：pve003 
spec:
  capacity:
    # 卷的大小為5G
    storage: 5Gi 
  # 儲存卷的型別為：檔案系統
  volumeMode: Filesystem 
  # 訪問策略：該卷可以被單個節點以讀/寫模式掛載
  accessModes:
    - ReadNriteOnce 
  # 回收策略：回收
  persistentVolumeReclaimPolicy: Recycle
  # 對應的具體底層儲存的分級
  # 比如有些固態或者其他儲存型別比較快，就可以定義為strong
  storageClassName: slow
  # (可選的)掛載選項
  mountOptions:
    - hard 
    - nfsvers=4.1
  # 具體對應的真實底層儲存型別為nfs
  # 掛載到172伺服器下的/tmp目錄
  nfs:
    path: /tmp 
    server: 172.17.0.2

5.2 PV的訪問模式(spec.accessModes)

5.2.1 三種訪問模式

訪問模式accessModes一共有三種：

ReadWriteOnce: 該卷可以被單個節點以讀/寫模式掛載
ReadOnlyMany: 該卷可以被多個節點以只讀模式掛載
ReadWriteMany: 該卷可以被多個節點以讀/寫模式掛載

在命令列cli中，三種訪問模式可以簡寫為：

RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany

但不是所有的型別的底層儲存都支援以上三種，每種底層儲存型別支援的都不一樣！！

5.2.2 各種底層儲存具體支援的訪問模式

Volume Plugin	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStore	✓	-	-
AzureFile	✓	✓	✓
AzureDisk	✓	-	-
CephFS	✓	✓	✓
Cinder	✓	-	-
FC	✓	✓	-
FlexVolume	✓	✓	-
Flocker	✓	-	-
GCEPersistentDisk	✓	✓	-
Glusterfs	✓	✓	✓
HostPath	✓	-	-
iSCSI	✓	✓	-
PhotonPersistentDisk	✓	-	-
Quobyte	✓	✓	✓
NFS	✓	✓	✓
RBD	✓	✓	-
VsphereVolume	✓	-	-
PortworxVolume	✓	-	✓
ScaleIO	✓	✓	-

5.3 PV的回收策略(spec.persistentVolumeReclaimPolicy)

5.3.1 回收策略的三種策略

Retain(保留): pv被刪除後會保留記憶體，手動回收
Recycle(回收): 刪除卷下的所有內容（rm-rf /thevolume/*)
Delete(刪除): 關聯的儲存資產（例如AWS EBS、GCE PD、Azure Disk 和OpenStack Cinder卷）將被刪除。即直接把卷給刪除了

5.3.2 回收策略注意事項

當前，只有NFS和HostPath支援Recycle回收策略

最新版本中的Recycle已被廢棄，截圖如下

附：具體官網文件詳細說明連結點選此處

AWS EBS、GCE PD、Azure Disk 和Cinder 卷支援Delete刪除策略

6. PersistentVolume(PV)的狀態

PV可以處於以下的某種狀態：

Available(可用): 塊空閒資源還沒有被任何宣告繫結
Bound(已繫結): 卷已經被宣告繫結, 注意：但是不一定不能繼續被繫結，看accessModes而定
Released(已釋放): 宣告被刪除，但是資源還未被叢集重新宣告
Failed(失敗): 該卷的自動回收失敗

命令列會顯示繫結到PV的PVC的名稱

7. 實驗-持久化演示說明-NFS

注：以下內容筆者沒有實際嘗試過，僅做記錄使用

7.1 安裝NFS伺服器

yum install -y nfs-common nfs-utils rpcbind 
mkdir /nfsdata 
chmod 777 /nfsdata 
chown nfsnobody /nfsdata 
cat /etc/exports /nfsdata *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind 
systemctl start nfs

7.2 在其他節點上安裝客戶端

yum -y install nfs-utils rpcbind
mkdir /test
showmount -e 192.168.66.100
mount -t nfs 192.168.66.100:/nfsdata /test/
cd /test/
ls
umount /test/

7.3 部署PV

apiVersion: v1 
kind: PersistentVolume 
metadata:
  name: nfspv1 
spec:
  capacity:
    storage: 10Gi 
  accessModes:
    - ReadWriteOnce 
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfsdata
   server: 192.168.66.100

7.4 建立服務並使用PVC

apiVersion: v1 
kind: Service 
metadata:
  name: nginx 
  labels:
    app: nginx 
spec:
  ports:
  - port: 80 
    name: web 
  clusterIP: None 
  selector:
    app: nginx
---
apiVersion: apps/v1 
kind: StatefulSet 
metadata:
  name: web 
spec:
  selector:
    matchLabels:
      app: nginx 
  serviceName: "nginx"
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:
      - name: nginx 
        image: k8s.gcr.io/nginx-slim:0.8 
        ports:
        - containerPort: 80 
          name: web 
        volumeMounts:
        - name: www 
          mountPath: /usr/share/nginx/html 
  volumeClaimTemplates:
  - metadata:
      name: www 
    spec:
      accessModes: [ "ReadWriteOnce" ] 
      storageClassName: "nfs"
      resources:
        requests:
          storage: 1Gi

8. 關於 Statefulset

StatefulSet為每個Pod副本建立了一個DNS域名，這個域名的格式為:S(podname).(headless servername)

也就意味著服務間是通過Pod域名來通訊而非PodIP，因為當Pod所在Node發生故障時，Pod會被飄移到其它 Node上,PodIP會發生變化，但是Pod域名不會有變化

StatefulSet使用Headless服務來控制Pod的域名，這個域名的FQDN為:S(servicename).$(namespace).svc.cluster.local

其中，“cluster.local”指的是叢集的域名

根據volumeClaimTemplates，為每個Pod 建立一個pvo,pvc的命名規則匹配模式:
(volumeClaimTemplates.name)-(pod_name)

比如上面的 volumeMounts.name=www,Podname-web-[0-2]，因此建立出來的PVC是 www-web-0、www-web-1、 www-web-2

刪除 Pod 不會刪除其pvc，手動刪除 pvc將自動釋放pv
Statefulset的啟停順序:
- 有序部署:部罷Statefulset時，如果有多個Pod副本，它們會被順序地建立（從0到N-1)並且，在下一個Pod執行之前所有之前的Pod必須都是Running和Ready狀態。
- 有序刪除:當Pod被刪除時，它們被終止的順序是從N-1到0。
- 有序擴充套件:當對Pod執行擴充套件操作時，與部署一樣，它前面的Pod必須都處於Running和Ready狀態。
Statefulset使用場景:
- 穩定的持久化儲存，即Pod重新排程後還是能訪問到相同的持久化資料，基於PVC 來實現。
- 穩定的網路識別符號，即Pod 重新排程後其iPodName 和 HostName不變。
- 有序部署，有序擴充套件，基於init containers 來實現。
- 有序收縮。

kubernetes系列(十三) - 儲存之Volume
2020-07-08
kubernetes系列(十二) - 儲存之Secret
2020-07-07
kubernetes系列10—儲存卷詳解
2019-01-30
Kubernetes的故事之持久化儲存(十)
2022-01-26
持久化
kubernetes 儲存流程
2024-05-03
【免費視訊】深入淺出kubernetes儲存系列
2018-07-20
Kubernetes K8S之儲存ConfigMap詳解
2020-10-14
K8S
MySQL入門系列：儲存程式（三）之儲存過程簡介
2019-03-21
MySql儲存過程
MySQL入門系列：儲存程式（二）之儲存函式簡介
2019-03-20
MySql儲存函式
kubernetes系列12—二個特色的儲存卷configmap和secret
2019-02-26
Spark in action on Kubernetes - 儲存篇
2019-04-09
Spark
Kubernetes-儲存卷Volume
2018-12-14
Kubernetes中的儲存(六)
2020-09-16
Kubernetes 持久化儲存之 NFS 終極實戰指南
2024-07-22
持久化NFS
探索 Kubernetes 持久化儲存之 Longhorn 初窺門徑
2024-07-25
持久化
SpringSession系列-儲存機制之Redis&Map
2018-12-15
SpringGseSessionRedis
kubernetes實踐之六十四：CoreDNS
2018-06-26
DNS
配置Kubernetes共享使用Ceph儲存
2019-04-25
Spark in action on Kubernetes - 儲存篇（一）
2019-04-19
Spark
（三）Kubernetes---持久化儲存
2020-12-10
持久化
探索 Kubernetes 持久化儲存之 Rook Ceph 初窺門徑
2024-08-13
持久化
MySQL系列-儲存引擎
2018-12-03
MySql儲存引擎
分散式儲存技術解讀系列之GFS
2022-05-23
分散式
kubernetes實踐之十四：Service Account與Secret
2018-04-11
09 . Kubernetes之pv、pvc及使用nfs網路儲存應用
2020-07-02
NFS
入門Kubernetes-資料儲存
2021-08-01
Kubernetes 持久化資料儲存 StorageClass
2021-09-08
持久化
Spring Security系列之Session管理(十四)
2018-12-27
SpringSession
kubernetes實踐之四十四：Ingress詳解
2018-05-20
kubernetes實踐之五十四：垃圾回收機制
2018-06-10
Flutter持久化儲存之檔案儲存
2019-03-06
Flutter持久化
kubernetes配置後端儲存 rook-ceph
2022-03-07
後端
Flutter持久化儲存之資料庫儲存
2019-03-08
Flutter持久化資料庫
Flutter持久化儲存之key-value儲存
2019-03-04
Flutter持久化
入門系列之Kubernetes部署
2018-07-13
為什麼Kubernetes的儲存如此艱難?
2019-01-14
利用Kubernetes實現容器的持久化儲存
2019-01-30
持久化
細述Kubernetes和Docker容器的儲存方式
2019-04-13
Docker