深入淺出聊聊Kubernetes存儲
近年來一直關注云計算領域的人，必定知道Docker和Kubernetes的崛起。如今，世界范圍內的公有云巨頭(谷歌、亞馬遜、微軟、華為云、阿里云等等)都在其傳統的公共云服務之上提供托管的Kubernetes服務。Kubernetes功能強大、擴展性高，在許多人看來，它正在成為云計算的終極解決方案。
但不得不說的是，盡管Kubernetes建立在谷歌在生產環境運行工作負載的超過15年的經驗之上，它非常復雜，一些設計決策總是讓用戶難以理解。即使對于經驗最豐富的工程師來說，Kubernetes的學習曲線也很陡峭。
就以存儲來舉例。你知道PV和PVC的區別嗎?storage class和provisioner的關系是什么?VolumeClaimTemplates是什么?什么時候該用statefulset?
在本文中，我將嘗試解釋Kubernetes中的一些關鍵概念，以及我對它們的看法。我希望這也會幫助大家更多地了解Kubernetes。使用Kubernetes時，有許多設計選擇和警告讓我意想不到。今天我將講講PV、PVC、Storage Class和Provisioner。
Docker中的Volume(卷)
在深入了解Kubernetes之前，讓我們先聊聊Docker——畢竟Kubernetes是構建在Docker之上。
Docker因其簡單易用聞名，這也是Docker能如此受歡迎，并成為Kubernetes基礎的原因。Docker容器是無狀態、快速的，它可以被破壞、重建，而不需要付出太多的代價。但是，就像是患了健忘癥的人，想要記住有意義的事情是很困難的一樣。無論是數據庫、鍵值存儲、還是一些原始數據，每一個都需要持久化存儲。
在Docker中創建持久化存儲非常簡單。早期版本中，用戶可以使用-v來創建一個新的未定義大小的匿名空卷或者在主機上的目錄中創建綁定掛載。那個時候，雖然可以很容易地通過掛載那些已經被存儲供應商掛載在主機上的目錄，但沒有第三方接口幫助你直接掛載到Docker上。2015年8月，Docker發布了v1.8版本，正式引入了卷插件，允許第三方連接它們的存儲解決方案。Docker會調用已安裝的卷插件來創建/刪除/掛載/卸載/get/list那些相關卷，而且每個卷都有一個名字，直到今天，卷插件的框架基本仍保持不變。
持久卷和持久卷聲明
當你想弄清楚如何在Kubernetes中創建持久存儲時，可能會遇到兩個概念：持久卷(Persistent Volume，PV)和持久卷聲明(Persistent Volume Claim，PVC)
它們是什么?它們中哪個更接近Docker中的卷?
實際上，它們都不像Docker中的卷。除了PV和PVC之外，Kubernetes還有一個Volume的概念，但它與Docker中的概念不同，稍后我們會討論它。
如果你了解一些關于PV和PVC信息，可能會意識到PV就是分配的存儲，而PVC是使用該存儲的請求。如果以前你有云計算或存儲的經驗，那么你可能會認為PV就是一個存儲池，而PVC是一個從存儲池中分割出來的卷。
不過這都不是PV和PVC真正的意義，在Kubernetes中，一個PV映射到一個PVC，反之亦然，它是一對一的映射。
我已經多次給具有豐富存儲和云計算經驗的人解釋過這些問題，他們幾乎都是抓耳撓腮，不明白這是怎么回事。
而在我第一次遇到這兩個概念的時候，我也沒法理解。
我們在這里列出PV和PVC的定義
PersistentVolume(PV)是集群中由管理員配置的一塊存儲。它是集群中的資源，就和節點是集群資源一樣。PV是卷插件比如Volumes，但是它的生命周期獨立于使用PV的任何pod個體。該API對象捕獲實現存儲的詳細信息，包括NFS、iSCSI或著是云服務商特定的存儲系統。
PersistentVolumeClaim(PVC)是用戶關于存儲的請求。它類似于一個pod，pod消耗節點資源，而PVC消耗PV資源。Pods可以請求特定級別的資源(CPU和內容)，而Claim可以請求特定的大小和訪問模式(例如，可以一次讀/寫或者多次只讀)。
這里需要留意的是“管理員”以及“用戶”的區別。
簡而言之，Kubernetes將基本存儲單元分為兩個概念。PV是一個存儲器，應該由管理員預先分配，而PVC是用戶對存儲的請求。
也就是說，Kubernetes希望管理員來實現分配各種大小的PV。當用戶創建PVC來請求存儲時，Kubernetes將嘗試用該PVC和預先分配的PV匹配。如果可以找到匹配項，就將PVC綁定到PV，用戶就可以開始使用這片預分配的存儲區。
這種方式和傳統方法不同，傳統方法中管理員并不負責分配每個存儲空間。他們只需要授予用戶訪問某個存儲池的權限，并且確定該用戶的配額是多少，然后讓用戶從存儲池中分割出所需的存儲部分即可。
不過在Kubernetes的設計中，PV已經從存儲池中分割了出來，等待和PVC進行匹配，因此用戶只能請求到預先分配的固定大小的存儲空間。這就出現了兩種情況：
- 如果用戶只需要1GiB的卷，而可用的最小PV是1TiB，那么用戶就必須使用這個1TiB的卷。這樣之后其他用戶就沒法使用到這個卷，而這些用戶可能需求的容量超過了1GiB。這不僅會造成存儲空間的浪費，還會導致由于資源限制無法啟動某些工作負載的情況，而其他的工作負載可能正占有了不需要的資源。
- 為了解決第一個問題，管理員要么需要不斷地和用戶保持通信，確定用戶需要的存儲大小/性能，要么就預測好需求，并相應地預先分配PV。
這樣一來就很難強制執行單獨的分配(PV)和使用(PVC)。在實際使用中，我并沒有看到大家講PV和PVC作為他們的設計方式。很可能管理員很快就放棄了創建PV的權限并把它委托給用戶執行。由于PV和PVC仍然是一對一的綁定，PVC的存在就變得不那么必要了。
在我看來，至少可以說，使用PV和PVC的示例是不常見的。
Storage Class和Provisioner
可能因為PV和PVC使用起來太麻煩了，在2017年3月，隨著v1.6版本的發布，Kubernetes引入了動態納管(dynamic provisioning)、Storage Class和Provisioner的概念。動態納管與傳統存儲方法類似。管理員可以使用Storage Class來描述他們提供的存儲“class”。Storage Class可以有不同的容量限制、不同的IOPS或其他Provisioner支持的參數。特定于存儲供應商的Provisioner將與Storage Class一起使用，根據Storage Class對象中設置的參數自動分配PV。此外，Provisioner現在能夠強制執行用戶的報價(quotes)和權限要求。在這種設計中，管理員已經從預測和分配PV的繁瑣中擺脫出來，這樣的方式更有意義。
另外，你還可以使用Storage Class而無需在Kubernetes中創建Storage Class對象。由于Storage Class也是用于PVC和PV(不必由Provisioner創建)的字段，因此你可以使用自定義的Storage Class名稱手動創建PV，然后創建一個請求相同Storage Class名稱的PVC。即使存儲類Storage Class對象不存在，Kubernetes也會將PVC綁定到具有相同存儲類名稱的PV上。
dynamic provisioning、Storage Class以及Provisioner對我來說非常有意義，它解決了最初的PV和PVC設計中最大的可用性問題。但與此同時，這些新概念也加劇了Kubernetes存儲的另一個問題，即處理持久存儲的各種方式造成的混亂。
