戳藍(lán)字“CSDN云計算”關(guān)注我們哦！

譯者：韋峻峰

轉(zhuǎn)自：RancherLabs

以Kubernetes為代表的容器編排工具在應(yīng)用開發(fā)部署領(lǐng)域起正發(fā)揮著顛覆性的變革作用。隨著微服務(wù)架構(gòu)的發(fā)展，從開發(fā)人員的角度來看，應(yīng)用邏輯架構(gòu)與基礎(chǔ)設(shè)施架構(gòu)之間開始解耦，這意味著開發(fā)者能夠?qū)⒕Ω嗉性谲浖?gòu)建以及價值交付身上。

Kubernetes的作用，在于對其管理的物理服務(wù)器進(jìn)行抽象。在Kubernetes的幫助下，我們可以描述并使用所需要的內(nèi)存與計算容量的總和，而不再關(guān)注底層基礎(chǔ)設(shè)施架構(gòu)。

當(dāng)管理Docker鏡像的時候，Kubernetes也讓實際應(yīng)用變的十分便捷靈活。在利用Kubernetes進(jìn)行容器架構(gòu)的應(yīng)用部署時，管理員們將在無需修改底層代碼的前提下將其部署在任何位置——包括公有云、混合云乃至私有云。

雖然Kubernetes在擴(kuò)展性、便攜性與管理性等方面的表現(xiàn)都相當(dāng)給力，但截至目前，它仍然不支持存儲狀態(tài)。與之對應(yīng)的是，如今的大多數(shù)應(yīng)用都是有狀態(tài)的——換言之，要求在一定程度上配合外部存儲資源。

Kubernetes架構(gòu)本身非常靈活的，能夠根據(jù)開發(fā)者的需求、規(guī)范以及實際負(fù)載情況，對容器進(jìn)行隨意創(chuàng)建與撤銷。此外，Pod和容器還具有自我修復(fù)與復(fù)制能力。因此從本質(zhì)上講，它們的生命周期普遍非常短暫。

但是，現(xiàn)有持久存儲解決方法無法支持動態(tài)的應(yīng)用場景，而持久化存儲也無法滿足動態(tài)創(chuàng)建與撤銷的需求。

當(dāng)我們需要將有狀態(tài)應(yīng)用部署到其它基礎(chǔ)架構(gòu)平臺，或者另一家內(nèi)部或混合云供應(yīng)商的環(huán)境中時，可移植性低下無疑將成為我們面臨的巨大挑戰(zhàn)。更具體地講，持久化存儲解決方案往往會鎖定于特定云服務(wù)供應(yīng)商，而無法靈活完成轉(zhuǎn)移。

另外，云原生應(yīng)用中的存儲機(jī)制也相當(dāng)復(fù)雜、難于理解。Kubernetes中的不少存儲術(shù)語極易混淆，其中包含著復(fù)雜的含義與微妙的變化。再有，在原生Kubernetes、開源框架以及托管與付費服務(wù)之間還存在著諸多選項，這極大增加了開發(fā)人員在做出決定之前的考量與試驗成本。

以下是CNCF列出的云原生存儲可選方案：

我們首先從最簡單的場景出發(fā)，即在Kubernetes當(dāng)中部署一套數(shù)據(jù)庫。具體流程包括：選擇一套符合需求的數(shù)據(jù)庫，讓它在本地磁盤上運行，然后將其作為新的工作負(fù)載部署到集群當(dāng)中。但是，由于數(shù)據(jù)庫中存在的一些固有屬性，這種方式往往無法帶來符合預(yù)期的效果。

容器本身是基于無狀態(tài)原則進(jìn)行構(gòu)建的，憑借這一天然屬性，我們才能如此輕松地啟動或撤銷容器環(huán)境。由于不存在需要保存及遷移的數(shù)據(jù)，集群也就不需要同磁盤讀寫這類密集型操作綁定在一起了。

