文章目錄
- 1. pv與pvc
- 1.1 區別
- 1.2 宣告周期
- 2. pv持久卷
- 2.1 容量 capacity
- 2.2 卷模式 volumeModes
- 2.3 訪問模式 accessModes
- 2.4 類 storageClassName
- 2.5 回收策略
- 2.6 狀態
- 3. pvc
- 4. nfs持久化存盤示例
1. pv與pvc
pv持久卷之官方檔案
1.1 區別
存盤的管理是一個與計算實體的管理完全不同的問題,PersistentVolume 子系統為用戶 和管理員提供了一組 API,將存盤如何供應的細節從其如何被使用中抽象出來, 為了實作這點,我們引入了兩個新的 API 資源:
PersistentVolume和PersistentVolumeClaim
- 持久卷(PersistentVolume,PV)是集群中的一塊存盤,可以由管理員事先供應,或者 使用存盤類(Storage Class)來動態供應, 持久卷是集群資源,就像節點也是集群資源一樣,PV 持久卷和普通的 Volume 一樣,也是使用 卷插件來實作的,只是它們擁有獨立于任何使用 PV 的 Pod 的生命周期, 此 API 物件中記述了存盤的實作細節,無論其背后是 NFS、iSCSI 還是特定于云平臺的存盤系統,
- 持久卷宣告(PersistentVolumeClaim,PVC)表達的是用戶對存盤的請求,概念上與 Pod 類似, Pod 會耗用節點資源,而 PVC 申領會耗用 PV 資源,Pod 可以請求特定數量的資源(CPU 和記憶體);同樣 PVC 申領也可以請求特定的大小和訪問模式 (例如,可以要求 PV 卷能夠以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一來掛載,參見訪問模式),
1.2 宣告周期
PV 卷是集群中的資源,PVC 宣告是對這些資源的請求,也被用來執行對資源的申領檢查,
pv卷的提供方式:
- 靜態:集群管理員創建若干 PV 卷,這些卷物件帶有真實存盤的細節資訊,并且對集群 用戶可用(可見),PV 卷物件存在于 Kubernetes API 中,可供用戶消費(使用)
- 動態:當管理員創建的靜態PV都不匹配用戶的PVC時,集群可能會嘗試專門地供給volume給PVC,這種供給基于StorageClass
系結:
PVC與PV的系結是一對一的映射,沒找到匹配的PV,那么PVC會無限期得處于unbound未系結狀態,
使用:
Pod使用PVC就像使用volume一樣,集群檢查PVC,查找系結的PV,并映射PV給Pod,對于支持多種訪問模式的PV,用戶可以指定想用的模式,一旦用戶擁有了一個PVC,并且PVC被系結,那么只要用戶還需要,PV就一直屬于這個用戶, 用戶調度Pod,通過在Pod的volume塊中包含PVC來訪問PV,
釋放:
當用戶使用PV完畢后,他們可以通過API來洗掉PVC物件,當PVC被洗掉后,對應的PV就被認為是已經是“released" 了,但還不能再給另外一個PVC使用, 前一個PVC的屬于還存在于該PV中,必須根據策略來處理掉,
回收:
PV的回收策略告訴集群,在PV被釋放之后集群應該如何處理該PV,當前,PV可以被Retained (保留) 、Recycled (再利用)或者Deleted (洗掉),保留允許手動地再次宣告資源,對于支持洗掉操作的PV卷,洗掉操作會從Kubemetes中移除PV物件,還有對應的外部存盤(如AWS EBS,GCE PD,Azure Disk,或者 Cinder volume),動態供給的卷總是會被洗掉,
2. pv持久卷
每個 PV 物件都包含:
spec:卷的規約status:卷的狀態,
2.1 容量 capacity
一般而言,每個 PV 卷都有確定的存盤容量, 容量屬性是使用 PV 物件的 capacity 屬性來設定的,
目前,存盤大小是可以設定和請求的唯一資源, 未來可能會包含 IOPS、吞吐量等屬性,
2.2 卷模式 volumeModes
針對 PV 持久卷,Kuberneretes 支持兩種卷模式(volumeModes):
- Filesystem(檔案系統) (默認):volumeMode 屬性設定為 Filesystem 的卷會被 Pod 掛載(Mount) 到某個目錄, 如果卷的存盤來自某塊設備而該設備目前為空,Kuberneretes 會在第一次掛載卷之前 在設備上創建檔案系統,
- Block(塊):可以將 volumeMode 設定為 Block,以便將卷作為原始塊設備來使用, 這類卷以塊設備的方式交給 Pod 使用,其上沒有任何檔案系統, 這種模式對于為 Pod 提供一種使用最快可能方式來訪問卷而言很有幫助,Pod 和 卷之間不存在檔案系統層,另外,Pod 中運行的應用必須知道如何處理原始塊設備,
2.3 訪問模式 accessModes
PersistentVolume 卷可以用資源提供者所支持的任何方式掛載到宿主系統上, 如下表所示,提供者(驅動)的能力不同,每個 PV 卷的訪問模式都會設定為 對應卷所支持的模式值, 例如,NFS 可以支持多個讀寫客戶,但是某個特定的 NFS PV 卷可能在服務器 上以只讀的方式匯出,每個 PV 卷都會獲得自身的訪問模式集合,描述的是 特定 PV 卷的能力,
訪問模式有:
- ReadWriteOnce -該volume只能被單個節點以讀寫的方式映射
- ReadOnlyMany --該volume可以被多個節點以只讀方式映射
- ReadWriteMany -該volume可以被多個節點以讀寫的方式映射
在命令列介面(CLI)中,訪問模式可以簡寫為:
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
重要提醒! 每個卷只能同一時刻只能以一種訪問模式掛載,即使該卷能夠支持 多種訪問模式,例如,一個 GCEPersistentDisk 卷可以被某節點以 ReadWriteOnce 模式掛載,或者被多個節點以 ReadOnlyMany 模式掛載,但不可以同時以兩種模式 掛載,
| 卷插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
|---|---|---|---|
| AWSElasticBlockStore | ? | - | - |
| AzureFile | ? | ? | ? |
| AzureDisk | ? | - | - |
| CephFS | ? | ? | ? |
| Cinder | ? | - | - |
| CSI | 取決于驅動 | 取決于驅動 | 取決于驅動 |
| FC | ? | ? | - |
| FlexVolume | ? | ? | 取決于驅動 |
| Flocker | ? | - | - |
| GCEPersistentDisk | ? | ? | - |
| Glusterfs | ? | ? | ? |
| HostPath | ? | - | - |
| iSCSI | ? | ? | - |
| Quobyte | ? | ? | ? |
| NFS | ? | ? | ? |
| RBD | ? | ? | - |
| VsphereVolume | ? | - | - (Pod 運行于同一節點上時可行) |
| PortworxVolume | ? | - | ? |
| ScaleIO | ? | ? | - |
| StorageOS | ? | - | - |
2.4 類 storageClassName
每個 PV 可以屬于某個類(Class),通過將其 storageClassName 屬性設定為某個 StorageClass 的名稱來指定, 特定類的 PV 卷只能系結到請求該類存盤卷的 PVC 申領, 未設定 storageClassName 的 PV 卷沒有類設定,只能系結到那些沒有指定特定 存盤類的 PVC 申領,
2.5 回收策略
persistentVolumeReclaimPolicy
- Retain:保留,需要手動回收
- Recycle:回收,自動洗掉卷中敬據
- Delete:洗掉,相關聯的存盤資產,如AWS EBS, GCE PD, Azure Disk, or
OpenStack Cinder卷都會被洗掉
當前,只有 NFS 和 HostPath 支持回收利用,AWS EBS, GCE PD, Azure Disk 和 OpenStack Cinder卷支持洗掉(Delete)操作,
2.6 狀態
- Available(可用):空閑的資源,尚未系結給PVC
- Bound(已系結):系結給了某個PVC
- Released(已釋放):PVC已經洗掉了,但是PV資源尚未被集群回收
- Failed(失敗):卷的自動回收操作失敗
命令列可以顯示PV系結的PVC名稱,
3. pvc
每個 PV 物件都包含:
spec:卷的規約status:卷的狀態,
訪問模式 (accessModes)
申領在請求具有特定訪問模式的存盤時,使用與卷相同的訪問模式約定,
卷模式 (volumeModes)
申領使用與卷相同的約定來表明是將卷作為檔案系統還是塊設備來使用,
資源 (resources)
申領和 Pod 一樣,也可以請求特定數量的資源,在這個背景關系中,請求的資源是存盤, 卷和申領都使用相同的 資源模型
4. nfs持久化存盤示例
1)在nfs服務器建立目錄 /nfsdata/pv1、/nfsdata/pv2、/nfsdata/pv3,并寫入測驗頁

