深挖Kubernetes存储为何如此难及其解决方案
戳藍字“CSDN云計算”關注我們哦！
譯者：韋峻峰
轉自：RancherLabs
以Kubernetes為代表的容器編排工具在應用開發部署領域起正發揮著顛覆性的變革作用。隨著微服務架構的發展，從開發人員的角度來看，應用邏輯架構與基礎設施架構之間開始解耦，這意味著開發者能夠將精力更多集中在軟件構建以及價值交付身上。
Kubernetes的作用，在于對其管理的物理服務器進行抽象。在Kubernetes的幫助下，我們可以描述并使用所需要的內存與計算容量的總和，而不再關注底層基礎設施架構。
當管理Docker鏡像的時候，Kubernetes也讓實際應用變的十分便捷靈活。在利用Kubernetes進行容器架構的應用部署時，管理員們將在無需修改底層代碼的前提下將其部署在任何位置——包括公有云、混合云乃至私有云。
雖然Kubernetes在擴展性、便攜性與管理性等方面的表現都相當給力，但截至目前，它仍然不支持存儲狀態。與之對應的是，如今的大多數應用都是有狀態的——換言之，要求在一定程度上配合外部存儲資源。
Kubernetes架構本身非常靈活的，能夠根據開發者的需求、規范以及實際負載情況，對容器進行隨意創建與撤銷。此外，Pod和容器還具有自我修復與復制能力。因此從本質上講，它們的生命周期普遍非常短暫。
但是，現有持久存儲解決方法無法支持動態的應用場景，而持久化存儲也無法滿足動態創建與撤銷的需求。
當我們需要將有狀態應用部署到其它基礎架構平臺，或者另一家內部或混合云供應商的環境中時，可移植性低下無疑將成為我們面臨的巨大挑戰。更具體地講，持久化存儲解決方案往往會鎖定于特定云服務供應商，而無法靈活完成轉移。
另外，云原生應用中的存儲機制也相當復雜、難于理解。Kubernetes中的不少存儲術語極易混淆，其中包含著復雜的含義與微妙的變化。再有，在原生Kubernetes、開源框架以及托管與付費服務之間還存在著諸多選項，這極大增加了開發人員在做出決定之前的考量與試驗成本。
以下是CNCF列出的云原生存儲可選方案：
我們首先從最簡單的場景出發，即在Kubernetes當中部署一套數據庫。具體流程包括：選擇一套符合需求的數據庫，讓它在本地磁盤上運行，然后將其作為新的工作負載部署到集群當中。但是，由于數據庫中存在的一些固有屬性，這種方式往往無法帶來符合預期的效果。
容器本身是基于無狀態原則進行構建的，憑借這一天然屬性，我們才能如此輕松地啟動或撤銷容器環境。由于不存在需要保存及遷移的數據，集群也就不需要同磁盤讀寫這類密集型操作綁定在一起了。
但對于數據庫，其狀態必須隨時保存。如果以容器方式部署在集群當中的數據庫不需要進行遷移，或者不需要頻繁開關，那么其基本屬性就相當于一種物理存儲設備。在理想情況下，使用數據的容器應該與該數據庫處于同一Pod當中。
當然，這并不是說將數據庫部署在容器中的作法不可取。在某些應用場景下，這樣的設計完全能夠滿足需求。舉例來說，在測試環境或者處理非生產級數據時，由于總體數據量很小，將數據庫納入集群完全沒有問題。但在實際生產中，開發人員往往需要仰仗于外部存儲機制。
Kubernetes到底是如何與存儲資源彼此通信的？其利用的是控制層接口。這些接口負責將Kubernetes與外部存儲相對接。接入Kubernetes的外部存儲解決方案被稱為“卷插件（Volume Plugins）”。正是有了卷插件的存在，存儲資源才得以抽象化并實現可移植性。
以前，卷插件一般由核心Kubernetes代碼庫進行構建、鏈接、編譯以及裝載。這樣就極大的限制了開發人員的發揮空間，同時也帶來了額外的維護開銷。因此，項目維護人員們決定在Kubernete的代碼庫上增加一些新的存儲功能。
隨著CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全無需更改代碼庫。
原生Kubernetes與存儲
原生Kubernetes如何處理存儲資源？它提供一系列管理存儲選項：除了臨時選項之外，還包括持持久卷（Persistent Volumes），持久卷聲明（Persistent Volume Claims），存儲類（Storage Classes）乃至StatefulSets等持久存儲形式。似乎有點亂，下面我們就對其進行一一解釋。
持久卷是由管理員負責配置的存儲單元，它們獨立于任何單一Pod之外，因此不受Pod生命周期的影響。
另一方面，持久卷聲明是對存儲資源——也就是持久卷——的需求。有了持久卷聲明，我們就可以將存儲與特定的節點綁定在一起使用。
存儲資源有兩種使用方式：靜態存儲與動態存儲。
使用靜態存儲時，管理員根據預估對持久卷進行預配置，這些持久卷將被手動綁定到具有明確持久卷聲明的特定Pod上。
實際上，靜態定義的持久卷并不能適應Kubernetes的可移植特性，因為存儲資源具有對環境的依賴性——例如AWS EBS或者GCE Persistent Disk。另外，手動綁定還需要根據不同供應商的存儲方案修改YAML文件。
在資源分配方面，靜態配置實際上也違背了Kubernetes的設計原則。后者的CPU與內存并非事先被分配好綁定在Pod或者容器上，而是以被動態形式進行分配。
動態分配則依靠存儲類來實現。集群管理員不需要預先手動創建持久卷，而是創建類似于模板的文件。當開發人員制作持久卷聲明時，只需要根據實際需求創建一套模板并附加至Pod即可。
通過簡單的說明，相信大家已經了解了原生Kubernetes對外部存儲資源的使用方式。當然，這里僅僅做出概括，實際使用場景中還有更多其它因素需要考量。
CSI——容器存儲接口
下面來看容器存儲接口（簡稱CSI）。CSI是由CNCF存儲工作組創建的統一標準，旨在定義一個標準的容器存儲接口，從而使存儲驅動程序能夠在任意容器架構下正常起效。
CSI規范目前已經在Kubernetes中得到普及，大量驅動插件被預先部署在Kubernetes集群內供開發人員使用。如此一來，我們就可以利用Kubernetes上的CSI卷來訪問與CSI兼容的開放存儲卷。
CSI的引入，意味著存儲資源能夠作為Kubernetes集群上的另一種工作負載實現容器化以及部署。
相關開源項目
目前，圍繞云原生技術涌現出大量工具與項目。但作為生產場景中的一大突出問題，我們往往很難在云原生架構中選擇最合適的開源項目。換言之，解決方案選項太多，反而令存儲需求變得更難解決。
?
我們再看一次CNCF列出的云原生存儲的可選方案：
下面我會分享一下當下流行的存儲方案Ceph與Rook，還有Rancher開源的容器化分布式存儲Longhorn。
Ceph
Ceph是一種動態托管、橫向擴展的分布式存儲集群。Ceph面向存儲資源提供一種邏輯抽象機制，其設計理念包括無單點故障、自管理以及軟件定義等特性。Ceph可以面向同一套存儲集群分別提供塊存儲、對象存儲以及文件存儲的對應接口。
Ceph架構相當復雜的，其中使用到大量的底層技術，例如RADOS、librados、RADOSGW、RDB、CRUSH算法，外加monitor、OSD以及MDS等功能性組件。這里我們先不談它的底層架構，關鍵在于Ceph屬于一種分布式存儲集群，這使得擴展更便利、能夠在不犧牲性能的前提下消除單點故障，且提供涵蓋對象存儲、塊存儲以及文件存儲的統一存儲體系。
很明顯，Ceph與云原生環境彼此兼容的，我們也可以利用多種方法部署一套Ceph集群，譬如使用Ansible。我們可以部署一套Ceph集群，并使用CSI與持久卷聲明來提供指向Kubernetes集群的接口。
?
Ceph架構圖
Rook
另一個有趣且頗具人氣的項目是Rook，這是一項旨在將Kubernetes與Ceph融合起來的技術方案。從本質上講，它將計算節點和存儲節點放進了同一個集群當中。
Rook是一種云原生編排器，并對Kubernetes做出擴展。Rook允許用戶將Ceph放置在容器內，同時提供卷管理邏輯以立足Kubernetes之上實現Ceph的可靠運行。Rook還使本應由集群管理員操作的多種任務完成了自動化實現，其中包括部署、引導、配置、擴展以及負載均衡等等。
Rook可以像Kubernetes一樣使用yaml文件來部署Ceph集群。這種文件以高級聲明的形式存在，負責為集群管理員提供所需要的全部內容。
Rook在集群啟動完成后，即開始進行實時監控。Rook將以操作端或者控制端的姿態確保yaml文件中所聲明的狀態始終正常。Rook運行在一套協調的邏輯循環中，該循環將觀察運行狀態并根據檢測到的異常采取響應。
Rook自身不具備持久狀態，也不需要單獨管理。這，才是真正與Kubernetes設計原則相符的存儲資源管理方案。
Rook憑借著將Ceph與Kubernetes協同起來的強大能力而頗受歡迎，在GitHub上獲得近4000顆星，1600多萬次的下載，并吸引到100多名貢獻者，現已進入CNCF孵化階段。
Longhorn
Longhorn項目是Rancher Labs推出的開源的基于云和容器部署的分布式塊存儲新方式。Longhorn遵循微服務的原則，利用容器將小型獨立組件構建為分布式塊存儲，并使用容器編排來協調這些組件，形成彈性分布式系統。
?
如今，基于云和容器的部署規模日益擴大，分布式塊存儲系統也正變得越來越復雜，單個存儲控制器上的volume數量在不斷增加。2000年代初，存儲控制器上的volume數量只有幾十個，但現代云環境卻需要數萬到數百萬的分布式塊存儲卷。存儲控制器變成了高度復雜的分布式系統。
?
Longhorn充分利用了近年來關于如何編排大量的容器和虛擬機的核心技術。例如，Longhorn并沒有構建一個可以擴展到100,000個volume的高度復雜的控制器，而是出于讓存儲控制器簡單輕便的考慮，創建了100,000個單獨的控制器。然后，我們可以利用像Kubernetes這樣的最先進的編排系統來調度這些獨立的控制器，共享一組磁盤中的資源，協同工作，形成一個彈性的分布式塊存儲系統。
?
Longhorn基于微服務的設計還有很多其他優勢。因為每個volume都有自己的控制器，在升級每個volume的控制器和replica容器時，是不會導致IO操作明顯的中斷的。Longhorn可以創建一個長期運行的工作來編排所有live volume的升級，同時確保不會中斷系統正在進行的操作。為確保升級不會導致意外的問題，Longhorn可以選擇升級一小部分volume，并在升級過程中出現問題時回滾到舊版本。這些做法在現代微服務應用中已得到廣泛應用，但在存儲系統中并不常見。希望Longhorn可以助力于微服務在存儲領域的更多應用。
結 語
對于實際應用層面出現的任何問題，最重要的自然是判斷需求、設計系統或者選擇適當的工具。同樣的道理也適用于云原生環境。雖然具體問題非常復雜，但也必然會出現大量工具方案嘗試解決。隨著云原生世界的持續發展，我們可以肯定，新的解決方案將不斷涌現。未來，一切都會更加美好！
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
如何用30分鐘快速優化家中Wi-Fi？阿里工程師有絕招
趣挨踢 | “菜鳥”程序員和“大神”程序員的差別竟然這么大...
女生適合做程序員嗎？
Kubernetes 調度器實現初探
李沐團隊新作Gluon，復現CV經典模型到BERT，簡單好用 | 強烈推薦
日本樂天要求員工學編程，AI 進中小學課堂，全民編程時代來了！
做了四年以太坊核心開發者, 以太坊升級了, 我也該離開了……
喜歡就點擊“在看”吧
總結
以上是生活随笔為你收集整理的深挖Kubernetes存储为何如此难及其解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： boost::core模块实现交换std
- 下一篇： boost::core模块实现交换std