但對于數(shù)據(jù)庫，其狀態(tài)必須隨時保存。如果以容器方式部署在集群當(dāng)中的數(shù)據(jù)庫不需要進(jìn)行遷移，或者不需要頻繁開關(guān)，那么其基本屬性就相當(dāng)于一種物理存儲設(shè)備。在理想情況下，使用數(shù)據(jù)的容器應(yīng)該與該數(shù)據(jù)庫處于同一Pod當(dāng)中。

當(dāng)然，這并不是說將數(shù)據(jù)庫部署在容器中的作法不可取。在某些應(yīng)用場景下，這樣的設(shè)計完全能夠滿足需求。舉例來說，在測試環(huán)境或者處理非生產(chǎn)級數(shù)據(jù)時，由于總體數(shù)據(jù)量很小，將數(shù)據(jù)庫納入集群完全沒有問題。但在實際生產(chǎn)中，開發(fā)人員往往需要仰仗于外部存儲機(jī)制。

Kubernetes到底是如何與存儲資源彼此通信的？其利用的是控制層接口。這些接口負(fù)責(zé)將Kubernetes與外部存儲相對接。接入Kubernetes的外部存儲解決方案被稱為“卷插件（Volume Plugins）”。正是有了卷插件的存在，存儲資源才得以抽象化并實現(xiàn)可移植性。

以前，卷插件一般由核心Kubernetes代碼庫進(jìn)行構(gòu)建、鏈接、編譯以及裝載。這樣就極大的限制了開發(fā)人員的發(fā)揮空間，同時也帶來了額外的維護(hù)開銷。因此，項目維護(hù)人員們決定在Kubernete的代碼庫上增加一些新的存儲功能。

隨著CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全無需更改代碼庫。

原生Kubernetes與存儲

原生Kubernetes如何處理存儲資源？它提供一系列管理存儲選項：除了臨時選項之外，還包括持持久卷（Persistent Volumes），持久卷聲明（Persistent Volume Claims），存儲類（Storage Classes）乃至StatefulSets等持久存儲形式。似乎有點亂，下面我們就對其進(jìn)行一一解釋。

持久卷是由管理員負(fù)責(zé)配置的存儲單元，它們獨立于任何單一Pod之外，因此不受Pod生命周期的影響。

另一方面，持久卷聲明是對存儲資源——也就是持久卷——的需求。有了持久卷聲明，我們就可以將存儲與特定的節(jié)點綁定在一起使用。

存儲資源有兩種使用方式：靜態(tài)存儲與動態(tài)存儲。

使用靜態(tài)存儲時，管理員根據(jù)預(yù)估對持久卷進(jìn)行預(yù)配置，這些持久卷將被手動綁定到具有明確持久卷聲明的特定Pod上。

實際上，靜態(tài)定義的持久卷并不能適應(yīng)Kubernetes的可移植特性，因為存儲資源具有對環(huán)境的依賴性——例如AWS EBS或者GCE Persistent Disk。另外，手動綁定還需要根據(jù)不同供應(yīng)商的存儲方案修改YAML文件。

在資源分配方面，靜態(tài)配置實際上也違背了Kubernetes的設(shè)計原則。后者的CPU與內(nèi)存并非事先被分配好綁定在Pod或者容器上，而是以被動態(tài)形式進(jìn)行分配。

動態(tài)分配則依靠存儲類來實現(xiàn)。集群管理員不需要預(yù)先手動創(chuàng)建持久卷，而是創(chuàng)建類似于模板的文件。當(dāng)開發(fā)人員制作持久卷聲明時，只需要根據(jù)實際需求創(chuàng)建一套模板并附加至Pod即可。

通過簡單的說明，相信大家已經(jīng)了解了原生Kubernetes對外部存儲資源的使用方式。當(dāng)然，這里僅僅做出概括，實際使用場景中還有更多其它因素需要考量。

CSI——容器存儲接口

下面來看容器存儲接口（簡稱CSI）。CSI是由CNCF存儲工作組創(chuàng)建的統(tǒng)一標(biāo)準(zhǔn)，旨在定義一個標(biāo)準(zhǔn)的容器存儲接口，從而使存儲驅(qū)動程序能夠在任意容器架構(gòu)下正常起效。

