近年來(lái)一直關(guān)注云計(jì)算領(lǐng)域的人，必定知道Docker和Kubernetes的崛起。如今，世界范圍內(nèi)的公有云巨頭(谷歌、亞馬遜、微軟、華為云、阿里云等等)都在其傳統(tǒng)的公共云服務(wù)之上提供托管的Kubernetes服務(wù)。Kubernetes功能強(qiáng)大、擴(kuò)展性高，在許多人看來(lái)，它正在成為云計(jì)算的***解決方案。

但不得不說(shuō)的是，盡管Kubernetes建立在谷歌在生產(chǎn)環(huán)境運(yùn)行工作負(fù)載的超過(guò)15年的經(jīng)驗(yàn)之上，它非常復(fù)雜，一些設(shè)計(jì)決策總是讓用戶(hù)難以理解。即使對(duì)于經(jīng)驗(yàn)最豐富的工程師來(lái)說(shuō)，Kubernetes的學(xué)習(xí)曲線(xiàn)也很陡峭。

就以存儲(chǔ)來(lái)舉例。你知道PV和PVC的區(qū)別嗎?storage class和provisioner的關(guān)系是什么?VolumeClaimTemplates是什么?什么時(shí)候該用statefulset?

在本文中，我將嘗試解釋Kubernetes中的一些關(guān)鍵概念，以及我對(duì)它們的看法。我希望這也會(huì)幫助大家更多地了解Kubernetes。使用Kubernetes時(shí)，有許多設(shè)計(jì)選擇和警告讓我意想不到。今天我將講講PV、PVC、Storage Class和Provisioner。

[[250049]]

Docker中的Volume(卷)

在深入了解Kubernetes之前，讓我們先聊聊Docker——畢竟Kubernetes是構(gòu)建在Docker之上。

Docker因其簡(jiǎn)單易用聞名，這也是Docker能如此受歡迎，并成為Kubernetes基礎(chǔ)的原因。Docker容器是無(wú)狀態(tài)、快速的，它可以被破壞、重建，而不需要付出太多的代價(jià)。但是，就像是患了健忘癥的人，想要記住有意義的事情是很困難的一樣。無(wú)論是數(shù)據(jù)庫(kù)、鍵值存儲(chǔ)、還是一些原始數(shù)據(jù)，每一個(gè)都需要持久化存儲(chǔ)。

在Docker中創(chuàng)建持久化存儲(chǔ)非常簡(jiǎn)單。早期版本中，用戶(hù)可以使用-v來(lái)創(chuàng)建一個(gè)新的未定義大小的匿名空卷或者在主機(jī)上的目錄中創(chuàng)建綁定掛載。那個(gè)時(shí)候，雖然可以很容易地通過(guò)掛載那些已經(jīng)被存儲(chǔ)供應(yīng)商掛載在主機(jī)上的目錄，但沒(méi)有第三方接口幫助你直接掛載到Docker上。2015年8月，Docker發(fā)布了v1.8版本，正式引入了卷插件，允許第三方連接它們的存儲(chǔ)解決方案。Docker會(huì)調(diào)用已安裝的卷插件來(lái)創(chuàng)建/刪除/掛載/卸載/get/list那些相關(guān)卷，而且每個(gè)卷都有一個(gè)名字，直到今天，卷插件的框架基本仍保持不變。

持久卷和持久卷聲明

當(dāng)你想弄清楚如何在Kubernetes中創(chuàng)建持久存儲(chǔ)時(shí)，可能會(huì)遇到兩個(gè)概念：持久卷(Persistent Volume，PV)和持久卷聲明(Persistent Volume Claim，PVC)

它們是什么?它們中哪個(gè)更接近Docker中的卷?

實(shí)際上，它們都不像Docker中的卷。除了PV和PVC之外，Kubernetes還有一個(gè)Volume的概念，但它與Docker中的概念不同，稍后我們會(huì)討論它。

如果你了解一些關(guān)于PV和PVC信息，可能會(huì)意識(shí)到PV就是分配的存儲(chǔ)，而PVC是使用該存儲(chǔ)的請(qǐng)求。如果以前你有云計(jì)算或存儲(chǔ)的經(jīng)驗(yàn)，那么你可能會(huì)認(rèn)為PV就是一個(gè)存儲(chǔ)池，而PVC是一個(gè)從存儲(chǔ)池中分割出來(lái)的卷。

不過(guò)這都不是PV和PVC真正的意義，在Kubernetes中，一個(gè)PV映射到一個(gè)PVC，反之亦然，它是一對(duì)一的映射。

我已經(jīng)多次給具有豐富存儲(chǔ)和云計(jì)算經(jīng)驗(yàn)的人解釋過(guò)這些問(wèn)題，他們幾乎都是抓耳撓腮，不明白這是怎么回事。

而在我***次遇到這兩個(gè)概念的時(shí)候，我也沒(méi)法理解。

我們?cè)谶@里列出PV和PVC的定義

PersistentVolume(PV)是集群中由管理員配置的一塊存儲(chǔ)。它是集群中的資源，就和節(jié)點(diǎn)是集群資源一樣。PV是卷插件比如Volumes，但是它的生命周期獨(dú)立于使用PV的任何pod個(gè)體。該API對(duì)象捕獲實(shí)現(xiàn)存儲(chǔ)的詳細(xì)信息，包括NFS、iSCSI或著是云服務(wù)商特定的存儲(chǔ)系統(tǒng)。

