k8s 存儲卷之 PV & PVC

書接上文：

高級存儲

由于kubernetes支持的存儲系統(tǒng)有很多，要求客戶全都掌握，顯然不現(xiàn)實(shí)。為了能夠屏蔽底層存儲實(shí)現(xiàn)的細(xì)節(jié)，方便用戶使用， kubernetes引入PV和PVC兩種資源對象。

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

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

使用了PV和PVC之后，工作可以得到進(jìn)一步的細(xì)分：

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

PV

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

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

• 訪問模式（accessModes）

  用于描述用戶應(yīng)用對存儲資源的訪問權(quán)限，訪問權(quán)限包括下面幾種方式：

 ReadWriteOnce（RWO）：讀寫權(quán)限，但是只能被單個節(jié)點(diǎn)掛載
    ReadOnlyMany（ROX）： 只讀權(quán)限，可以被多個節(jié)點(diǎn)掛載
    ReadWriteMany（RWX）：讀寫權(quán)限，可以被多個節(jié)點(diǎn)掛載

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

• 回收策略（persistentVolumeReclaimPolicy）

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

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

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

• 狀態(tài)（status）

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

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

創(chuàng)建 PV 實(shí)例

示例
1、準(zhǔn)備環(huán)境

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

# 暴露服務(wù)
[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)

# 重啟服務(wù)
[root@nfs ~]#  systemctl restart nfs

2、創(chuàng)建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: # 采用標(biāo)簽對PV選擇
  storageClassName: # 存儲類別
  resources: # 請求空間
    requests:
      storage: 5Gi

示例：

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

Pod 掛載數(shù)據(jù)卷

這是很重要的臨門一腳，我們前面又是創(chuàng)建 PV 實(shí)例，又是申請空間，就是為了掛載到 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 需要真實(shí)存在的，不然是無法調(diào)度到的。

PVC和PV都受限于Namespace，PVC在選擇PV時受到Namespace的限制，只有相同Namespace中的PV才可能與PVC綁定。Pod在引用PVC時同樣受Namespace的限制，只有相同Namespace中的PVC才能掛載到Pod內(nèi)。

當(dāng)Selector和Class都進(jìn)行了設(shè)置時，系統(tǒng)將選擇兩個條件同時滿足的PV與之匹配另外，如果資源供應(yīng)使用的是動態(tài)模式，即管理員沒有預(yù)先定義PV，僅通過StorageClass交給系統(tǒng)自動完成PV的動態(tài)創(chuàng)建，那么PVC再設(shè)定Selector時，系統(tǒng)將無法為其供應(yīng)任何存儲資源。

在啟用動態(tài)供應(yīng)模式的情況下，一旦用戶刪除了PVC，與之綁定的PV也將根據(jù)其默認(rèn)的回收策略“Delete”被刪除。如果需要保留PV（用戶數(shù)據(jù)），則在動態(tài)綁定成功后，用戶需要將系統(tǒng)自動生成PV的回收策略從“Delete”改成“Retain”。

生命周期

Kubernetes支持兩種資源的供應(yīng)模式：靜態(tài)模式（Static）和動態(tài)模式（Dynamic）。資源供應(yīng)的結(jié)果就是創(chuàng)建好的PV。

◎ 靜態(tài)模式：集群管理員手工創(chuàng)建許多PV，在定義PV時需要將后端存儲的特性進(jìn)行設(shè)置。
◎ 動態(tài)模式：集群管理員無須手工創(chuàng)建PV，而是通過StorageClass的設(shè)置對后端存儲進(jìn)行描述，標(biāo)記為某種類型。
此時要求PVC對存儲的類型進(jìn)行聲明，系統(tǒng)將自動完成PV的創(chuàng)建及與PVC的綁定。PVC可以聲明Class為""，說明該P(yáng)VC禁止使用動態(tài)模式。

下圖描述了在靜態(tài)資源供應(yīng)模式下的 PV 和 PVC 原理：

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

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