本文介紹了容器云存儲設計所需要的基本知識，使讀者能對此形成比較立體的認知以及了解設計的重點方向，并進一步介紹了Kubernetes存儲的設計與架構。

[[331868]]

1、容器平臺存儲的基本知識

存儲作為容器平臺重要的組成部分，保證著容器數據的安全，在整個系統中具有舉足輕重的作用，是整個設計的重中之重。

容器中數據的存儲是臨時性的，當容器消失的時候，數據也會隨之消失，后來就有了持久化存儲的研究;在Kubernetes平臺上，Pod中同時多個容器運行，常常需要這些容器共享數據存儲，來保證數據的安全性。Kubernetes抽象出Volume對象來解決存儲方面的問題。Docker也有Volume的概念，但對它只有少量且松散的管理。在Docker中，Volume是磁盤上或者另外一個容器內的一個目錄。后來新增了Volume生命周期的管理，以及Volume的驅動程序，雖然功能還非常有限。

Kubernetes卷具有明確的生命周期——與包裹它的Pod相同。因此，卷比Pod中運行的任何容器的存活周期都長，在容器重新啟動時數據也會得到保留。當然，當一個Pod不再存在時，卷也將不存在。Kubernetes可以支持許多類型的卷，Pod也能同時使用任意數量的卷。

卷的核心是包含一些數據的目錄，Pod中的容器可以訪問該目錄。特定的卷類型可以決定這個目錄如何形成的，并能決定它支持何種介質，以及目錄中存放什么內容。使用卷時，Pod聲明中需要提供卷的類型(.spec.volumes字段)和卷掛載的位置(.spec.containers.volumeMounts字段)。容器中的進程能看到由它們的Docker鏡像和卷組成的文件系統視圖。Docker鏡像位于文件系統層次結構的根部，并且任何Volume都掛載在鏡像內的指定路徑上。卷不能掛載到其他卷，也不能與其他卷有硬連接。Pod中的每個容器必須獨立地指定每個卷的掛載位置。

容器存儲的類型

容器架構使用到的三種存儲：

(1)鏡像存儲

這個可以利用現有的共享存儲，類似于虛擬化環境中虛擬機鏡像的分發保護機制。容器鏡像的優勢在于其存儲容量相較于完整的虛擬機鏡像小了很多，因為不會復制操作系統代碼。此外，容器鏡像的運行在設計之初便是固定的，因此可以更高效地存儲、共享。但也因此，容器鏡像無法存儲動態應用程序的數據。

(2)配置數據存儲

這些配置數據用來管理容器，可以借助現有的存儲來實現，主要是一些配置數據和日志記錄等管理數據。

(3)應用數據存儲

這些數據是重要的、臨時的，也是最難存儲下來的。相比虛擬機，容器的設計壽命更短，一旦容器銷毀，所有的臨時存儲都會隨之消失。因此，應用真正需要保存的數據，可以寫入持久化的Volume數據卷。由于以微服務為主的容器應用多位分布式系統，容器可能在多個節點中動態地啟動、停止、伸縮或者遷移。因此，當容器應用具有持久化的數據時，必須確保數據能被不同的節點所訪問。另一方面，容器是面向應用的運行環境，數據通常要保存到文件系統中，即存儲接口以文件形式更適應應用訪問。

數據持久化存儲數據量需要提前做好規劃，對于容器遷移的支持也同樣需要提供存儲方面的支持。需要根據業務不同的需求，來提供不同的存儲。etcd會存儲平臺的狀態和配置信息，那么對性能、安全、穩定的要求就比較高。

平臺中存儲的應用場景

Kubernetes中對于存儲的使用主要集中在以下幾個方面：

• 服務的基本配置文件讀取、密碼密鑰管理等;
• 服務的存儲狀態、數據存儲等;
• 不同服務或應用程序間共享數據;

在Kubernetes中部署和運行的服務大致分為：

(1)無狀態服務

