在本系列文章的上一篇中，我們講到了PV，PVC，Storage Class以及Provisioner

簡單回顧一下：

1. PV在最一開始是設計成了一個需要管理員預先分配的存儲塊。引入Storage Class和Provisioner之后，用戶可以動態地供應PV。

2. PVC是對PV的請求，當和Storage Class一起使用時，它將觸發與相匹配PV的動態供應。

3. PV和PVC總是一一對應的。

4. Provisioner是給用戶提供PV的插件。它可以把管理員從為持久化創建工作負載的繁重角色中解脫出來。

5. Storage Class是PV的分類器。相同的Storage Class中的PV可以共享一些屬性。在大多數情況下，Storage Class和Provisioner一起使用時，可以把它當作具有預定義屬性的Provisioner。因此，當用戶請求它時，它能夠用這些預定義的屬性動態地提供PV。

不過上述這些只是在Kubernetes中使用持久化存儲的其中一種方法而已

在前一篇文章中，我們提到Kubernetes中還有一個卷（Volume）的概念。為了把Volume和持久卷（Persistent Volume）區分開，大家有時會稱它為In-line Volume或者Ephemeral Volume。

Volume一個重要屬性是，它與所屬的pod具有相同的生命周期。如果pod消失了，它也會消失。這與Persistent Volume不同，因為Persistent Volume將繼續存在于系統中，直到用戶刪除它。Volume還可以在同一個pod中的容器間共享數據，不過這不是主要的用例，因為通常情況下用戶只會在每個pod中使用一個容器。

因此，這更可以把Volume看作是pod的屬性而不是一個獨立的對象。正如它的定義所說，Volume表示pod中的目錄，而Volume的類型定義了目錄中的內容。例如，Config Map Volume類型將會在Volume目錄中從API服務器創建配置文件；PVC Volume類型將從目錄中相應的PV里掛在文件系統等等。實際上，Volume幾乎是在pod中本地使用存儲的唯一方法。

Volume、Persistent Volume和持久卷聲明（Persistent Volume Claim）之間很容易弄混淆。假設有一個數據流，它是這樣PV->PVC->Volume。PV包含了真實數據，綁定到PVC上，最終變成pod中的Volume。

然而，除了PVC，Volume還可以由Kubernetes直接支持的各種類型的存儲庫支持，從這個意義上來說，Volume的定義也挺令人困惑的。

我們需要知道的事，我們已經有了Persistent Volume，它支持不同類型的存儲解決方案。我們還有Provisioner，它支持類似（并不完全相同）的解決方案。而且我們還有不同類型的Volume。

那么，它們到底有什么不同呢？如何在它們之間選擇？

以AWS EBS為例。讓我們來細數Kubernetes中的持久化數據方式吧。

Volume方式

awsElasticBlockStore是一個Volume類型。

你可以創建一個Pod，定義一個awsElasticBlockStore類型的volume，設置好volumeID，接著使用pod中存在的EBS volume。

該EBS volume在直接和Volume使用前必須已經存在。

PV方式

AWSElasticBlockStore還是一個PV類型。

所以你可以創建一個PV，用它來表示EBS volume（假設你有這樣的權限），然后創建一個和它綁定的PVC卷。最后，令PVC作為volume，然后就可以在pod中使用它了。

和Volume方法類似，EBS volume在創建PV之前就必須存在。

Provisioner方式

kubernetes.io/aws-ebs是一個Kubernetes中用于EBS的內置Provisioner。

你可以用Provisioner kubernetes.io/aws-ebs來創建一個Storage Class，通過Storage Class創建PVC。Kubernetes會自動為你創建相對應的PV。接下來指定PVC為volume就可以在pod中使用了。

在本用例中，你不需要在使用使用之前創建EBS，EBS Provisioner會為你創建的。

第三方方式

上面列出的都是Kubernetes內置選項，如果你不太滿意的話，其實還有一些使用Flexvolume driver格式的第三方EBS實現，它們可以幫助你和Kubernetes連接起來。

如果Flexvolume不適合你，還可以使用具備同樣功能的CSI drivers（為什么這么說？稍后會對此進行詳細介紹）

VolumeClaimTemplate方式

如果你在使用StatefulSet，那么恭喜你！你現在有額外多了一種使用工作負載中EBS的方式——VolumeClaimTemple。

VolumeClaimTemple是StatefulSet規范屬性，它為StatefulSet所創建的Pod提供了創建匹配PV和PVC的方式。這些PVC將通過Storage Class創建，這樣當StatefulSet擴展時就可以自動創建它們。當StatefulSet縮小時，多余的PV/PVCs會保留在系統中。因此，當StatefulSet再一次擴展時，它們會再次作用于Kubernetes創建的新pods中。稍后我們會詳細講StatefulSet。

舉個例子說明，假設你用replica 3創建了一個名為www的StatefulSet，并用它創建了名為data的VolumeClaimTemplate。Kubernetes會創建3個pods，分別起名www-0、www-1、www-2。Kubernetes還會創建PVC，其中www-data-0用于pod www-0，www-data-1給www-1，www-data-2給www-2。如果你把StatefulSet擴展到5，Kubernetes就會分別創建www-3、www-data-3、www-4、www-data-4。如果接著將StatefulSet降為1，www-1到www-4全都會刪除，而www-data-1到www-data-4會保留在系統中。因此當你決定再次擴展到5的時候，pod www-1到www-4又回被創建出來，而PVC www-data-1仍然會服務于Pod www-1，www-data-2對應www-2，以此類推。這是因為StatefulSet中pod的身份在是stable的。使用StatefulSet時，名稱和關系都是可以預測的。

