所屬技術領域：
K8s
|名詞定義|
PersistentVolumeClaim（簡稱PVC）是使用者存儲的請求，PVC消耗PV的資源，可以請求特定的大小和通路模式，需要指定歸屬于某個Namespace，在同一個Namespace的Pod才可以指定對應的PVC。
當需要不同性質的PV來滿足存儲需求時，可以使用StorageClass來實作。
每個 PVC 中都包含一個 spec 規格字段和一個 status 聲明狀态字段。
|技術特點|
有了PV,為什麼又設計了PVC？
1.職責分離，PVC中隻用聲明自己需要的存儲size、access mode（單node獨占還是多node共享？隻讀還是讀寫通路？）等業務真正關心的存儲需求（不用關心存儲實作細節），PV和其對應的後端存儲資訊則由交給cluster admin統一運維和管控，安全通路政策更容易控制。
2.PVC簡化了User對存儲的需求，PV才是存儲的實際資訊的承載體，通過kube-controller-manager中的persistentVolumeController将PVC與合适的PV bound到一起，進而滿足User 對存儲的實際需求。
3.PVC像是面向對對象程式設計中抽象出來的接口，PV是接口對應的實作。
建立PVC
PVC 的檔案裡存儲的大小、通路模式是不變的。現在需要新加一個字段，叫 StorageClassName，它的意思是指定動态建立 PV 的模闆檔案的名字，這裡 StorageClassName 填的就是上面聲明的 csi-disk。
在送出完 PVC之後，K8s 叢集中的相關元件就會根據 PVC 以及對應的 StorageClass 動态生成這塊 PV 給這個 PVC 做一個綁定，之後使用者在送出自己的 yaml 時，用法和接下來的流程和前面的靜态使用方式是一樣的，通過 PVC 找到我們動态建立的 PV，然後把它挂載到相應的容器中就可以使用了。
PVC 的 yaml
寫的是我需要的大小以及我需要的 accessModes。送出完之後，它就與我們叢集中已經存在的 PV 做比對，比對成功之後，它就會做 bound。
PVC 的處理流程
csi 是什麼？csi 的全稱是 container storage interface，它是 K8s 社群後面對存儲插件實作 ( out of tree ) 的官方推薦方式。
接下來看一下，當使用者送出 yaml 之後，k8s 内部的處理流程。使用者在送出 PVCyaml 的時候，首先會在叢集中生成一個 PVC 對象，然後 PVC 對象會被 csi-provisioner controller watch 到，csi-provisioner 會結合 PVC 對象以及 PVC 對象中聲明的 storageClass，通過 GRPC 調用 csi-controller-server，然後，到雲存儲服務這邊去建立真正的存儲，并最終建立出來 PV 對象。最後，由叢集中的 PV controller 将 PVC 和 PV 對象做 bound 之後，這個 PV 就可以被使用了。
使用者在送出 pod 之後，首先會被排程器排程選中某一個合适的node，之後該 node 上面的 kubelet 在建立 pod 流程中會通過首先 csi-node-server 将我們之前建立的 PV 挂載到我們 pod 可以使用的路徑，然後 kubelet 開始 create && start pod 中的所有 container。
|資料來源|
名詞定義:
https://blog.csdn.net/huwh_/article/details/96016049