以Kubernetes為代表的容器編排工具在應(yīng)用開發(fā)部署領(lǐng)域起正發(fā)揮著顛覆性的變革作用。隨著微服務(wù)架構(gòu)的發(fā)展，從開發(fā)人員的角度來看，應(yīng)用邏輯架構(gòu)與基礎(chǔ)設(shè)施架構(gòu)之間開始解耦，這意味著開發(fā)者能夠?qū)⒕Ω嗉性谲浖?gòu)建以及價(jià)值交付身上。
Kubernetes的作用，在于對(duì)其管理的物理服務(wù)器進(jìn)行抽象。在Kubernetes的幫助下，我們可以描述并使用所需要的內(nèi)存與計(jì)算容量的總和，而不再關(guān)注底層基礎(chǔ)設(shè)施架構(gòu)。
當(dāng)管理Docker鏡像的時(shí)候，Kubernetes也讓實(shí)際應(yīng)用變的十分便捷靈活。在利用Kubernetes進(jìn)行容器架構(gòu)的應(yīng)用部署時(shí)，管理員們將在無需修改底層代碼的前提下將其部署在任何位置——包括公有云、混合云乃至私有云。
雖然Kubernetes在擴(kuò)展性、便攜性與管理性等方面的表現(xiàn)都相當(dāng)給力，但截至目前，它仍然不支持存儲(chǔ)狀態(tài)。與之對(duì)應(yīng)的是，如今的大多數(shù)應(yīng)用都是有狀態(tài)的——換言之，要求在一定程度上配合外部存儲(chǔ)資源。
Kubernetes架構(gòu)本身非常靈的，能夠根據(jù)開發(fā)者的需求、規(guī)范以及實(shí)際負(fù)載情況，對(duì)容器進(jìn)行隨意創(chuàng)建與撤銷。此外，Pod和容器還具有自我修復(fù)與復(fù)制能力。因此從本質(zhì)上講，它們的生命周期普遍非常短暫。
但是，現(xiàn)有持久存儲(chǔ)解決方法無法支持動(dòng)態(tài)的應(yīng)用場(chǎng)景，而持久化存儲(chǔ)也無法滿足動(dòng)態(tài)創(chuàng)建與撤銷的需求。
當(dāng)我們需要將有狀態(tài)應(yīng)用部署到其它基礎(chǔ)架構(gòu)平臺(tái)，或者另一家內(nèi)部或混合云供應(yīng)商的環(huán)境中時(shí)，可移植性低下無疑將成為我們面臨的巨大挑戰(zhàn)。更具體地講，持久化存儲(chǔ)解決方案往往會(huì)鎖定于特定云服務(wù)供應(yīng)商，而無法靈活完成轉(zhuǎn)移。
另外，云原生應(yīng)用中的存儲(chǔ)機(jī)制也相當(dāng)復(fù)雜、難于理解。Kubernetes中的不少存儲(chǔ)術(shù)語極易混淆，其中包含著復(fù)雜的含義與微妙的變化。再有，在原生Kubernetes、開源框架以及托管與付費(fèi)服務(wù)之間還存在著諸多選項(xiàng)，這極大增加了開發(fā)人員在做出決定之前的考量與試驗(yàn)成本。
以下是CNCF列出的云原生存儲(chǔ)可選方案：
我們首先從最簡(jiǎn)單的場(chǎng)景出發(fā)，即在Kubernetes當(dāng)中部署一套數(shù)據(jù)庫。具體流程包括：選擇一套符合需求的數(shù)據(jù)庫，讓它在本地磁盤上運(yùn)行，然后將其作為新的工作負(fù)載部署到集群當(dāng)中。但是，由于數(shù)據(jù)庫中存在的一些固有屬性，這種方式往往無法帶來符合預(yù)期的效果。
容器本身是基于無狀態(tài)原則進(jìn)行構(gòu)建的，憑借這一天然屬性，我們才能如此輕松地啟動(dòng)或撤銷容器環(huán)境。由于不存在需要保存及遷移的數(shù)據(jù)，集群也就不需要同磁盤讀寫這類密集型操作綁定在一起了。
但對(duì)于數(shù)據(jù)庫，其狀態(tài)必須隨時(shí)保存。如果以容器方式部署在集群當(dāng)中的數(shù)據(jù)庫不需要進(jìn)行遷移，或者不需要頻繁開關(guān)，那么其基本屬性就相當(dāng)于一種物理存儲(chǔ)設(shè)備。在理想情況下，使用數(shù)據(jù)的容器應(yīng)該與該數(shù)據(jù)庫處于同一Pod當(dāng)中。
當(dāng)然，這并不是說將數(shù)據(jù)庫部署在容器中的作法不可取。在某些應(yīng)用場(chǎng)景下，這樣的設(shè)計(jì)完全能夠滿足需求。舉例來說，在測(cè)試環(huán)境或者處理非生產(chǎn)級(jí)數(shù)據(jù)時(shí)，由于總體數(shù)據(jù)量很小，將數(shù)據(jù)庫納入集群完全沒有問題。
但在實(shí)際生產(chǎn)中，開發(fā)人員往往需要仰仗于外部存儲(chǔ)機(jī)制。
Kubernetes到底是如何與存儲(chǔ)資源彼此通信的？其利用的是控制層接口。這些接口負(fù)責(zé)將Kubernetes與外部存儲(chǔ)相對(duì)接。接入Kubernetes的外部存儲(chǔ)解決方案被稱為“卷插件（Volume Plugins）”。正是有了卷插件的存在，存儲(chǔ)資源才得以抽象化并實(shí)現(xiàn)可移植性。
以前，卷插件一般由核心Kubernetes代碼庫進(jìn)行構(gòu)建、鏈接、編譯以及裝載。這樣就極大的限制了開發(fā)人員的發(fā)揮空間，同時(shí)也帶來了額外的維護(hù)開銷。因此，項(xiàng)目維護(hù)人員們決定在Kubernete的代碼庫上增加一些新的存儲(chǔ)功能。
隨著CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全無需更改代碼庫。
原生Kubernetes與存儲(chǔ)
原生Kubernetes如何處理存儲(chǔ)資源？它提供一系列管理存儲(chǔ)選項(xiàng)：除了臨時(shí)選項(xiàng)之外，還包括持持久卷（Persistent Volumes），持久卷聲明（Persistent Volume Claims），存儲(chǔ)類（Storage Classes）乃至StatefulSets等持久存儲(chǔ)形式。似乎有點(diǎn)亂，下面我們就對(duì)其進(jìn)行一一解釋。
持久卷是由管理員負(fù)責(zé)配置的存儲(chǔ)單元，它們獨(dú)立于任何單一Pod之外，因此不受Pod生命周期的影響。
另一方面，持久卷聲明是對(duì)存儲(chǔ)資源——也就是持久卷——的需求。有了持久卷聲明，我們就可以將存儲(chǔ)與特定的節(jié)點(diǎn)綁定在一起使用。
存儲(chǔ)資源有兩種使用方式：靜態(tài)存儲(chǔ)與動(dòng)態(tài)存儲(chǔ)。
使用靜態(tài)存儲(chǔ)時(shí)，管理員根據(jù)預(yù)估對(duì)持久卷進(jìn)行預(yù)配置，這些持久卷將被手動(dòng)綁定到具有明確持久卷聲明的特定Pod上。
實(shí)際上，靜態(tài)定義的持久卷并不能適應(yīng)Kubernetes的可移植特性，因?yàn)榇鎯?chǔ)資源具有對(duì)環(huán)境的依賴性——例如AWS EBS或者GCE Persistent Disk。另外，手動(dòng)綁定還需要根據(jù)不同供應(yīng)商的存儲(chǔ)方案修改YAML文件。
在資源分配方面，靜態(tài)配置實(shí)際上也違背了Kubernetes的設(shè)計(jì)原則。后者的CPU與內(nèi)存并非事先被分配好綁定在Pod或者容器上，而是以被動(dòng)態(tài)形式進(jìn)行分配。
動(dòng)態(tài)分配則依靠存儲(chǔ)類來實(shí)現(xiàn)。集群管理員不需要預(yù)先手動(dòng)創(chuàng)建持久卷，而是創(chuàng)建類似于模板的文件。當(dāng)開發(fā)人員制作持久卷聲明時(shí)，只需要根據(jù)實(shí)際需求創(chuàng)建一套模板并附加至Pod即可。
通過簡(jiǎn)單的說明，相信大家已經(jīng)了解了原生Kubernetes對(duì)外部存儲(chǔ)資源的使用方式。當(dāng)然，這里僅僅做出概括，實(shí)際使用場(chǎng)景中還有更多其它因素需要考量。
CSI——容器存儲(chǔ)接口
下面來看容器存儲(chǔ)接口（簡(jiǎn)稱CSI）。CSI是由CNCF存儲(chǔ)工作組創(chuàng)建的統(tǒng)一標(biāo)準(zhǔn)，旨在定義一個(gè)標(biāo)準(zhǔn)的容器存儲(chǔ)接口，從而使存儲(chǔ)驅(qū)動(dòng)程序能夠在任意容器架構(gòu)下正常起效。
CSI規(guī)范目前已經(jīng)在Kubernetes中得到普及，大量驅(qū)動(dòng)插件被預(yù)先部署在Kubernetes集群內(nèi)供開發(fā)人員使用。如此一來，我們就可以利用Kubernetes上的CSI卷來訪問與CSI兼容的開放存儲(chǔ)卷。
CSI的引入，意味著存儲(chǔ)資源能夠作為Kubernetes集群上的另一種工作負(fù)載實(shí)現(xiàn)容器化以及部署。
相關(guān)開源項(xiàng)目
目前，圍繞云原生技術(shù)涌現(xiàn)出大量工具與項(xiàng)目。但作為生產(chǎn)場(chǎng)景中的一大突出問題，我們往往很難在云原生架構(gòu)中選擇最合適的開源項(xiàng)目。換言之，解決方案選項(xiàng)太多，反而令存儲(chǔ)需求變得更難解決。
從人氣角度來看，目前最流行的存儲(chǔ)項(xiàng)目當(dāng)數(shù)Ceph與Rook。
Ceph是一種動(dòng)態(tài)托管、橫向擴(kuò)展的分布式存儲(chǔ)集群。Ceph面向存儲(chǔ)資源提供一種邏輯抽象機(jī)制，其設(shè)計(jì)理念包括無單點(diǎn)故障、自管理以及軟件定義等特性。Ceph可以面向同一套存儲(chǔ)集群分別提供塊存儲(chǔ)、對(duì)象存儲(chǔ)以及文件存儲(chǔ)的對(duì)應(yīng)接口。
Ceph架構(gòu)相當(dāng)復(fù)雜的，其中使用到大量的底層技術(shù)，例如RADOS、librados、RADOSGW、RDB、CRUSH算法，外加monitor、OSD以及MDS等功能性組件。這里我們先不談它的底層架構(gòu)，關(guān)鍵在于Ceph屬于一種分布式存儲(chǔ)集群，這使得擴(kuò)展更便利、能夠在不犧牲性能的前提下消除單點(diǎn)故障，且提供涵蓋對(duì)象存儲(chǔ)、塊存儲(chǔ)以及文件存儲(chǔ)的統(tǒng)一存儲(chǔ)體系。
很明顯，Ceph與云原生環(huán)境彼此兼容的，我們也可以利用多種方法部署一套Ceph集群，譬如使用Ansible。我們可以部署一套Ceph集群，并使用CSI與持久卷聲明來提供指向Kubernetes集群的接口。
Ceph架構(gòu)圖
另一個(gè)有趣且頗具人氣的項(xiàng)目是Rook，這是一項(xiàng)旨在將Kubernetes與Ceph融合起來的技術(shù)方案。從本質(zhì)上講，它將計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)放進(jìn)了同一個(gè)集群當(dāng)中。
Rook是一種云原生編排器，并對(duì)Kubernetes做出擴(kuò)展。Rook允許用戶將Ceph放置在容器內(nèi)，同時(shí)提供卷管理邏輯以立足Kubernetes之上實(shí)現(xiàn)Ceph的可靠運(yùn)行。Rook還使本應(yīng)由集群管理員操作的多種任務(wù)完成了自動(dòng)化實(shí)現(xiàn)，其中包括部署、引導(dǎo)、配置、擴(kuò)展以及負(fù)載均衡等等。
Rook可以像Kubernetes一樣使用yaml文件來部署Ceph集群。這種文件以高級(jí)聲明的形式存在，負(fù)責(zé)為集群管理員提供所需要的全部?jī)?nèi)容。
Rook在集群?jiǎn)?dòng)完成后，即開始進(jìn)行實(shí)時(shí)監(jiān)控。Rook將以操作端或者控制端的姿態(tài)確保yaml文件中所聲明的狀態(tài)始終正常。Rook運(yùn)行在一套協(xié)調(diào)的邏輯循環(huán)中，該循環(huán)將觀察運(yùn)行狀態(tài)并根據(jù)檢測(cè)到的異常采取響應(yīng)。
Rook自身不具備持久狀態(tài)，也不需要單獨(dú)管理。這，才是真正與Kubernetes設(shè)計(jì)原則相符的存儲(chǔ)資源管理方案。
Rook憑借著將Ceph與Kubernetes協(xié)同起來的強(qiáng)大能力，成為目前最受歡迎的云原生存儲(chǔ)解決方案。Rook項(xiàng)目已經(jīng)在GitHub上獲得近4000顆星，1600多萬次的下載，并吸引到100多名貢獻(xiàn)者。
作為CNCF認(rèn)可的第一個(gè)存儲(chǔ)項(xiàng)目，Rook現(xiàn)在已經(jīng)進(jìn)入孵化階段。
對(duì)于實(shí)際應(yīng)用層面出現(xiàn)的任何問題，最重要的自然是判斷需求、設(shè)計(jì)系統(tǒng)或者選擇適當(dāng)?shù)墓ぞ摺Ｍ瑯拥牡览硪策m用于云原生環(huán)境。雖然具體問題非常復(fù)雜，但也必然會(huì)出現(xiàn)大量工具方案嘗試解決。隨著云原生世界的持續(xù)發(fā)展，我們可以肯定，新的解決方案將不斷涌現(xiàn)。未來，一切都會(huì)更加美好！