PersistentVolumeClaim(PVC)是用戶(hù)關(guān)于存儲(chǔ)的請(qǐng)求。它類(lèi)似于一個(gè)pod，pod消耗節(jié)點(diǎn)資源，而PVC消耗PV資源。Pods可以請(qǐng)求特定級(jí)別的資源(CPU和內(nèi)容)，而Claim可以請(qǐng)求特定的大小和訪問(wèn)模式(例如，可以一次讀/寫(xiě)或者多次只讀)。

這里需要留意的是“管理員”以及“用戶(hù)”的區(qū)別。

簡(jiǎn)而言之，Kubernetes將基本存儲(chǔ)單元分為兩個(gè)概念。PV是一個(gè)存儲(chǔ)器，應(yīng)該由管理員預(yù)先分配，而PVC是用戶(hù)對(duì)存儲(chǔ)的請(qǐng)求。

也就是說(shuō)，Kubernetes希望管理員來(lái)實(shí)現(xiàn)分配各種大小的PV。當(dāng)用戶(hù)創(chuàng)建PVC來(lái)請(qǐng)求存儲(chǔ)時(shí)，Kubernetes將嘗試用該P(yáng)VC和預(yù)先分配的PV匹配。如果可以找到匹配項(xiàng)，就將PVC綁定到PV，用戶(hù)就可以開(kāi)始使用這片預(yù)分配的存儲(chǔ)區(qū)。

這種方式和傳統(tǒng)方法不同，傳統(tǒng)方法中管理員并不負(fù)責(zé)分配每個(gè)存儲(chǔ)空間。他們只需要授予用戶(hù)訪問(wèn)某個(gè)存儲(chǔ)池的權(quán)限，并且確定該用戶(hù)的配額是多少，然后讓用戶(hù)從存儲(chǔ)池中分割出所需的存儲(chǔ)部分即可。

不過(guò)在Kubernetes的設(shè)計(jì)中，PV已經(jīng)從存儲(chǔ)池中分割了出來(lái)，等待和PVC進(jìn)行匹配，因此用戶(hù)只能請(qǐng)求到預(yù)先分配的固定大小的存儲(chǔ)空間。這就出現(xiàn)了兩種情況：

1. 如果用戶(hù)只需要1GiB的卷，而可用的最小PV是1TiB，那么用戶(hù)就必須使用這個(gè)1TiB的卷。這樣之后其他用戶(hù)就沒(méi)法使用到這個(gè)卷，而這些用戶(hù)可能需求的容量超過(guò)了1GiB。這不僅會(huì)造成存儲(chǔ)空間的浪費(fèi)，還會(huì)導(dǎo)致由于資源限制無(wú)法啟動(dòng)某些工作負(fù)載的情況，而其他的工作負(fù)載可能正占有了不需要的資源。
2. 為了解決***個(gè)問(wèn)題，管理員要么需要不斷地和用戶(hù)保持通信，確定用戶(hù)需要的存儲(chǔ)大小/性能，要么就預(yù)測(cè)好需求，并相應(yīng)地預(yù)先分配PV。

這樣一來(lái)就很難強(qiáng)制執(zhí)行單獨(dú)的分配(PV)和使用(PVC)。在實(shí)際使用中，我并沒(méi)有看到大家講PV和PVC作為他們的設(shè)計(jì)方式。很可能管理員很快就放棄了創(chuàng)建PV的權(quán)限并把它委托給用戶(hù)執(zhí)行。由于PV和PVC仍然是一對(duì)一的綁定，PVC的存在就變得不那么必要了。

在我看來(lái)，至少可以說(shuō)，使用PV和PVC的示例是不常見(jiàn)的。

Storage Class和Provisioner

可能因?yàn)镻V和PVC使用起來(lái)太麻煩了，在2017年3月，隨著v1.6版本的發(fā)布，Kubernetes引入了動(dòng)態(tài)納管(dynamic provisioning)、Storage Class和Provisioner的概念。動(dòng)態(tài)納管與傳統(tǒng)存儲(chǔ)方法類(lèi)似。管理員可以使用Storage Class來(lái)描述他們提供的存儲(chǔ)“class”。Storage Class可以有不同的容量限制、不同的IOPS或其他Provisioner支持的參數(shù)。特定于存儲(chǔ)供應(yīng)商的Provisioner將與Storage Class一起使用，根據(jù)Storage Class對(duì)象中設(shè)置的參數(shù)自動(dòng)分配PV。此外，Provisioner現(xiàn)在能夠強(qiáng)制執(zhí)行用戶(hù)的報(bào)價(jià)(quotes)和權(quán)限要求。在這種設(shè)計(jì)中，管理員已經(jīng)從預(yù)測(cè)和分配PV的繁瑣中擺脫出來(lái)，這樣的方式更有意義。

另外，你還可以使用Storage Class而無(wú)需在Kubernetes中創(chuàng)建Storage Class對(duì)象。由于Storage Class也是用于PVC和PV(不必由Provisioner創(chuàng)建)的字段，因此你可以使用自定義的Storage Class名稱(chēng)手動(dòng)創(chuàng)建PV，然后創(chuàng)建一個(gè)請(qǐng)求相同Storage Class名稱(chēng)的PVC。即使存儲(chǔ)類(lèi)Storage Class對(duì)象不存在，Kubernetes也會(huì)將PVC綁定到具有相同存儲(chǔ)類(lèi)名稱(chēng)的PV上。

dynamic provisioning、Storage Class以及Provisioner對(duì)我來(lái)說(shuō)非常有意義，它解決了最初的PV和PVC設(shè)計(jì)中***的可用性問(wèn)題。但與此同時(shí)，這些新概念也加劇了Kubernetes存儲(chǔ)的另一個(gè)問(wèn)題，即處理持久存儲(chǔ)的各種方式造成的混亂。