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

[[331868]]

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

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

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

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

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

容器存儲的類型

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

(1)鏡像存儲

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

(2)配置數據存儲

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

(3)應用數據存儲

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

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

平臺中存儲的應用場景

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

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

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

(1)無狀態(tài)服務

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

(2)普通有狀態(tài)服務

和無狀態(tài)服務相比，它多了狀態(tài)保存的需求。Kubernetes提供了以Volume和Persisettent Volume為基礎的存儲系統(tǒng)，可以實現(xiàn)服務狀態(tài)的保存。

(3)有狀態(tài)集群服務

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

容器云存儲設計的重要性

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

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

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

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

2、Kubernetes中幾種常見的存儲系統(tǒng)

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

 

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

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

3、持久化存儲設計

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

 

 

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

4.1 Persistent Volume與Persistent Volume Claim概念介紹

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

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

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

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

(1)直接訪問

 

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

(2)靜態(tài)provision

 

(3)動態(tài)provision

 

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

In-tree Volume Plugin

Out-of-tree Provisioner

Out-of-tree CSI Driver

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

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

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

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

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

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

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

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

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

 

根據這5個階段，Volume的狀態(tài)有以下4種：

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

4.2 基礎Kubernetes存儲架構

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

 

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

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

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

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

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

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

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

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

 

Kubernetes存儲架構設計圖