深入浅出聊聊Kubernetes存储（二）：搞定持久化存储
回 顧
在本系列文章的上一篇中，我們講到了PV，PVC，Storage Class以及Provisioner
簡單回顧一下：
PV在最一開始是設(shè)計成了一個需要管理員預(yù)先分配的存儲塊。引入Storage Class和Provisioner之后，用戶可以動態(tài)地供應(yīng)PV。
PVC是對PV的請求，當(dāng)和Storage Class一起使用時，它將觸發(fā)與相匹配PV的動態(tài)供應(yīng)。
PV和PVC總是一一對應(yīng)的。
Provisioner是給用戶提供PV的插件。它可以把管理員從為持久化創(chuàng)建工作負(fù)載的繁重角色中解脫出來。
Storage Class是PV的分類器。相同的Storage Class中的PV可以共享一些屬性。在大多數(shù)情況下，Storage Class和Provisioner一起使用時，可以把它當(dāng)作具有預(yù)定義屬性的Provisioner。因此，當(dāng)用戶請求它時，它能夠用這些預(yù)定義的屬性動態(tài)地提供PV。
不過上述這些只是在Kubernetes中使用持久化存儲的其中一種方法而已
Volume
在前一篇文章中，我們提到Kubernetes中還有一個卷（Volume）的概念。為了把Volume和持久卷（Persistent Volume）區(qū)分開，大家有時會稱它為In-line Volume或者Ephemeral Volume。
這里我們引用Volume的定義：
Kubernetes Volume…有一個顯式的生命周期——這和包含它的pod的生命周期相同。因此，Volume的生命周期比在pod中運行的任何容器都長，并且在容器重啟的時候會保存數(shù)據(jù)。當(dāng)然，當(dāng)Pod終止時，Volume也將終止。更重要的是，Kubernetes支持多種類型的Volume，一個pod中也可以同時使用任何數(shù)量的Volume。 在其核心部分，Volume只是一個目錄，可能其中包含了一些數(shù)據(jù)，這些數(shù)據(jù)可由pod中的容器訪問。這些目錄是如何產(chǎn)生的、支持它的介質(zhì)、以及它的內(nèi)容都是由所使用的特定volume的類型決定的。在其核心部分，Volume只是一個目錄，可能其中包含了一些數(shù)據(jù)，這些數(shù)據(jù)可由pod中的容器訪問。這些目錄是如何產(chǎn)生的、支持它的介質(zhì)、以及它的內(nèi)容都是由所使用的特定volume的類型決定的。Volume一個重要屬性是，它與所屬的pod具有相同的生命周期。如果pod消失了，它也會消失。這與Persistent Volume不同，因為Persistent Volume將繼續(xù)存在于系統(tǒng)中，直到用戶刪除它。Volume還可以在同一個pod中的容器間共享數(shù)據(jù)，不過這不是主要的用例，因為通常情況下用戶只會在每個pod中使用一個容器。
因此，這更可以把Volume看作是pod的屬性而不是一個獨立的對象。正如它的定義所說，Volume表示pod中的目錄，而Volume的類型定義了目錄中的內(nèi)容。例如，Config Map Volume類型將會在Volume目錄中從API服務(wù)器創(chuàng)建配置文件；PVC Volume類型將從目錄中相應(yīng)的PV里掛在文件系統(tǒng)等等。實際上，Volume幾乎是在pod中本地使用存儲的唯一方法。
Volume、Persistent Volume和持久卷聲明（Persistent Volume Claim）之間很容易弄混淆。假設(shè)有一個數(shù)據(jù)流，它是這樣PV->PVC->Volume。PV包含了真實數(shù)據(jù)，綁定到PVC上，最終變成pod中的Volume。
然而，除了PVC，Volume還可以由Kubernetes直接支持的各種類型的存儲庫支持，從這個意義上來說，Volume的定義也挺令人困惑的。
我們需要知道的事，我們已經(jīng)有了Persistent Volume，它支持不同類型的存儲解決方案。我們還有Provisioner，它支持類似（并不完全相同）的解決方案。而且我們還有不同類型的Volume。
那么，它們到底有什么不同呢？如何在它們之間選擇？
持久化數(shù)據(jù)的多種方式
以AWS EBS為例。讓我們來細(xì)數(shù)Kubernetes中的持久化數(shù)據(jù)方式吧。
Volume方式
awsElasticBlockStore是一個Volume類型。
你可以創(chuàng)建一個Pod，定義一個awsElasticBlockStore類型的volume，設(shè)置好volumeID，接著使用pod中存在的EBS volume。
該EBS volume在直接和Volume使用前必須已經(jīng)存在。
PV方式
AWSElasticBlockStore還是一個PV類型。
所以你可以創(chuàng)建一個PV，用它來表示EBS volume（假設(shè)你有這樣的權(quán)限），然后創(chuàng)建一個和它綁定的PVC卷。最后，令PVC作為volume，然后就可以在pod中使用它了。
和Volume方法類似，EBS volume在創(chuàng)建PV之前就必須存在。
Provisioner方式
kubernetes.io/aws-ebs是一個Kubernetes中用于EBS的內(nèi)置Provisioner。
你可以用Provisioner kubernetes.io/aws-ebs來創(chuàng)建一個Storage Class，通過Storage Class創(chuàng)建PVC。Kubernetes會自動為你創(chuàng)建相對應(yīng)的PV。接下來指定PVC為volume就可以在pod中使用了。
在本用例中，你不需要在使用使用之前創(chuàng)建EBS，EBS Provisioner會為你創(chuàng)建的。
第三方方式
上面列出的都是Kubernetes內(nèi)置選項，如果你不太滿意的話，其實還有一些使用Flexvolume driver格式的第三方EBS實現(xiàn)，它們可以幫助你和Kubernetes連接起來。
如果Flexvolume不適合你，還可以使用具備同樣功能的CSI drivers（為什么這么說？稍后會對此進行詳細(xì)介紹）
VolumeClaimTemplate方式
如果你在使用StatefulSet，那么恭喜你！你現(xiàn)在有額外多了一種使用工作負(fù)載中EBS的方式——VolumeClaimTemple。
VolumeClaimTemple是StatefulSet規(guī)范屬性，它為StatefulSet所創(chuàng)建的Pod提供了創(chuàng)建匹配PV和PVC的方式。這些PVC將通過Storage Class創(chuàng)建，這樣當(dāng)StatefulSet擴展時就可以自動創(chuàng)建它們。當(dāng)StatefulSet縮小時，多余的PV/PVCs會保留在系統(tǒng)中。因此，當(dāng)StatefulSet再一次擴展時，它們會再次作用于Kubernetes創(chuàng)建的新pods中。稍后我們會詳細(xì)講StatefulSet。
舉個例子說明，假設(shè)你用replica 3創(chuàng)建了一個名為www的StatefulSet，并用它創(chuàng)建了名為data的VolumeClaimTemplate。Kubernetes會創(chuàng)建3個pods，分別起名www-0、www-1、www-2。Kubernetes還會創(chuàng)建PVC，其中www-data-0用于pod www-0，www-data-1給www-1，www-data-2給www-2。如果你把StatefulSet擴展到5，Kubernetes就會分別創(chuàng)建www-3、www-data-3、www-4、www-data-4。如果接著將StatefulSet降為1，www-1到www-4全都會刪除，而www-data-1到www-data-4會保留在系統(tǒng)中。因此當(dāng)你決定再次擴展到5的時候，pod www-1到www-4又回被創(chuàng)建出來，而PVC www-data-1仍然會服務(wù)于Pod www-1，www-data-2對應(yīng)www-2，以此類推。這是因為StatefulSet中pod的身份在是stable的。使用StatefulSet時，名稱和關(guān)系都是可以預(yù)測的。
VolumeClaimTemple對于像EBS和Longhorn這樣的塊存儲解決方案非常重要。因為這些解決方案本質(zhì)上是ReadWriteOnce，你不能在Pod之間共享它們。如果你有不止一個運行了持久化數(shù)據(jù)的pod，那么就無法順利地進行部署。因此，VolumeClaimTemplate的出現(xiàn)為塊存儲解決方案提供了一種水平擴展Kubernetes工作負(fù)載的方式。
如何在Volume、Persistent Volume和Provisioner之間做出選擇
正如你所看到的，現(xiàn)在有了內(nèi)置的Volume類型、PV類型、Provisioner類型、以及使用Flexvolume和/或CSI的外部插件。讓人比較頭大的是，它們之間提供的功能基本相同，不過也有略微的區(qū)別。
我認(rèn)為，至少應(yīng)該有一個準(zhǔn)則來確定如何在它們之間選擇。
但是我并沒有找到。
所以我翻遍了代碼和文檔，畫出了下面的比較表格，以及對我來說最有意義的準(zhǔn)則，從Volume、Persistent Volume和Provisioner幾個方面進行對比。
這里我只涉及到Kubernetes中in-tree所支持的，除此之外一些官方的out-of-tree的Provisioners：
https://github.com/kubernetes...
可以看到，Volume、Persistent Volume以及Provisioner在一些細(xì)微的地方還是不一樣的。
A.它是連接PVC和pod的唯一方法
B.它也是唯一一個支持Config Map、Secret、Downward API以及Projected的。這些所有都與Kubernetes API服務(wù)器密切相關(guān)。
C.它還是唯一一個支持EmptyDir的，EmptyDir可以自動給pod分配和清理臨時volume。（注：早在2015年，Clayton Coleman就提出了一個關(guān)于支持EmptyDir的問題。這對于需要持久化儲存但只有本地卷可用的工作負(fù)載，這非常有用。可是這一觀點并沒有得到太多的關(guān)注。沒有scheduler的支持，這一目標(biāo)在當(dāng)時很難做到。而現(xiàn)在，在2018年，Kubernetes v1.11版本的Local Volume已經(jīng)加入scheduler和PV的節(jié)點親和支持（node affinity support），但是仍然沒有EmptyDir PV。而且Local Volume特性并不是我所期望的那樣，因為它并不具備在節(jié)點上使用新目錄創(chuàng)建新卷的能力。因此，我編寫了Local Path Provisioner，它利用scheduler和PV節(jié)點親和更改，為工作負(fù)載提供動態(tài)的Host Path type PV。）
在Volume、Persistent Volume和Provisioner之間選擇的準(zhǔn)則
那么用戶到底應(yīng)該選擇哪種方式呢？
在我看來，用戶們應(yīng)該堅持一個原則：
在條件允許的情況下，選擇Provisioner而不是Persistent Volume，接著再是Volume。
詳細(xì)來說：
a. 如果你想用異構(gòu)的Host Path Volume，它在Kubernetes v1.11版之后才能使用，因為之前缺少對PV的節(jié)點親和知識，使用v1.11+版本，你可以使用我的Local Path Provisioner創(chuàng)建帶有節(jié)點親和的Host Path PV：
https://github.com/rancher/lo...。
這個準(zhǔn)則背后的原理很簡單。在Kubernetes內(nèi)部進行操作時，對象（PV）比屬性（Volume）更容易管理，而且和手動創(chuàng)建PV相比，自動創(chuàng)建PV容易得多（Provisioner）。
不過這里有一個例外：如果你喜歡在Kubernetes外面進行存儲，那么最好使用Volume，盡管使用這種方式需要用到另一組API進行創(chuàng)建/刪除。此外，由于缺少VolumeClaimTemplate，會失去使用StatefulSet自動伸縮的能力。我不認(rèn)為這是多數(shù)Kubernetes用戶會選擇的方式。
為什么做同樣的事會有這么多選項？
當(dāng)我開始研究Kubernetes存儲時，首先想到的就是這個問題。由于缺乏一致性和直觀性，Kubernetes存儲看起來就像是事后才想到的。于是我試圖研究這些設(shè)計決策背后的歷史緣由，可是在2016之前都毫無收獲。
最后，我傾向于相信這些是由于一些早期的設(shè)計造成的，這可能是為獲取供應(yīng)商支持的迫切需求，導(dǎo)致安排給Volume比原本更多的責(zé)任。在我看來，所有復(fù)制了PV的內(nèi)置volume插件都不應(yīng)該存在。
在研究歷史的過程中，我發(fā)現(xiàn)在2016初發(fā)布的Kubernetes v1.2中，dynamic provisioning就已經(jīng)成為了alpha特性。它需要兩個發(fā)布版周期變成beta，在兩個周期實現(xiàn)穩(wěn)定，這都是非常合理的。
SIG Storage（它推動了Kubernetes存儲開發(fā)）還進行了大量的工作，使用Provisioner和CSI將Volume插件從tree中移出來。我認(rèn)為這是朝著更加一致、更加精簡的系統(tǒng)邁出了一大步。
可另一方面，我也不認(rèn)為這一大堆Volume類型會消失。這像是和硅谷非官方的格言唱反調(diào)：快速行動，打破常規(guī)。有時候，快速迭代的項目所遺留下來的設(shè)計，修改它們實在是太難了。我們只能和它們共處，在它們身邊小心工作，不要用錯誤的方式調(diào)用它們。
下一步
本系列的下一節(jié)中，我們將討論擴展Kubernetes存儲系統(tǒng)的機制，即Flexvolume和CSI。一個小小的提示：你可能注意到了，我并不是Flexvolume的粉絲，而且這不是存儲子系統(tǒng)的問題。
總結(jié)
以上是生活随笔為你收集整理的深入浅出聊聊Kubernetes存储（二）：搞定持久化存储的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 下一个全排列
- 下一篇： 全连接网络和卷积网络实践