- 1. PersistentVolume(PV)簡介
- 2. PersistentVolume(PV)的分類
- 3. PersistentVolumeClaim(PVC)的保護
- 4. PersistentVolume(PV)支援的底層儲存型別
- 5. PersistentVolume(PV)的資源清單
- 6. PersistentVolume(PV)的狀態
- 7. 實驗-持久化演示說明-NFS
- 8. 關於 Statefulset
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支援的型別差不多
GCEPersistentDiskAWSElasticBlockStoreAzureFileAzureDiskFC(Fibre Channel)FlexVolumeFlockerNFSiSCSIRBD(Ceph Block Device)CephFSCinder(OpenStack block storage)GlusterfsVsphereVolumeQuobyteVolumesHostPathVMwarePhotonPortworx VolumesScalelo VolumesStorageOS
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-ReadWriteOnceROX-ReadOnlyManyRWX-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 來實現。
- 有序收縮。