Kubernetes使用ReplicateSet來保證一個服務的實例數量，如果說某個Pod實例由于某種原因掛掉或者崩潰，ReplicateSet會立刻用這個Pod的模版來替代它。由于是無狀態的服務，新Pod與舊Pod一摸一樣。此外Kubernetes通過Service(一個Service后面可以掛多個Pod)對外提供一個穩定的訪問接口，實現服務的高可用。

(2)普通有狀態服務

和無狀態服務相比，它多了狀態保存的需求。Kubernetes提供了以Volume和Persisettent Volume為基礎的存儲系統，可以實現服務狀態的保存。

(3)有狀態集群服務

和普通有狀態服務相比，它多了集群管理的需求。要運行有狀態集群服務要解決的問題有兩個，一個是狀態保存，另一個是集群管理。Kubernetes為此開發了StatefulSet，方便有狀態集群服務在Kubernetes上部署和管理。

容器云存儲設計的重要性

數據是一個企業重要的資產，如何利用好數據，可以實現企業的興盛，如何保存好數據，則是保障企業興盛的堅強后盾。因此，在平臺建設前的規劃階段，必須做好充分的技術準備和項目調研，必須將數據的重要性提升到一個重要的層面來引起重視。

數據是企業的重要資產，保證數據不丟失，數據完整，數據一致，才能更好的開展業務。容器和虛擬機或物理機技術實現側重不同，容器側重無狀態應用，要支持有狀態應用，數據存儲必須基于業務需求提前考慮和規劃。

容器云是基礎平臺，涉及平臺組件、鏡像、應用、中間件等多個方面，每個方面都可能有不同的存儲需求。要獲得理想的性能和結果，需要全面的考慮每個方面，存儲等作為基礎設施資源，更是必不可少的部分。

容器是用來承載應用的，應用各個層次的數據具有潛在的價值，捕獲并處理、存儲、分析這些數據是獲取價值的步驟。因此，應用數據的持久化是容器云平臺支撐業務應用的重要的基礎能力之一。建好基礎，才能好地服務應用。

2、Kubernetes中幾種常見的存儲系統

從Kubernetes官方提供的數據看來，Kubernetes支持的Volume Plugin如下表所示：

 

Kubernetes已經提供了非常豐富的Volume和Persistent Volume插件，可以根據自身業務的特性，使用這些插件給容器提供存儲服務。每一種Plugin的使用方法和注意事項參見：https://kuberne-tes.io/zh/docs/concepts/storage/

容器存儲接口(Container Storage Interface，CSI)是一項跨行業標準倡議，旨在降低云原生存儲開發工作的門檻，從而進一步確保兼容性水平。Kubernetes中CSI，將新分卷插件的安裝流程簡化至與安裝Pod相當，并允許第三方存儲供應商在無需接觸核心Kubernetes代碼庫的前提下開發自己的解決方案。

3、持久化存儲設計

前面提到了，數據是企業開展業務，進一步獲取價值的源泉，是核心資產。重要的數據必須做持久化存儲并按照監管/業務要求進行備份。容器持久化存儲一般可以通過兩種形式來實現：第一，是本地盤的形式，優勢是簡單易用，缺點是難以遷移共享以及伸縮;第二，是共享存儲集群的形式，優勢是數據共享，可以提供多種存儲接口，可以彈性伸縮，缺點是架構稍顯復雜。針對不同場景，持久化存儲需要有不同的選擇策略：

 

 

4 Kubernetes存儲的設計與基本架構

4.1 Persistent Volume與Persistent Volume Claim概念介紹

一個運行中的容器，在缺省情況下，對文件系統的寫入，都是發生在其分層文件系統的可寫層的(copy-on-write)。當遷移的應用程序從開發到生產環境的時候，開發人員面臨著巨大的挑戰。當容器掛掉、崩潰或者運行結束時，任何與之相關的數據都會丟失。為了解決這個問題引發的數據丟失，我們需要將數據存儲持久化，也可以稱為Persistent Volume。