CSI規(guī)范目前已經(jīng)在Kubernetes中得到普及，大量驅(qū)動插件被預(yù)先部署在Kubernetes集群內(nèi)供開發(fā)人員使用。如此一來，我們就可以利用Kubernetes上的CSI卷來訪問與CSI兼容的開放存儲卷。

CSI的引入，意味著存儲資源能夠作為Kubernetes集群上的另一種工作負(fù)載實現(xiàn)容器化以及部署。

相關(guān)開源項目

目前，圍繞云原生技術(shù)涌現(xiàn)出大量工具與項目。但作為生產(chǎn)場景中的一大突出問題，我們往往很難在云原生架構(gòu)中選擇最合適的開源項目。換言之，解決方案選項太多，反而令存儲需求變得更難解決。

?

我們再看一次CNCF列出的云原生存儲的可選方案：

下面我會分享一下當(dāng)下流行的存儲方案Ceph與Rook，還有Rancher開源的容器化分布式存儲Longhorn。

Ceph

Ceph是一種動態(tài)托管、橫向擴(kuò)展的分布式存儲集群。Ceph面向存儲資源提供一種邏輯抽象機(jī)制，其設(shè)計理念包括無單點故障、自管理以及軟件定義等特性。Ceph可以面向同一套存儲集群分別提供塊存儲、對象存儲以及文件存儲的對應(yīng)接口。

Ceph架構(gòu)相當(dāng)復(fù)雜的，其中使用到大量的底層技術(shù)，例如RADOS、librados、RADOSGW、RDB、CRUSH算法，外加monitor、OSD以及MDS等功能性組件。這里我們先不談它的底層架構(gòu)，關(guān)鍵在于Ceph屬于一種分布式存儲集群，這使得擴(kuò)展更便利、能夠在不犧牲性能的前提下消除單點故障，且提供涵蓋對象存儲、塊存儲以及文件存儲的統(tǒng)一存儲體系。

很明顯，Ceph與云原生環(huán)境彼此兼容的，我們也可以利用多種方法部署一套Ceph集群，譬如使用Ansible。我們可以部署一套Ceph集群，并使用CSI與持久卷聲明來提供指向Kubernetes集群的接口。

?

Ceph架構(gòu)圖

Rook

另一個有趣且頗具人氣的項目是Rook，這是一項旨在將Kubernetes與Ceph融合起來的技術(shù)方案。從本質(zhì)上講，它將計算節(jié)點和存儲節(jié)點放進(jìn)了同一個集群當(dāng)中。

Rook是一種云原生編排器，并對Kubernetes做出擴(kuò)展。Rook允許用戶將Ceph放置在容器內(nèi)，同時提供卷管理邏輯以立足Kubernetes之上實現(xiàn)Ceph的可靠運行。Rook還使本應(yīng)由集群管理員操作的多種任務(wù)完成了自動化實現(xiàn)，其中包括部署、引導(dǎo)、配置、擴(kuò)展以及負(fù)載均衡等等。

Rook可以像Kubernetes一樣使用yaml文件來部署Ceph集群。這種文件以高級聲明的形式存在，負(fù)責(zé)為集群管理員提供所需要的全部內(nèi)容。

Rook在集群啟動完成后，即開始進(jìn)行實時監(jiān)控。Rook將以操作端或者控制端的姿態(tài)確保yaml文件中所聲明的狀態(tài)始終正常。Rook運行在一套協(xié)調(diào)的邏輯循環(huán)中，該循環(huán)將觀察運行狀態(tài)并根據(jù)檢測到的異常采取響應(yīng)。

Rook自身不具備持久狀態(tài)，也不需要單獨管理。這，才是真正與Kubernetes設(shè)計原則相符的存儲資源管理方案。

