国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

深入淺出聊聊Kubernetes存儲(二):搞定持久化存儲

韓冰 / 1984人閱讀

摘要:這與不同,因為將繼續存在于系統中,直到用戶刪除它。和持久卷聲明之間很容易弄混淆。該在直接和使用前必須已經存在。這對于需要持久化儲存但只有本地卷可用的工作負載,這非常有用。此外,由于缺少,會失去使用自動伸縮的能力。


回 顧

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

簡單回顧一下:

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

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

PV和PVC總是一一對應的。

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

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

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

Volume

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

這里我們引用Volume的定義:

Kubernetes Volume…有一個顯式的生命周期——這和包含它的pod的生命周期相同。因此,Volume的生命周期比在pod中運行的任何容器都長,并且在容器重啟的時候會保存數據。當然,當Pod終止時,Volume也將終止。更重要的是,Kubernetes支持多種類型的Volume,一個pod中也可以同時使用任何數量的Volume。
在其核心部分,Volume只是一個目錄,可能其中包含了一些數據,這些數據可由pod中的容器訪問。這些目錄是如何產生的、支持它的介質、以及它的內容都是由所使用的特定volume的類型決定的。在其核心部分,Volume只是一個目錄,可能其中包含了一些數據,這些數據可由pod中的容器訪問。這些目錄是如何產生的、支持它的介質、以及它的內容都是由所使用的特定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、Persistent Volume和Provisioner之間做出選擇

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

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

但是我并沒有找到。

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

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

https://github.com/kubernetes...

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

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。)

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

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

在Volume、Persistent Volume和Provisioner之間選擇的準則

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

在我看來,用戶們應該堅持一個原則:

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

詳細來說:

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

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

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

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

https://github.com/rancher/lo...。

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

這個準則背后的原理很簡單。在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的粉絲,而且這不是存儲子系統的問題。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32760.html

相關文章

  • 深入淺出聊聊Kubernetes存儲(一):詳解Kubernetes存儲關鍵概念

    摘要:功能強大擴展性高,在許多人看來,它正在成為云計算的終極解決方案。我已經多次給具有豐富存儲和云計算經驗的人解釋過這些問題,他們幾乎都是抓耳撓腮,不明白這是怎么回事。和可能因為和使用起來太麻煩了,在年月,隨著版本的發布,引入了動態納管和的概念。 Kubernetes存儲全解!你知道PV和PVC的區別嗎?storage class和provisioner是什么關系?VolumeClaimTe...

    loonggg 評論0 收藏0
  • 聊聊調度框架,K8S、Mesos、Swarm 一個都不能少

    摘要:在這三種調度框架做出選擇需要進行驗證根據應用的工作方式,數量以及如何管理數據等基礎,可以幫助縮小選擇范圍。容器安裝和運行時對存儲服務進行特定的請求,以實現如創建刪除檢查列表連接分離掛載卸載等功能。和一樣,它也有相同的功能和限制。 Swarm、Mesos、和Kubernetes都為各種規模的企業提供了全面的支持,如何選擇是好? API ▼ 目前找到符合企業自身需求的調度框架比較困難,Do...

    fasss 評論0 收藏0
  • 貓頭鷹的深夜翻譯:久化容器存儲

    摘要:如果我們的容器使用,文件如下在這個例子中,我們可以重復創建和銷毀,同一個持久存儲會被提供給新的,無論容器位于哪個節點上。 前言 臨時性存儲是容器的一個很大的買點。根據一個鏡像啟動容器,隨意變更,然后停止變更重啟一個容器。你看,一個全新的文件系統又誕生了。 在docker的語境下: # docker run -it centos [root@d42876f95c6a /]# echo H...

    tianhang 評論0 收藏0
  • 貓頭鷹的深夜翻譯:久化容器存儲

    摘要:如果我們的容器使用,文件如下在這個例子中,我們可以重復創建和銷毀,同一個持久存儲會被提供給新的,無論容器位于哪個節點上。 前言 臨時性存儲是容器的一個很大的買點。根據一個鏡像啟動容器,隨意變更,然后停止變更重啟一個容器。你看,一個全新的文件系統又誕生了。 在docker的語境下: # docker run -it centos [root@d42876f95c6a /]# echo H...

    xiao7cn 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<