❶ 存儲卷是什麼意思
其實就是硬碟分區，我們通常所用的硬碟叫做分區，伺服器用的動態磁碟的分區叫做卷
❷ 深入剖析k8s中的存儲
本文是《深入剖析k8s》學習筆記的第四篇，主要對k8s中的存儲數據卷進行分析和學喚臘習。
容器中的存儲是不穩定的，一旦容器重啟或者銷毀，這些存儲就都會丟失。所以真實使用場景下，都會以數據卷掛載的方式將外部存儲應用到容器中，帶來的好處就是：
在k8s中，如果要在容器中使用數據卷，需要像如下一個pod的yaml示例一樣進行聲明定義：
其中pod的定義中，聲明使用了自定義名稱為 my-volume 的數據卷，並且類型為emptyDir；k8s的volume支持多種數據類型，可以通過命令 kubectl explain pod.spec.volumes 來查看所有支持的volume類型，其中常用的類型及意義比較如下：
從工程分工角度上來說，存儲的定義和聲明應該由運維人員完成，開發人員只要使用即可。因此，為了避免將存儲細節過度地暴露給開發人員，k8s才引進了Persistent Volume Claim(PVC)和Persistent Volume(PV)這兩個API對象，同時也降低了開發人員使用存儲卷的門檻。如此，開發人員只需要如下兩步就能解決存儲卷的使用問題：
那麼開發人員聲明的PVC到底使用的是什麼存儲卷呢，這個和廳就由運維人員負責維護就行了，如下是一個PV的定義，開發人員了解即可：
為什麼這個PV可以和上面的PVC綁定呢？只要符合如下的條件，k8s就會自動將它們綁定，綁定後，在PVC的配置文件中就能看到使用的數據卷就是該PV了。
總的來說，PVC和PV的關系就像是介面和實現的關系，PVC是介面定義，聲明要使用什麼，至於怎麼實現，就是PV去完成的事情。如此解耦，使得開發和運維都能高效地搞定存儲。
假設開發人員在創建好帶有PVC的pod之後，且pod已經運行了，才發現運維還沒有來得及創建對應的PVC或者PVC創建有問題，致使pod存儲卷使用有問題該怎麼辦？只要運維及時創建對應的PV，k8s中的volume controller會循環遍歷沒有成功綁定PV的PVC，幫它們尋找喚鏈隱合適的PV進行綁定。
一個k8s集群往往有很多開發團隊在使用，開發會部署很多pod，如果這些pod都需要存儲卷，運維人員就需要天天創建pv來滿足開發人員pvc綁定的需求了，太浪費人力，所以這種重復工作就被k8s中的storageClass取代了。原先手動創建PV的方式被稱為static provisioning，使用storageClass自動創建PV的方式被稱為dynamic provisioning，storageClass其實就是PV的一個模板，其定義大致分為兩個部分：
在開發人員創建PVC的時候，只要指定使用的storageClassName是如上定義和創建的my-storageclass，那麼k8s就會根據該storageClass自動創建一個PV與該PVC綁定。