深入浅出聊聊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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 下一个全排列
- 下一篇: 全连接网络和卷积网络实践