大白話說明白K8S的PV/PVC/StorageClass
先來個一句話總結：PV、PVC是K8S用來做存儲管理的資源對象，它們讓存儲資源的使用變得可控，從而保障系統的穩定性、可靠性。StorageClass則是為了減少人工的工作量而去自動化創建PV的組件。所有Pod使用存儲只有一個原則：先規劃 → 后申請 → 再使用。
一、理論
1、PV概念
PV是對K8S存儲資源的抽象，PV一般由運維人員創建和配置，供容器申請使用。
沒有PV之前，服務器的磁盤沒有分區的概念，有了PV之后，相當于通過PV對服務器的磁盤進行分區。
2、PVC概念
PVC 是Pod對存儲資源的一個申請，主要包括存儲空間申請、訪問模式等。創建PV后，Pod就可以通過PVC向PV申請磁盤空間了。類似于某個應用程序向操作系統的D盤申請1G的使用空間。
PVC 創建成功之后，Pod 就可以以存儲卷（Volume）的方式使用 PVC 的存儲資源了。Pod 在使用 PVC 時必須與PVC在同一個Namespace下。
3、PV / PVC的關系
PV相當于對磁盤的分區，PVC相當于APP（應用程序）向某個分區申請多少空間。比如說安裝WPS程序時，一般會告知我們安裝它需要多少存儲空間，讓你選擇在某個磁盤下安裝。如果將來某個分區磁盤滿了，也不會影響別的分區磁盤的使用。
一旦 PV 與PVC綁定，Pod就可以使用這個 PVC 了。如果在系統中沒有滿足 PVC 要求的 PV，PVC則一直處于 Pending 狀態，直到系統里產生了一個合適的 PV。
4、StorageClass概念
K8S有兩種存儲資源的供應模式：靜態模式和動態模式，資源供應的最終目的就是將適合的PV與PVC綁定：
- 靜態模式：管理員預先創建許多各種各樣的PV，等待PVC申請使用。
- 動態模式：管理員無須預先創建PV，而是通過StorageClass自動完成PV的創建以及與PVC的綁定。
StorageClass就是動態模式，根據PVC的需求動態創建合適的PV資源，從而實現存儲卷的按需創建。
一般某個商業性的應用程序，會用到大量的Pod，如果每個Pod都需要使用存儲資源，那么就需要人工時不時的去創建PV，這也是個麻煩事兒。解決方法就是使用動態模式：當Pod通過PVC申請存儲資源時，直接通過StorageClass去動態的創建對應大小的PV，然后與PVC綁定，所以基本上PV → PVC是一對一的關系。
5、Provisioner概念
在創建 PVC 時需要指定 StorageClass，PVC 選擇到對應的StorageClass后，與其關聯的 Provisioner 組件來動態創建 PV 資源。
那Provisioner是個啥呢？其實就一個存儲驅動，類似操作系統里的磁盤驅動。
StorageClass 資源對象的定義主要包括：名稱、Provisioner、存儲的相關參數配置、回收策略。StorageClass一旦被創建，則無法修改，只能刪除重新創建。
PV和PVC的生命周期，包括4個階段：資源供應（Provisioning）、資源綁定（Binding）、資源使用（Using）、資源回收（Reclaiming）。首先舊的有資源供應，說白了就是得有存儲驅動，然后才能創建、綁定和使用、回收。
6、使用PV / PVC前后對比
6.1、通過描述對比
在沒有使用PV、PVC之前，各個Pod都可以任意的向存儲資源里（比如NFS）寫數據，隨便一個Pod都可以往磁盤上插一杠子，長期下去磁盤的管理會越來越混亂，然后導致數據使用超限，磁盤爆掉，最后導致磁盤上的所有應用全部掛掉。
為了解決這個問題，引入了PV、PVC的概念，達到限制Pod寫入存儲數據大小的目的，從而更好地保障了系統的可用性、穩定性。
有了PVC、PV之后，所有Pod使用存儲資源，保持一個原則：先規劃 → 后申請 → 再使用。
那你肯定有一個疑問，“StorageClass是自動化創建PV，跟原本的無序不可控是一樣的效果啊，都可以隨便占用存儲資源啊”。
其實不然，使用StorageClass只是自動化了創建PV的流程，但依舊執行的是一個存儲可控的流程。每個Pod使用多少存儲空間是固定的，Pod沒有辦法超額使用存儲空間，更不會影響到別的應用，要出故障也只是某個Pod自己出故障。
6.2、通過圖片對比
沒有使用PV、PVC之前的情況，如下面2張圖：
有了PV、PVC之后的情況，如下圖：
二、實踐
在實踐PV、PVC、StorageClass之前，需要讀者朋友自行安裝NFS服務器。文中演示的內容是通過yaml編排自動到NFS服務器起上創建PV。
1、Pod使用PV、PVC掛載存儲卷
1.1、編排PV、PVC、Pod掛載PVC
文中演示的是：Pod的某個目錄掛載到NFS的某個目錄下。使用了nginx鏡像，將html文件寫在PV所在的NFS服務器上，最終可以看到利用PV / PVC 成功掛載上去了。
yaml文件如下：
# PV編排
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv1
namespace: dev1
labels:
pv: nfs-pv1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
# Recycle 刪除PVC會同步刪除PV | Retain 刪除PVC不會同步刪除PV
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data/nfstest/share/pv1
server: 10.20.1.20
readOnly: false
---
# PVC 編排，通過selector查找PV，K8S里的資源查找都是通過selector查找label標簽
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc1
namespace: dev1
labels:
pv: nfs-pvc1
spec:
resources:
requests:
storage: 100Mi
accessModes:
- ReadWriteOnce
selector:
matchLabels:
pv: nfs-pv1
---
# Pod掛載PVC，這里為了測試，直接通過node節點的hostPort暴露服務
apiVersion: v1
kind: Pod
metadata:
name: webapp
namespace: dev1
labels:
app: webapp
spec:
containers:
- name: webapp
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
hostPort: 8081
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
volumes:
- name: workdir
persistentVolumeClaim:
claimName: nfs-pvc1執行kubectl命令，查看實踐效果如下：
然后查看pod的情況，發現pod一直處于創建中，如下：
于是查看pod的情況kubectl describe pod webapp -n dev1，發現如下異常信息：
是因為沒有在NFS上創建此文件夾。到NFS創建此文件夾之后，重啟Pod，一切正常了，然后找到Pod所在Node節點。通過http://nodeip:port訪問，可以看到成功的界面：
[root@k8s-master pv-pvc-storageclass]# kubectl get pods -n dev1 -owide | grep webapp
webapp 1/1 Running 0 4m17s 10.21.69.214 k8s-worker-3 <none> <none>
此時因為nginx下還沒有html頁面，所以看不到內容。此時到NFS服務器對應的目錄/data/nfstest/share/pv1下增加index.html頁面，然后刷新頁面即可，界面如下：
也可以通過進入到Pod內部，查看驗證是夠掛載成功。
執行進入Pod的命令kubectl exec -it webapp -n dev1 -- /bin/sh，可以看到如下頁面：
2、Pod使用StorageClass自動掛載存儲卷
2.1、安裝 Provisioner
文中選擇通過helm的方式安裝nfs-subdir-external-provisioner，這種方式相對簡單。安裝文檔、安裝過程見下文：
- 安裝文檔：
https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#nfs
https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
- 安裝過程：
通過以下3個步驟完成nfs-subdir-external-provisioner的安裝。
- 安裝helm，本文以mac為例
brew install heml- 安裝nfs-subdir-external-provisioner，執行以下2個命令：
$ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
$ helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner -n kube-system \
--set image.repository=dyrnq/nfs-subdir-external-provisioner \
--set nfs.server=10.20.1.20 \
--set nfs.path=/data/nfstest/nfs-storage這里注意幾個參數：
image.repository：修改了鏡像的地址，默認用的國外鏡像很有可能拉不下來
nfs.server：你的NFS服務器地址
nfs.path：存儲目錄
- 查看helm安裝的結果：
執行命令：helm list -A，查看helm安裝結果：
查看是否創建了對應的pod，如果沒有修改鏡像地址會一直拉取失敗，如下圖：
修改鏡像地址后成功啟動Pod，如下圖：
2.2、使用StorageClass
文中演示的是：Pod利用StorageClass自動創建PV，同時在對應的存儲目錄上創建了文件，寫入了數據。
yaml文件如下：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-storage-1
provisioner: cluster.local/nfs-subdir-external-provisioner
parameters:
# 設置為"false"時刪除PVC不會保留數據，"true"則保留數據
archiveOnDelete: "false"
mountOptions:
# 指定NFS版本,這個需要根據NFS Server版本號設置
- nfsvers=4
---
# 創建PVC
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: nfs-storage-pvc-1
namespace: dev1
spec:
storageClassName: nfs-storage-1 #需要與上面創建的storageclass的名稱一致
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Mi
---
kind: Pod
apiVersion: v1
metadata:
name: nfs-storage-pod-1
namespace: dev1
spec:
containers:
- name: nfs-storage-pod-1
image: busybox
command:
- "/bin/sh"
args:
- "-c"
- "touch /mnt/teststorage && echo 111 > /mnt/teststorage && exit 0 || exit 1" ## 創建一個名稱為"SUCCESS"的文件
volumeMounts:
- name: nfs-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: nfs-storage-pvc-1執行kubectl命令后，可以看到如下效果：
可以看到如我們預料的那樣，通過storageClass自動創建了PV，同時在NFS對應的存儲目錄上創建了文件，寫入了數據。
至此，我們實踐過程全部結束。
三、總結
本文主要講解了PV、PVC、StorageClass的理論和實戰。
一句話總結：PV、PVC是K8S用來做存儲管理的資源對象，它們讓存儲資源的使用變得可控，從而保障系統的穩定性、可靠性。StorageClass則是為了減少人工的工作量而去自動化創建PV的組件。所有Pod使用存儲只有一個原則：先規劃 → 后申請 → 再使用。
