k8s 存儲卷之 PV & PVC

書接上文：

高級存儲

由于kubernetes支持的存儲系統有很多，要求客戶全都掌握，顯然不現實。為了能夠屏蔽底層存儲實現的細節，方便用戶使用， kubernetes引入PV和PVC兩種資源對象。

• PV（Persistent Volume）是持久化卷的意思，是對底層的共享存儲的一種抽象。一般情況下PV由kubernetes管理員進行創建和配置，它與底層具體的共享存儲技術有關，并通過插件完成與共享存儲的對接。

• PVC（Persistent Volume Claim）是持久卷聲明的意思，是用戶對于存儲需求的一種聲明。換句話說，PVC其實就是用戶向kubernetes系統發出的一種資源需求申請。

使用了PV和PVC之后，工作可以得到進一步的細分：

• 存儲：存儲工程師維護
• PV： kubernetes管理員維護
• PVC：kubernetes用戶維護

---

PV

PV作為存儲資源，主要包括存儲能力、訪問模式、存儲類型、回收策略、后端存儲類型等關鍵信息的設置。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存儲類型，和底層的存儲對應
    path:
    server:
  capacity: # 存儲能力，目前只支持存儲空間的設置
    storage: 2Gi
  accessModes: # 訪問模式
    -
  storageClassName: # 存儲類別
  persistentVolumeReclaimPolicy: # 回收策略

• 訪問模式（accessModes）

  用于描述用戶應用對存儲資源的訪問權限，訪問權限包括下面幾種方式：

 ReadWriteOnce（RWO）：讀寫權限，但是只能被單個節點掛載
    ReadOnlyMany（ROX）： 只讀權限，可以被多個節點掛載
    ReadWriteMany（RWX）：讀寫權限，可以被多個節點掛載

需要注意的是，底層不同的存儲類型可能支持的訪問模式不同：

• 回收策略（persistentVolumeReclaimPolicy）

  當PV不再被使用了之后，對其的處理方式。目前支持三種策略：

Retain （保留） 保留數據，需要管理員手工清理數據
Recycle（回收） 清除 PV 中的數據，效果相當于執行 rm -rf /thevolume/*
Delete （刪除） 與 PV 相連的后端存儲完成 volume 的刪除操作，當然這常見于云服務商的存儲服務

需要注意的是，底層不同的存儲類型可能支持的回收策略不同。
警告： 回收策略 Recycle 已被廢棄。取而代之的建議方案是使用動態供應。

• 狀態（status）

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

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

---

創建 PV 實例

示例
1、準備環境

# 創建目錄
[root@nfs ~]# mkdir /root/data/{pv1,pv2,pv3} -pv

# 暴露服務
[root@nfs ~]# more /etc/exports
/root/data/pv1     192.168.5.0/24(rw,no_root_squash)
/root/data/pv2     192.168.5.0/24(rw,no_root_squash)
/root/data/pv3     192.168.5.0/24(rw,no_root_squash)

# 重啟服務
[root@nfs ~]#  systemctl restart nfs

2、創建pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv1
spec:
  capacity: 
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv1
    server: 192.168.5.6

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv2
spec:
  capacity: 
    storage: 2Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv2
    server: 192.168.5.6
    
---

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv3
spec:
  capacity: 
    storage: 3Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv3
    server: 192.168.5.6

---

PVC

PVC是資源的申請，用來聲明對存儲空間、訪問模式、存儲類別需求信息。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: dev
spec:
  accessModes: # 訪問模式
  selector: # 采用標簽對PV選擇
  storageClassName: # 存儲類別
  resources: # 請求空間
    requests:
      storage: 5Gi

示例：

注：這里申請的大小需要注意，申請的存儲卷大小需要等于或小于當前系統中空閑的存儲卷大小，以本文為例，前面我們創建了 1G/2G/3G 三個 PV 實例，都還沒用，都是空閑的。但是這里申請的存儲空間大小為 8 G，所以是無法被匹配的。

---

Pod 掛載數據卷

這是很重要的臨門一腳，我們前面又是創建 PV 實例，又是申請空間，就是為了掛載到 Pod 上使用。

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  namespace: dev
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc1
        readOnly: false
---
apiVersion: v1
kind: Pod
metadata:
  name: pod2
  namespace: dev
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;"]
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc2
        readOnly: false

注：這里需要特別注意這一行：claimName: pvc1

這個 pvc 需要真實存在的，不然是無法調度到的。

---

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”。

---

生命周期

Kubernetes支持兩種資源的供應模式：靜態模式（Static）和動態模式（Dynamic）。資源供應的結果就是創建好的PV。

◎ 靜態模式：集群管理員手工創建許多PV，在定義PV時需要將后端存儲的特性進行設置。
◎ 動態模式：集群管理員無須手工創建PV，而是通過StorageClass的設置對后端存儲進行描述，標記為某種類型。
此時要求PVC對存儲的類型進行聲明，系統將自動完成PV的創建及與PVC的綁定。PVC可以聲明Class為""，說明該PVC禁止使用動態模式。

下圖描述了在靜態資源供應模式下的 PV 和 PVC 原理：

下圖描述了在動態資源供應模式下，通過StorageClass和PVC完成資源動態綁定（系統自動生成PV），并供Pod使用的存儲管理機制。

---

在 Kubernetes 中，實際上存在著一個專門處理持久化存儲的控制器，叫作 Volume Controller。這個 Volume Controller 維護著多個控制循環，其中有一個循環，扮演的就是撮合 PV 和 PVC 的“紅娘”的角色。它的名字叫作 PersistentVolumeController。PersistentVolumeController 會不斷地查看當前每一個 PVC，是不是已經處于 Bound（已綁定）狀態。如果不是，那它就會遍歷所有的、可用的 PV，并嘗試將其與這個“單身”的 PVC 進行綁定。這樣，Kubernetes 就可以保證用戶提交的每一個 PVC，只要有合適的 PV 出現，它就能夠很快進入綁定狀態，從而結束“單身”之旅。而所謂將一個 PV 與 PVC 進行“綁定”，其實就是將這個 PV 對象的名字，填在了 PVC 對象的 spec.volumeName 字段上。所以，接下來 Kubernetes 只要獲取到這個 PVC 對象，就一定能夠找到它所綁定的 PV。