2)創建pv
- pv1:5Gi,RWO模式,Recycle模式,/nfsdata/pv1
- pv2:10Gi,RWM模式,Recycle模式,/nfsdata/pv2
- pv3:20Gi,ROM模式,Recycle模式,/nfsdata/pv3
# pv.yml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity: # 容量
storage: 5Gi
volumeMode: Filesystem # 卷模式
accessModes: # 訪問模式
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle #回收策略
storageClassName: nfs #類
nfs: # nfs服務器
path: /nfsdata/pv1 # 掛載位置
server: 192.168.17.250 #服務器地址
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2
spec:
capacity:
storage: 10Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
path: /nfsdata/pv2
server: 192.168.17.250
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv3
spec:
capacity:
storage: 20Gi
volumeMode: Filesystem
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
path: /nfsdata/pv3
server: 192.168.17.250

3)創建pvc
- pvc1:5Gi,RWO(pvc1滿足pv1的條件)
- pvc2:10Gi,RWM(pvc2滿足pv2的條件)
# pvc.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
storageClassName: nfs
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc2
spec:
storageClassName: nfs
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi

4)創建pod:在容器掛載的node節點宿主機一定要安裝 nfs-utils
.
- test-pd-1:掛載pvc1
- test-pd-2:掛載pvc2
apiVersion: v1
kind: Pod
metadata:
name: test-pd-1
spec:
containers:
- image: myapp:v1
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nfs-pv-1
volumes:
- name: nfs-pv-1
persistentVolumeClaim:
claimName: pvc1
---
apiVersion: v1
kind: Pod
metadata:
name: test-pd-2
spec:
containers:
- image: myapp:v1
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nfs-pv-2
volumes:
- name: nfs-pv-2
persistentVolumeClaim:
claimName: pvc2

5)測驗成功!資料共享成功!

6)洗掉pvc,發現pv的狀態變為已釋放,過一會會后,資源被回收變為可利用(Available)

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/267049.html
標籤:其他