VolumeClaimTemple對于像EBS和Longhorn這樣的塊存儲解決方案非常重要。因為這些解決方案本質上是ReadWriteOnce，你不能在Pod之間共享它們。如果你有不止一個運行了持久化數據的pod，那么就無法順利地進行部署。因此，VolumeClaimTemplate的出現為塊存儲解決方案提供了一種水平擴展Kubernetes工作負載的方式。

正如你所看到的，現在有了內置的Volume類型、PV類型、Provisioner類型、以及使用Flexvolume和/或CSI的外部插件。讓人比較頭大的是，它們之間提供的功能基本相同，不過也有略微的區別。

我認為，至少應該有一個準則來確定如何在它們之間選擇。

但是我并沒有找到。

所以我翻遍了代碼和文檔，畫出了下面的比較表格，以及對我來說最有意義的準則，從Volume、Persistent Volume和Provisioner幾個方面進行對比。

這里我只涉及到Kubernetes中in-tree所支持的，除此之外一些官方的out-of-tree的Provisioners：

https://github.com/kubernetes-incubator/external-storage

可以看到，Volume、Persistent Volume以及Provisioner在一些細微的地方還是不一樣的。

1.    Volume支持大部分的volume插件。

       A.它是連接PVC和pod的唯一方法

       B.它也是唯一一個支持Config Map、Secret、Downward API以及Projected的。這些所有都與Kubernetes API服務器密切相關。

       C.它還是唯一一個支持EmptyDir的，EmptyDir可以自動給pod分配和清理臨時volume。（注：早在2015年，Clayton Coleman就提出了一個關于支持EmptyDir的問題。這對于需要持久化儲存但只有本地卷可用的工作負載，這非常有用。可是這一觀點并沒有得到太多的關注。沒有scheduler的支持，這一目標在當時很難做到。而現在，在2018年，Kubernetes v1.11版本的Local Volume已經加入scheduler和PV的節點親和支持（node affinity support），但是仍然沒有EmptyDir PV。而且Local Volume特性并不是我所期望的那樣，因為它并不具備在節點上使用新目錄創建新卷的能力。因此，我編寫了Local Path Provisioner，它利用scheduler和PV節點親和更改，為工作負載提供動態的Host Path type PV。）

2.    PV支持的插件是Provisioner支持的超集，因為Provisioner需要在工作負載使用它之前創建PV。但是，還有一些PV支持而Provisioner不支持的插件，比如Local Volume（正在進行修改中）。

3.    還有兩種類型Volume是不支持的。他們是兩個最新的特性：CSI和Local Volume，現在還有一些正在進行的工作，會在之后把它們用于Volume。

那么用戶到底應該選擇哪種方式呢？

在我看來，用戶們應該堅持一個原則：

在條件允許的情況下，選擇Provisioner而不是Persistent Volume，接著再是Volume。

詳細來說：

1.    對于Config Map、Downward API、Secret或者Projected，請使用Volume，因為PV不支持它們。

2.    對于EmptyDir，直接使用Volume，或者使用Host Path來代替。

3.    對于Host Path，通常是直接使用Volume，因為它綁定到一個特定的節點，并且節點之間它是同構的。

a.    如果你想用異構的Host Path Volume，它在Kubernetes v1.11版之后才能使用，因為之前缺少對PV的節點親和知識，使用v1.11+版本，你可以使用我的Local Path Provisioner創建帶有節點親和的Host Path PV：

https://github.com/rancher/local-path-provisioner。

4.    對于其他的情況，除非你需要和現有的卷掛鉤（這種情況下你應該使用PV），否則就使用Provisioner代替。有些Provisioner并不是內置的選項，但是你應該能在此鏈接（https://github.com/kubernetes-incubator/external-storage）或者供應商的官方倉庫中找到它們。

這個準則背后的原理很簡單。在Kubernetes內部進行操作時，對象（PV）比屬性（Volume）更容易管理，而且和手動創建PV相比，自動創建PV容易得多（Provisioner）。

不過這里有一個例外：如果你喜歡在Kubernetes外面進行存儲，那么最好使用Volume，盡管使用這種方式需要用到另一組API進行創建/刪除。此外，由于缺少VolumeClaimTemplate，會失去使用StatefulSet自動伸縮的能力。我不認為這是多數Kubernetes用戶會選擇的方式。

當我開始研究Kubernetes存儲時，首先想到的就是這個問題。由于缺乏一致性和直觀性，Kubernetes存儲看起來就像是事后才想到的。于是我試圖研究這些設計決策背后的歷史緣由，可是在2016之前都毫無收獲。

最后，我傾向于相信這些是由于一些早期的設計造成的，這可能是為獲取供應商支持的迫切需求，導致安排給Volume比原本更多的責任。在我看來，所有復制了PV的內置volume插件都不應該存在。

在研究歷史的過程中，我發現在2016初發布的Kubernetes v1.2中，dynamic provisioning就已經成為了alpha特性。它需要兩個發布版周期變成beta，在兩個周期實現穩定，這都是非常合理的。

SIG Storage（它推動了Kubernetes存儲開發）還進行了大量的工作，使用Provisioner和CSI將Volume插件從tree中移出來。我認為這是朝著更加一致、更加精簡的系統邁出了一大步。

可另一方面，我也不認為這一大堆Volume類型會消失。這像是和硅谷非官方的格言唱反調：快速行動，打破常規。有時候，快速迭代的項目所遺留下來的設計，修改它們實在是太難了。我們只能和它們共處，在它們身邊小心工作，不要用錯誤的方式調用它們。

本系列的下一節中，我們將討論擴展Kubernetes存儲系統的機制，即Flexvolume和CSI。一個小小的提示：你可能注意到了，我并不是Flexvolume的粉絲，而且這不是存儲子系統的問題。