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

成都創(chuàng)新互聯(lián)成都企業(yè)網(wǎng)站建設服務，提供成都做網(wǎng)站、成都網(wǎng)站設計網(wǎng)站開發(fā),網(wǎng)站定制,建網(wǎng)站,網(wǎng)站搭建,網(wǎng)站設計,響應式網(wǎng)站設計,網(wǎng)頁設計師打造企業(yè)風格網(wǎng)站,提供周到的售前咨詢和貼心的售后服務。歡迎咨詢做網(wǎng)站需要多少錢:13518219792

但不得不說的是，盡管Kubernetes建立在谷歌在生產環(huán)境運行工作負載的超過15年的經(jīng)驗之上，它非常復雜，一些設計決策總是讓用戶難以理解。即使對于經(jīng)驗最豐富的工程師來說，Kubernetes的學習曲線也很陡峭。

就以存儲來舉例。你知道PV和PVC的區(qū)別嗎？storage class和provisioner的關系是什么？VolumeClaimTemplates是什么？什么時候該用statefulset？

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

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

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

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

當你想弄清楚如何在Kubernetes中創(chuàng)建持久存儲時，可能會遇到兩個概念：持久卷（Persistent Volume，PV）和持久卷聲明（Persistent Volume Claim，PVC） 

它們是什么？它們中哪個更接近Docker中的卷？ 

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

如果你了解一些關于PV和PVC信息，可能會意識到PV就是分配的存儲，而PVC是使用該存儲的請求。如果以前你有云計算或存儲的經(jīng)驗，那么你可能會認為PV就是一個存儲池，而PVC是一個從存儲池中分割出來的卷。

不過這都不是PV和PVC真正的意義，在Kubernetes中，一個PV映射到一個PVC，反之亦然，它是一對一的映射。

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

而在我第一次遇到這兩個概念的時候，我也沒法理解。

我們在這里列出PV和PVC的定義

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

簡而言之，Kubernetes將基本存儲單元分為兩個概念。PV是一個存儲器，應該由管理員預先分配，而PVC是用戶對存儲的請求。

也就是說，Kubernetes希望管理員來實現(xiàn)分配各種大小的PV。當用戶創(chuàng)建PVC來請求存儲時，Kubernetes將嘗試用該PVC和預先分配的PV匹配。如果可以找到匹配項，就將PVC綁定到PV，用戶就可以開始使用這片預分配的存儲區(qū)。

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

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

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

在我看來，至少可以說，使用PV和PVC的示例是不常見的。

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

另外，你還可以使用Storage Class而無需在Kubernetes中創(chuàng)建Storage Class對象。由于Storage Class也是用于PVC和PV（不必由Provisioner創(chuàng)建）的字段，因此你可以使用自定義的Storage Class名稱手動創(chuàng)建PV，然后創(chuàng)建一個請求相同Storage Class名稱的PVC。即使存儲類Storage Class對象不存在，Kubernetes也會將PVC綁定到具有相同存儲類名稱的PV上。

dynamic provisioning、Storage Class以及Provisioner對我來說非常有意義，它解決了最初的PV和PVC設計中最大的可用性問題。但與此同時，這些新概念也加劇了Kubernetes存儲的另一個問題，即處理持久存儲的各種方式造成的混亂。在本系列文章的下一篇中，我們將分享Kubernetes中的卷與持久化存儲的相關內容，敬請關注！