Kubernetes使用兩種資源管理存儲：

• Persistent Volume(簡稱PV)：由管理員添加的一個存儲的描述，是一個全局資源，包含存儲的類型，存儲的大小和訪問模式等。它的生命周期獨立于Pod，例如當前使用它的Pod銷毀時對PV沒有影響。
• Persistent Volume Claim(簡稱PVC)：是Namespace里的資源，描述對PV的一個請求，請求信息包含存儲大小、訪問模式等。

Kubernetes中的Volume則是基于Docker進行擴展，使用 Docker Volume掛載宿主機上的文件目錄到容器中。一般說來，Kubernetes中的Pod通過如下三種方式來訪問存儲：

(1)直接訪問

 

該方式移植性較差，可擴展能力差，把Volume的基本信息完全暴露給用戶，有嚴重的安全隱患，同時需要協調不同user對Volume的訪問。

(2)靜態provision

 

(3)動態provision

 

很明顯，動態供應比靜態供應靈活更多，而且這種方式還解耦了Kubernetes系統的計算層和存儲層，更重要的是它給存儲供應商提供了可插拔式的開發模型，存儲供應商只需要根據這個模型開發相應的卷插件即可為Kubernetes提供存儲服務。有三種方法實現：

In-tree Volume Plugin

Out-of-tree Provisioner

Out-of-tree CSI Driver

第一種，Kubernetes內部代碼中實現了一些存儲插件，用于支持一些主流網絡存儲。

第二種，如果有官方插件不能滿足要求，存儲供應商可以根據需要去定制或者優化存儲插件并集成到Kubernetes系統。

第三種，是容器存儲接口CSI，是Kubernetes對外開放的存儲接口，實現這個接口即可集成到Kubernetes系統中。社區之前已經宣布將不再對in tree/out of tree繼續開發，并將已有功能全部遷移到CSI上，所以對于存儲供應商和使用者來說，第三種CSI方案更值得推薦。

一般來說，PV和PVC的生命周期分為5個階段：

(1)Provisioning，即PV的創建，可以直接創建PV(靜態方式)，也可以使用Storage Class動態創建;

(2)Binding，將PV分配給PVC;

(3)Using，Pod通過PVC使用該Volume;

(4)Releasing，Pod釋放Volume并刪除PVC;

(5)Reclaiming，回收PV，可以保留PV以便下次使用，也可以直接從存儲中刪除。

 

根據這5個階段，Volume的狀態有以下4種：

• Available：可用
• Bound：已經分配給PVC
• Release：PVC解綁但還未執行回收策略
• Failed：發生錯誤

4.2 基礎Kubernetes存儲架構

Kubernetes存儲在設計的時候遵循聲明式(Declarative)架構。同時為了盡可能多地兼容各種存儲平臺，Kubernetes以in-tree plugin的形式來對接不同的存儲系統，滿足用戶可以根據自己業務的需要使用這些插件給容器提供存儲服務。同時兼容用戶使用FlexVolume和CSI定制化插件。相比較于Docker Volume，支持的存儲功能更加豐富和多樣。

 

Kubernetes中mount一個PV的基本過程包括：

(1)用戶通過API創建一個包含PVC的Pod;

(2)Scheduler把這個Pod分配到某個節點Node;

(3)節點Node上的Kublet開始等待Volume Manager準備Device;

(4)PV controller調用相應Volume Plugin(in-tree或者out-of-tree)，創建PV，并在系統中與對應的PVC綁定;

(5)Attach/Detach controller或者Volume Manager通過Volume Plugin實現Device掛載(Attach);

(6)Volume Manager等待Device掛載完畢后，將卷掛載到節點指定目錄;

(7)Node節點上的Kublet此時被告知Volume已經準備好后，開始啟動Pod，通過Volume mapping將PV掛載到相應的容器中去。

 

Kubernetes存儲架構設計圖