Rook憑借著將Ceph與Kubernetes協(xié)同起來的強(qiáng)大能力而頗受歡迎，在GitHub上獲得近4000顆星，1600多萬次的下載，并吸引到100多名貢獻(xiàn)者，現(xiàn)已進(jìn)入CNCF孵化階段。

Longhorn

Longhorn項目是Rancher Labs推出的開源的基于云和容器部署的分布式塊存儲新方式。Longhorn遵循微服務(wù)的原則，利用容器將小型獨立組件構(gòu)建為分布式塊存儲，并使用容器編排來協(xié)調(diào)這些組件，形成彈性分布式系統(tǒng)。

?

如今，基于云和容器的部署規(guī)模日益擴(kuò)大，分布式塊存儲系統(tǒng)也正變得越來越復(fù)雜，單個存儲控制器上的volume數(shù)量在不斷增加。2000年代初，存儲控制器上的volume數(shù)量只有幾十個，但現(xiàn)代云環(huán)境卻需要數(shù)萬到數(shù)百萬的分布式塊存儲卷。存儲控制器變成了高度復(fù)雜的分布式系統(tǒng)。

?

Longhorn充分利用了近年來關(guān)于如何編排大量的容器和虛擬機(jī)的核心技術(shù)。例如，Longhorn并沒有構(gòu)建一個可以擴(kuò)展到100,000個volume的高度復(fù)雜的控制器，而是出于讓存儲控制器簡單輕便的考慮，創(chuàng)建了100,000個單獨的控制器。然后，我們可以利用像Kubernetes這樣的最先進(jìn)的編排系統(tǒng)來調(diào)度這些獨立的控制器，共享一組磁盤中的資源，協(xié)同工作，形成一個彈性的分布式塊存儲系統(tǒng)。

?

Longhorn基于微服務(wù)的設(shè)計還有很多其他優(yōu)勢。因為每個volume都有自己的控制器，在升級每個volume的控制器和replica容器時，是不會導(dǎo)致IO操作明顯的中斷的。Longhorn可以創(chuàng)建一個長期運行的工作來編排所有l(wèi)ive volume的升級，同時確保不會中斷系統(tǒng)正在進(jìn)行的操作。為確保升級不會導(dǎo)致意外的問題，Longhorn可以選擇升級一小部分volume，并在升級過程中出現(xiàn)問題時回滾到舊版本。這些做法在現(xiàn)代微服務(wù)應(yīng)用中已得到廣泛應(yīng)用，但在存儲系統(tǒng)中并不常見。希望Longhorn可以助力于微服務(wù)在存儲領(lǐng)域的更多應(yīng)用。

結(jié) 語

對于實際應(yīng)用層面出現(xiàn)的任何問題，最重要的自然是判斷需求、設(shè)計系統(tǒng)或者選擇適當(dāng)?shù)墓ぞ摺Ｍ瑯拥牡览硪策m用于云原生環(huán)境。雖然具體問題非常復(fù)雜，但也必然會出現(xiàn)大量工具方案嘗試解決。隨著云原生世界的持續(xù)發(fā)展，我們可以肯定，新的解決方案將不斷涌現(xiàn)。未來，一切都會更加美好！

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！

推薦閱讀：

• 如何用30分鐘快速優(yōu)化家中Wi-Fi？阿里工程師有絕招

• 趣挨踢 | “菜鳥”程序員和“大神”程序員的差別竟然這么大...

• 女生適合做程序員嗎？

• Kubernetes 調(diào)度器實現(xiàn)初探
  

• 李沐團(tuán)隊新作Gluon，復(fù)現(xiàn)CV經(jīng)典模型到BERT，簡單好用 | 強(qiáng)烈推薦

• 日本樂天要求員工學(xué)編程，AI 進(jìn)中小學(xué)課堂，全民編程時代來了！

• 做了四年以太坊核心開發(fā)者, 以太坊升級了, 我也該離開了……

喜歡就點擊“在看”吧

總結(jié)

以上是生活随笔為你收集整理的深挖Kubernetes存储为何如此难及其解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。