![red-berries-4760840_1920.jpg](https://ucc.alicdn.com/pic/developer-ecology/203c0b56f0c3477296648dfb81e5d616.jpg)
作者 | 闞俊寶  阿里巴巴高階技術專家

本文整理自《CNCF x Alibaba 雲原生技術公開課》第 21 講。 關注“阿里巴巴雲原生”公眾號，回覆關鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。

> **導讀：**容器儲存是 Kubernetes 系統中提供資料持久化的基礎元件，是實現有狀態服務的重要保證。Kubernetes 預設提供了主流的儲存卷接入方案（In-Tree），同時也提供了外掛機制（Out-Of-Tree），允許其他型別的儲存服務接入 Kubernetes 系統服務。本文將從 Kubernetes 儲存架構、儲存外掛原理、實現等方面進行講解，希望大家有所收穫。

# 一、Kubernetes 儲存體系架構

## 引例： 在 Kubernetes 中掛載一個 Volume

首先以一個 Volume 的掛載例子來作為引入。

如下圖所示，左邊的 YAML 模板定義了一個 StatefulSet 的一個應用，其中定義了一個名為 disk-pvc 的 volume，掛載到 Pod 內部的目錄是 /data。disk-pvc 是一個 PVC 型別的資料卷，其中定義了一個 storageClassName。

因此這個模板是一個典型的動態儲存的模板。右圖是資料卷掛載的過程，主要分為 6 步：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/827b01acd90341d096b462f5d2dc07b0.png)

- **第一步**：使用者建立一個包含 PVC的 Pod；

- **第二步**：PV Controller 會不斷觀察 ApiServer，如果它發現一個 PVC 已經建立完畢但仍然是未繫結的狀態，它就會試圖把一個 PV 和 PVC 繫結；

PV Controller 首先會在叢集內部找到一個適合的 PV 進行繫結，如果未找到相應的 PV，就呼叫 Volume Plugin 去做 Provision。Provision 就是從遠端上一個具體的儲存介質建立一個 Volume，並且在叢集中建立一個 PV 物件，然後將此 PV 和 PVC 進行繫結；

- **第三步**：透過 Scheduler 完成一個排程功能；

我們知道，當一個 Pod 執行的時候，需要選擇一個 Node，這個節點的選擇就是由 Scheduler 來完成的。Scheduler 進行排程的時候會有多個參考量，比如 Pod 內部所定義的 nodeSelector、nodeAffinity 這些定義以及 Volume 中所定義的一些標籤等。

我們可以在資料卷中新增一些標籤，這樣使用這個 pv 的 Pod 就會由於標籤的限制，被排程器排程到期望的節點上。

- **第四步**：如果有一個 Pod 排程到某個節點之後，它所定義的 PV 還沒有被掛載（Attach），此時 AD Controller 就會呼叫 VolumePlugin，把遠端的 Volume 掛載到目標節點中的裝置上（如：/dev/vdb）；

- **第五步：**當 Volum Manager 發現一個 Pod 排程到自己的節點上並且 Volume 已經完成了掛載，它就會執行 mount 操作，將本地裝置（也就是剛才得到的 /dev/vdb）掛載到 Pod 在節點上的一個子目錄中。同時它也可能會做一些像格式化、是否掛載到 GlobalPath 等這樣的附加操作。

- **第六步**：繫結操作，就是將已經掛載到本地的 Volume 對映到容器中。

## Kubernetes 的儲存架構
接下來，我們一起看一下 Kubernetes 的儲存架構。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/be84773ac4f242e29167a124ac55566f.png)

- **PV Controller**: 負責 PV/PVC 的繫結、生命週期管理，並根據需求進行資料卷的 Provision/Delete 操作；

- **AD Controller**：負責儲存裝置的 Attach/Detach 操作，將裝置掛載到目標節點；

- **Volume Manager**：管理卷的 Mount/Unmount 操作、卷裝置的格式化以及掛載到一些公用目錄上的操作；

- **Volume Plugins**：它主要是對上面所有掛載功能的實現；

PV Controller、AD Controller、Volume Manager 主要是進行操作的呼叫，而具體操作則是由 Volume Plugins 實現的。

- **Scheduler**：實現對 Pod 的排程能力，會根據一些儲存相關的的定義去做一些儲存相關的排程；

接下來，我們分別介紹上面這幾部分的功能。

### PV Controller
首先我們先來回顧一下幾個基本概念：

- **Persistent Volume (PV)**： 持久化儲存卷，詳細定義了預掛載儲存空間的各項引數；

例如，我們去掛載一個遠端的 NAS 的時候，這個 NAS 的具體引數就要定義在 PV 中。一個 PV 是沒有 NameSpace 限制的，它一般由 Admin 來建立與維護；

- **Persistent Volume Claim (PVC)**：持久化儲存宣告；

它是使用者所使用的儲存介面，對儲存細節無感知，主要是定義一些基本儲存的 Size、AccessMode 引數在裡面，並且它是屬於某個 NameSpace 內部的。

- **StorageClass**：儲存類；

一個動態儲存卷會按照 StorageClass 所定義的模板來建立一個 PV，其中定義了建立模板所需要的一些引數和建立 PV 的一個 Provisioner（就是由誰去建立的）。

PV Controller 的主要任務就是完成 PV、PVC 的生命週期管理，比如建立、刪除 PV 物件，負責 PV、PVC 的狀態遷移；另一個任務就是繫結 PVC 與 PV 物件，一個 PVC 必須和一個 PV 繫結後才能被應用使用，它們是一一繫結的，一個 PV 只能被一個 PVC 繫結，反之亦然。   接下來，我們看一下一個 PV 的狀態遷移圖。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/ce66a434ad924dac812fd5ee45115ebc.png)

建立好一個 PV 以後，我們就處於一個 Available 的狀態，當一個 PVC 和一個 PV 繫結的時候，這個 PV 就進入了 Bound 的狀態，此時如果我們把 PVC 刪掉，Bound 狀態的 PV 就會進入 Released 的狀態。

一個 Released 狀態的 PV 會根據自己定義的 ReclaimPolicy 欄位來決定自己是進入一個 Available 的狀態還是進入一個 Deleted 的狀態。如果 ReclaimPolicy 定義的是 "recycle" 型別，它會進入一個 Available 狀態，如果轉變失敗，就會進入 Failed 的狀態。

相對而言，PVC 的狀態遷移圖就比較簡單。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/4f29e87ce9294113b38880bbd68daf0e.png)

一個建立好的 PVC 會處於 Pending 狀態，當一個 PVC 與 PV 繫結之後，PVC 就會進入 Bound 的狀態，當一個 Bound 狀態的 PVC 的 PV 被刪掉之後，該 PVC 就會進入一個 Lost 的狀態。對於一個 Lost 狀態的 PVC，它的 PV 如果又被重新建立，並且重新與該 PVC 繫結之後，該 PVC 就會重新回到 Bound 狀態。

下圖是一個 PVC 去繫結 PV 時對 PV 篩選的一個流程圖。就是說一個 PVC 去繫結一個 PV 的時候，應該選擇一個什麼樣的 PV 進行繫結。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/efaa7acc32fd4a2b80051bd4155b660a.png)

- **首先**它會檢查 VolumeMode 這個標籤，PV 與 PVC 的 VolumeMode 標籤必須相匹配。VolumeMode 主要定義的是我們這個資料卷是檔案系統 (FileSystem) 型別還是一個塊 (Block) 型別；

- **第二個部分**是 LabelSelector。當 PVC 中定義了 LabelSelector 之後，我們就會選擇那些有 Label 並且與 PVC 的 LabelSelector 相匹配的 PV 進行繫結；

- **第三個部分**是 StorageClassName 的檢查。如果 PVC 中定義了一個 StorageClassName，則必須有此相同類名的 PV 才可以被篩選中。

這裡再具體解釋一下 StorageClassName 這個標籤，該標籤的目的就是說，當一個 PVC 找不到相應的 PV 時，我們就會用該標籤所指定的 StorageClass 去做一個動態建立 PV 的操作，同時它也是一個繫結條件，當存在一個滿足該條件的 PV 時，就會直接使用現有的 PV，而不再去動態建立。

- **第四個部分**是 AccessMode 檢查。

AccessMode 就是平時我們在 PVC 中定義的如 "ReadWriteOnce"、"RearWriteMany" 這樣的標籤。該繫結條件就是要求 PVC 和 PV 必須有匹配的 AccessMode，即 PVC 所需求的 AccessMode 型別，PV 必須具有。

- **最後**一個部分是 Size 的檢查。

一個 PVC 的 Size 必須小於等於 PV 的 Size，這是因為 PVC 是一個宣告的 Volume，實際的 Volume 必須要大於等於宣告的 Volume，才能進行繫結。

接下來，我們看一個 PV Controller 的一個實現。

PV Controller 中主要有兩個實現邏輯：一個是 ClaimWorker；一個是 VolumeWorker。

ClaimWorker 實現的是 PVC 的狀態遷移。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/4b2b674d11794036988d1b512c153231.png)

透過系統標籤 "pv.kubernetes.io/bind-completed" 來標識一個 PVC 的狀態。

- 如果該標籤為 True，說明我們的 PVC 已經繫結完成，此時我們只需要去同步一些內部的狀態；
- 如果該標籤為 False，就說明我們的 PVC 處於未繫結狀態。

這個時候就需要檢查整個叢集中的 PV 去進行篩選。透過 findBestMatch 就可以去篩選所有的 PV，也就是按照之前提到的五個繫結條件來進行篩選。如果篩選到 PV，就執行一個 Bound 操作，否則就去做一個 Provision 的操作，自己去建立一個 PV。

再看 VolumeWorker 的操作。它實現的則是 PV 的狀態遷移。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/8b609ce7bf194f6889c8aa04d91d371e.png)

透過 PV 中的 ClaimRef 標籤來進行判斷，如果該標籤為空，就說明該 PV 是一個 Available 的狀態，此時只需要做一個同步就可以了；如果該標籤非空，這個值是 PVC 的一個值，我們就會去叢集中查詢對應的 PVC。如果存在該 PVC，就說明該 PV 處於一個 Bound 的狀態，此時會做一些相應的狀態同步；如果找不到該 PVC，就說明該 PV 處於一個繫結過的狀態，相應的 PVC 已經被刪掉了，這時 PV 就處於一個 Released 的狀態。此時再根據 ReclaimPolicy 是否是 Delete 來決定是刪掉還是隻做一些狀態的同步。   以上就是 PV Controller 的簡要實現邏輯。

### AD Controller
AD Controller 是 Attach/Detach Controller 的一個簡稱。

它有兩個核心物件，即 DesiredStateofWorld 和 ActualStateOfWorld。

- DesiredStateofWorld 是叢集中預期要達到的資料卷的掛載狀態；
- ActualStateOfWorld 則是叢集內部實際存在的資料卷掛載狀態。

它有兩個核心邏輯，desiredStateOfWorldPopulator 和 Reconcile。

- desiredStateOfWorldPopulator 主要是用來同步叢集的一些資料以及 DSW、ASW 資料的更新，它會把叢集裡面，比如說我們建立一個新的 PVC、建立一個新的 Pod 的時候，我們會把這些資料的狀態同步到 DSW 中；

- Reconcile 則會根據 DSW 和 ASW 物件的狀態做狀態同步。它會把 ASW 狀態變成 DSW 狀態，在這個狀態的轉變過程中，它會去執行 Attach、Detach 等操作。

下面這個表分別給出了 desiredStateOfWorld 以及 actualStateOfWorld 物件的一個具體例子。

- desiredStateOfWorld 會對每一個 Worker 進行定義，包括 Worker 所包含的 Volume 以及一些試圖掛載的資訊；
- actualStateOfWorl 會把所有的 Volume 進行一次定義，包括每一個 Volume 期望掛載到哪個節點上、掛載的狀態是什麼樣子的等等。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/f2d8148efa0d40f899b9ec9b15fb7b5e.png)

下圖是 AD Controller 實現的邏輯框圖。

從中我們可以看到，AD Controller 中有很多 Informer，Informer 會把叢集中的 Pod 狀態、PV 狀態、Node 狀態、PVC 狀態同步到本地。

在初始化的時候會呼叫 populateDesireStateofWorld 以及 populateActualStateofWorld 將 desireStateofWorld、actualStateofWorld 兩個物件進行初始化。

在執行的時候，透過 desiredStateOfWorldPopulator 進行資料同步，即把叢集中的資料狀態同步到 desireStateofWorld 中。reconciler 則透過輪詢的方式把 actualStateofWorld 和 desireStateofWorld 這兩個物件進行資料同步，在同步的時候，會透過呼叫 Volume Plugin 進行 attach 和 detach 操作，同時它也會呼叫 nodeStatusUpdater 對 Node 的狀態進行更新。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/70759996a961448f8d6455a090c5d2ae.png)

以上就是 AD Controller 的簡要實現邏輯。

### Volume Manager
Volume Manager 實際上是 Kubelet 中一部分，是 Kubelet 中眾多 Manager 的一個。它主要是用來做本節點 Volume 的 Attach/Detach/Mount/Unmount 操作。

它和 AD Controller 一樣包含有 desireStateofWorld 以及 actualStateofWorld，同時還有一個 volumePluginManager 物件，主要進行節點上外掛的管理。在核心邏輯上和 AD Controller 也類似，透過 desiredStateOfWorldPopulator 進行資料的同步以及透過 Reconciler 進行介面的呼叫。

這裡我們需要講一下 Attach/Detach 這兩個操作：

之前我們提到 AD Controller 也會做 Attach/Detach 操作，所以到底是由誰來做呢？我們可以透過 "--enable-controller-attach-detach" 標籤進行定義，如果它為 True，則由 AD Controller 來控制；若為 False，就由 Volume Manager 來做。

它是 Kubelet 的一個標籤，只能定義某個節點的行為，所以如果假設一個有 10 個節點的叢集，它有 5 個節點定義該標籤為 False，說明這 5 個節點是由節點上的 Kubelet 來做掛載，而其它 5 個節點是由 AD Controller 來做掛載。

下圖是 Volume Manager 實現邏輯圖。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/37008bb3525c47dbbecca528e5710746.png)

我們可以看到，最外層是一個迴圈，內部則是根據不同的物件，包括 desireStateofWorld， actualStateofWorld 的不同物件做一個輪詢。

例如，對 actualStateofWorld 中的 MountedVolumes 物件做輪詢，對其中的某一個 Volume，如果它同時存在於 desireStateofWorld，這就說明實際的和期望的 Volume 均是處於掛載狀態，因此我們不會做任何處理。如果它不存在於 desireStateofWorld，說明期望狀態中該 Volume 應該處於 Umounted 狀態，就執行 UnmountVolume，將其狀態轉變為 desireStateofWorld 中相同的狀態。

所以我們可以看到：實際上，該過程就是根據 desireStateofWorld 和 actualStateofWorld 的對比，再呼叫底層的介面來執行相應的操作，下面的 desireStateofWorld.UnmountVolumes 和 actualStateofWorld.AttachedVolumes 的操作也是同樣的道理。

### Volume Plugins
我們之前提到的 PV Controller、AD Controller 以及 Volume Manager 其實都是透過呼叫 Volume Plugin 提供的介面，比如 Provision、Delete、Attach、Detach 等去做一些 PV、PVC 的管理。而這些介面的具體實現邏輯是放在 VolumePlugin 中的

根據原始碼的位置可將 Volume Plugins 分為 In-Tree 和 Out-of-Tree 兩類：

- In-Tree 表示原始碼是放在 Kubernetes 內部的，和 Kubernetes 一起釋出、管理與迭代，缺點及時迭代速度慢、靈活性差；
- Out-of-Tree 類的 Volume Plugins 的程式碼獨立於 Kubernetes，它是由儲存商提供實現的，目前主要有 Flexvolume 和 CSI 兩種實現機制，可以根據儲存型別實現不同的儲存外掛。所以我們比較推崇 Out-of-Tree 這種實現邏輯。

從位置上我們可以看到，Volume Plugins 實際上就是 PV Controller、AD Controller 以及 Volume Manager 所呼叫的一個庫，分為 In-Tree 和 Out-of-Tree 兩類 Plugins。它透過這些實現來呼叫遠端的儲存，比如說掛載一個 NAS 的操作 "mount -t nfs ***"，該命令其實就是在 Volume Plugins 中實現的，它會去呼叫遠端的一個儲存掛載到本地。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/7da549b58fe44840bfcfd30d72cb2c35.png)

從型別上來看，Volume Plugins 可以分為很多種。In-Tree 中就包含了 幾十種常見的儲存實現，但一些公司的自己定義私有型別，有自己的 API 和引數，公共儲存外掛是無法支援的，這時就需要 Out-of-Tree 類的儲存實現，比如 CSI、FlexVolume。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/70db6852adc843098c657c5b7c882de3.png)

Volume Plugins 的具體實現會放到後面去講。這裡主要看一下 Volume Plugins 的外掛管理。

Kubernetes會在 PV Controller、AD Controller 以及 Volume Manager 中來做外掛管理。透過 VolumePlguinMg 物件進行管理。主要包含 Plugins 和 Prober 兩個資料結構。

Plugins 主要是用來儲存 Plugins 列表的一個物件，而 Prober 是一個探針，用於發現新的 Plugin，比如 FlexVolume、CSI 是擴充套件的一種外掛，它們是動態建立和生成的，所以一開始我們是無法預知的，因此需要一個探針來發現新的 Plugin。

下圖是外掛管理的整個過程。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/3e5213685724478683738ec2a728613b.png)

PV Controller、AD Controller 以及 Volume Manager 在啟動的時候會執行一個 InitPlugins 方法來對 VolumePluginsMgr 做一些初始化。

它首先會將所有 In-Tree 的 Plugins 加入到我們的外掛列表中。同時會呼叫 Prober 的 init 方法，該方法會首先呼叫一個 InitWatcher，它會時刻觀察著某一個目錄 (比如圖中的 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/)，當這個目錄每生成一個新檔案的時候，也就是建立了一個新的 Plugins，此時就會生成一個新的 FsNotify.Create 事件，並將其加入到 EventsMap 中；同理，如果刪除了一個檔案，就生成一個 FsNotify.Remove 事件加入到 EventsMap 中。

當上層呼叫 refreshProbedPlugins 時，Prober 就會把這些事件進行一個更新，如果是 Create，就將其新增到外掛列表；如果是 Remove，就從外掛列表中刪除一個外掛。

以上就是 Volume Plugins 的外掛管理機制。

### Kubernetes 儲存卷排程
我們之前說到 Pod 必須被排程到某個 Worker 上才能去執行。在排程 Pod 時，我們會使用不同的排程器來進行篩選，其中有一些與 Volume 相關的排程器。例如 VolumeZonePredicate、VolumeBindingPredicate、CSIMaxVolumLimitPredicate 等。

VolumeZonePredicate 會檢查 PV 中的 Label，比如 failure-domain.beta.kubernetes.io/zone 標籤，如果該標籤定義了 zone 的資訊，VolumeZonePredicate 就會做相應的判斷，即必須符合相應的 zone 的節點才能被排程。

比如下圖左側的例子，定義了一個 label 的 zone 為 cn-shenzhen-a。右側的 PV 則定義了一個 nodeAffinity，其中定義了 PV 所期望的節點的 Label，該 Label 是透過 VolumeBindingPredicate 進行篩選的。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/608586e635c34ae59008fce9332fc34e.png)

儲存卷具體排程資訊的實現可以參考《[從零開始入門 K8s | 應用儲存和持久化資料卷：儲存快照與拓撲排程](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487353&idx=1&sn=80263666e7e2e17da37374990262d283&chksm=fae504b6cd928da0b44045ed3d1596597a84128cd6a7d6cfbcfac33382a252f295fce2e39d78&scene=21#wechat_redirect)》，這裡會有一個更加詳細的介紹。

# 二、Flexvolume 介紹及使用
Flexvolume 是 Volume Plugins 的一個擴充套件，主要實現 Attach/Detach/Mount/Unmount 這些介面。我們知道這些功能本是由 Volume Plugins 實現的，但是對於某些儲存型別，我們需要將其擴充套件到 Volume Plugins 以外，所以我們需要把介面的具體實現放到外面。

在下圖中我們可以看到，Volume Plugins 其實包含了一部分 Flexvolume 的實現程式碼，但這部分程式碼其實只有一個 “Proxy”的功能。

比如當 AD Controller 呼叫外掛的一個 Attach 時，它首先會呼叫 Volume Plugins 中 Flexvolume 的 Attach 介面，但這個介面只是把呼叫轉到相應的 Flexvolume 的Out-Of-Tree實現上。

Flexvolume是可被 Kubelet 驅動的可執行檔案，每一次呼叫相當於執行一次 shell 的 ls 這樣的指令碼，都是可執行檔案的命令列呼叫，因此它不是一個常駐記憶體的守護程式。

Flexvolume 的 Stdout 作為 Kubelet 呼叫的返回結果，這個結果需要是 JSON 格式。

Flexvolume預設的存放地址為 "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/alicloud~disk/disk"。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/54c8c693c28446c4bf1b840c277d0afb.png)

下面是一個命令格式和呼叫的例項。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/4a66003358ac44b7a9ee2846d2e9fed9.png)

## Flexvolume 的介面介紹

Flexvolum 包含以下介面：

- **init**: 主要做一些初始化的操作，比如部署外掛、更新外掛的時候做 init 操作，返回的時候會返回剛才我們所說的 DriveCapabilities 型別的資料結構，用來說明我們的 Flexvolume 外掛有哪些功能；

- **GetVolumeName**： 返回外掛名;

- **Attach**: 掛載功能的實現。根據 --enable-controller-attach-detach 標籤來決定是由 AD Controller 還是 Kubelet 來發起掛載操作;

- **WaitforAttach**： Attach 經常是非同步操作，因此需要等待掛載完成，才能需要進行下面的操作;

- MountDevice：它是 mount 的一部分。這裡我們將 mount 分為 MountDevice 和 SetUp 兩部分，MountDevice 主要做一些簡單的預處理工作，比如將裝置格式化、掛載到 GlobalMount 目錄中等；

- **GetPath**：獲取每個 Pod 對應的本地掛載目錄；

- **Setup**：使用 Bind 方式將 GlobalPath 中的裝置掛載到 Pod 的本地目錄；

- **TearDown**、**UnmountDevice**、**Detach** 實現的是上面一些藉口的逆過程；

- **ExpandVolumeDevice**：擴容儲存卷，由 Expand Controller 發起呼叫；

- **NodeExpand**： 擴容檔案系統，由 Kubelet 發起呼叫。

上面這些介面不一定需要全部實現，如果某個介面沒有實現的話，可以將返回結果定義成：

```
{
    "status": "Not supported",
    "message": "error message"
}
```

告訴呼叫者沒有實現這個介面。此外，Volume Plugins 中的 Flexvolume 介面除了作為一個 Proxy 外，它也提供了一些預設實現，比如 Mount 操作。所以如果你的 Flexvolume 中沒有定義該介面，該預設實現就會被呼叫。

在定義 PV 時可以透過 secretRef 欄位來定義一些 secret 的功能。比如掛載時所需的使用者名稱和密碼，就可以透過 secretRef 傳入。

## Flexvolume 的掛載分析

從掛載流程和解除安裝流程兩個方向來分析 Flexvolume 的掛載過程。

![17.png](https://ucc.alicdn.com/pic/developer-ecology/7be062cf8e844ac2a7556471c166dc4b.png)

我們首先看 Attach 操作，它呼叫了一個遠端的 API 把我們的 Storage 掛載到目標節點中的某個裝置上去。然後透過 MountDevice 將本地裝置掛載到 GlobalPath 中，同時也會做一些格式化這樣的操作。Mount 操作（SetUp），它會把 GlobalPath 掛載 PodPath 中，PodPath 就是 Pod 啟動時所對映的一個目錄。

下圖給出了一個例子，比如我們一個雲盤，其 Volume ID 為 d-8vb4fflsonz21h31cmss，在執行完 Attach 和 WaitForAttach 操作之後，就會將其掛載到目標節點上的 /dec/vdc 裝置中。執行 MountDevice 之後，就會把上述裝置格式化，掛載到一個本地的 GlobalPath 中。而執行完 Mount 之後，就會將 GlobalPath 對映到 Pod 相關的一個子目錄中。最後執行 Bind 操作，將我們的本地目錄對映到容器中。這樣完成一次掛載過程。

![18.png](https://ucc.alicdn.com/pic/developer-ecology/bc5f070d8bf14ac994ddc2a5075eeaab.png)

解除安裝流程就是一個逆過程。上述過程描述的是一個塊裝置的掛載過程，對於檔案儲存型別，就無需 Attach、MountDevice操作，只需要 Mount 操作，因此檔案系統的 Flexvolume 實現較為簡單，只需要 Mount 和 Unmount 過程即可。

## Flexvolume 的程式碼示例

![19.png](https://ucc.alicdn.com/pic/developer-ecology/3beec866fc4d47dcb704103037c4987b.png)

其中主要實現的是 init()、doMount()、doUnmount() 方法。在執行該指令碼的時候對傳入的引數進行判斷來決定執行哪一個命令。   在 Github 上還有很多 Flexvolume 的示例，大家可以自行參考查閱。阿里雲提供了一個 [Flexvolume 的實現](https://github.com/AliyunContainerService/flexvolume)，有興趣的可以參考一下。

## Flexvolume 的使用
下圖給出了一個 Flexvolume 型別的 PV 模板。它和其它模板實際上沒有什麼區別，只不過型別被定義為 flexVolume 型別。flexVolume 中定義了 driver、fsType、options。

- driver 定義的是我們實現的某種驅動，比如圖中的是 aliclound/disk，也可以是 aliclound/nas 等；
- fsType 定義的是檔案系統型別，比如 "ext4"；
- options 包含了一些具體的引數，比如定義雲盤的 id 等。

我們也可以像其它型別一樣，透過 selector 中的 matchLabels 定義一些篩選條件。同樣也可以定義一些相應的排程資訊，比如定義 zone 為 cn-shenzhen-a。

![20.png](https://ucc.alicdn.com/pic/developer-ecology/2d279e210fb447349393288fcce484e8.png)

下面是一個具體的執行結果。在 Pod 內部我們掛載了一個雲盤，其所在本地裝置為 /dev/vdb。透過 mount | grep disk 我們可以看到相應的掛載目錄，首先它會將 /dev/vdb 掛載到 GlobalPath 中；其次會將 GlobalPath 透過 mount 命令掛載到一個 Pod 所定義的本地子目錄中去；最後會把該本地子目錄對映到 /data 上。

![21.png](https://ucc.alicdn.com/pic/developer-ecology/31a9e77d0f7c45199457957cf7b095d4.png)

# 三、CSI 介紹及使用
和 Flexvolume 類似，CSI 也是為第三方儲存提供資料卷實現的抽象介面。

有了 Flexvolume，為何還要 CSI 呢？   Flexvolume 只是給 kubernetes 這一個編排系統來使用的，而 CSI 可以滿足不同編排系統的需求，比如 Mesos，Swarm。

其次 CSI 是容器化部署，可以減少環境依賴，增強安全性，豐富外掛的功能。我們知道，Flexvolume 是在 host 空間一個二進位制檔案，執行 Flexvolum 時相當於執行了本地的一個 shell 命令，這使得我們在安裝 Flexvolume 的時候需要同時安裝某些依賴，而這些依賴可能會對客戶的應用產生一些影響。因此在安全性上、環境依賴上，就會有一個不好的影響。

同時對於豐富外掛功能這一點，我們在 Kubernetes 生態中實現 operator 的時候，經常會透過 RBAC 這種方式去呼叫 Kubernetes 的一些介面來實現某些功能，而這些功能必須要在容器內部實現，因此像 Flexvolume 這種環境，由於它是 host 空間中的二進位制程式，就沒法實現這些功能。而 CSI 這種容器化部署的方式，可以透過 RBAC 的方式來實現這些功能。

CSI 主要包含兩個部分：CSI Controller Server 與 CSI Node Server。

- Controller Server 是控制端的功能，主要實現建立、刪除、掛載、解除安裝等功能；
- Node Server 主要實現的是節點上的 mount、Unmount 功能。

下圖給出了 CSI 介面通訊的描述。CSI Controller Server 和 External CSI SideCar 是透過 Unix Socket 來進行通訊的，CSI Node Server 和 Kubelet 也是透過 Unix Socket 來通訊，之後我們會講一下 External CSI SiderCar 的具體概念。

![22.png](https://ucc.alicdn.com/pic/developer-ecology/a26d9a4a9b3143d293743ec5aa450d95.png)

下圖給出了 CSI 的介面。主要分為三類：通用管控介面、節點管控介面、中心管控介面。

- 通用管控介面主要返回 CSI 的一些通用資訊，像外掛的名字、Driver 的身份資訊、外掛所提供的能力等；

- 節點管控介面的 NodeStageVolume 和 NodeUnstageVolume 就相當於 Flexvolume 中的 MountDevice 和 UnmountDevice。NodePublishVolume 和 NodeUnpublishVolume 就相當於 SetUp 和 TearDown 介面；

- 中心管控介面的 CreateVolume 和 DeleteVolume 就是我們的 Provision 和 Delete 儲存卷的一個介面，ControllerPublishVolume 和 ControllerUnPublishVolume 則分別是 Attach 和 Detach 的介面。

![23.png](https://ucc.alicdn.com/pic/developer-ecology/5959aa6f8841488da306e631497ffe62.png)

## CSI 的系統結構
CSI 是透過 CRD 的形式實現的，所以 CSI 引入了這麼幾個物件型別：VolumeAttachment、CSINode、CSIDriver 以及 CSI Controller Server 與 CSI Node Server 的一個實現。

![24.png](https://ucc.alicdn.com/pic/developer-ecology/4341928d9cf74f1aba10dc7d5c7e22d0.png)

在 CSI Controller Server 中，有傳統的類似 Kubernetes 中的 AD Controller 和 Volume Plugins，VolumeAttachment 物件就是由它們所建立的。

此外，還包含多個 External Plugin元件，每個元件和 CSI Plugin 組合的時候會完成某種功能。比如：

- External Provisioner 和 Controller Server 組合的時候就會完成資料卷的建立與刪除功能；
- External Attacher 和 Controller Server 組合起來可以執行資料卷的掛載和操作；
- External Resizer 和 Controller Server 組合起來可以執行資料卷的擴容操作；
- External Snapshotter 和 Controller Server 組合則可以完成快照的建立和刪除。

![25.png](https://ucc.alicdn.com/pic/developer-ecology/00121822daba4d3fa77735fb5e9a8ae4.png)

CSI Node Server 中主要包含 Kubelet 元件，包括 VolumeManager 和 VolumePlugin，它們會去呼叫 CSI Plugin 去做 mount 和 unmount 操作；另外一個元件 Driver Registrar 主要實現的是 CSI Plugin 註冊的功能。

以上就是 CSI 的整個拓撲結構，接下來我們將分別介紹不同的物件和元件。

### CSI 物件
我們將介紹 3 種物件：VolumeAttachment，CSIDriver，CSINode。

VolumeAttachment 描述一個 Volume 卷在一個 Pod 使用中掛載、解除安裝的相關資訊。例如，對一個卷在某個節點上的掛載，我們透過 VolumeAttachment 對該掛載進行跟蹤。AD Controller 建立一個 VolumeAttachment，而 External-attacher 則透過觀察該 VolumeAttachment，根據其狀態來進行掛載和解除安裝操作。

下圖就是一個 VolumeAttachment 的例子，其類別 (kind) 為 VolumeAttachment，spec 中指定了 attacher 為 ossplugin.csi.alibabacloud.com，即指定掛載是由誰操作的；指定了 nodeName 為 cn-zhangjiakou.192.168.1.53，即該掛載是發生在哪個節點上的；指定了 source 為 persistentVolumeName 為 oss-csi-pv，即指定了哪一個資料捲進行掛載和解除安裝。

status 中 attached 指示了掛載的狀態，如果是 False， External-attacher 就會執行一個掛載操作。

![26.png](https://ucc.alicdn.com/pic/developer-ecology/f7e88b2a04594bb98111c5881e8e5916.png)

第二個物件是 CSIDriver，它描述了叢集中所部署的 CSI Plugin 列表，需要管理員根據外掛型別進行建立。

例如下圖中建立了一些 CSI Driver，透過 `kuberctl get csidriver` 我們可以看到叢集裡面建立的 3 種型別的 CSI Driver：一個是雲盤；一個是 NAS；一個是 OSS。

在 CSI Driver 中，我們定義了它的名字，在 spec 中還定義了 attachRequired 和 podInfoOnMount 兩個標籤。

- attachRequired 定義一個 Plugin 是否支援 Attach 功能，主要是為了對塊儲存和檔案儲存做區分。比如檔案儲存不需要 Attach 操作，因此我們將該標籤定義為 False；
- podInfoOnMount 則是定義 Kubernetes 在呼叫 Mount 介面時是否帶上 Pod 資訊。

![27.png](https://ucc.alicdn.com/pic/developer-ecology/21cdf4bd73bb40049cb188e0028b31a7.png)

第三個物件是 CSINode，它是叢集中的節點資訊，由 node-driver-registrar 在啟動時建立。它的作用是每一個新的 CSI Plugin 註冊後，都會在 CSINode 列表裡新增一個 CSINode 資訊。

例如下圖，定義了 CSINode 列表，每一個 CSINode 都有一個具體的資訊（左側的 YAML）。以 一 cn-zhangjiakou.192.168.1.49 為例，它包含一個雲盤的 CSI Driver，還包含一個 NAS 的 CSI Driver。每個 Driver 都有自己的 nodeID 和它的拓撲資訊 topologyKeys。如果沒有拓撲資訊，可以將 topologyKeys 設定為 "null"。也就是說，假如有一個有 10 個節點的叢集，我們可以只定義一部分節點擁有 CSINode。

![28.png](https://ucc.alicdn.com/pic/developer-ecology/8d8ccc3214c246d19488a485b0d0af7e.png)

### CSI 元件之 Node-Driver-Registrar
Node-Driver-Registrar 主要實現了 CSI Plugin 註冊的一個機制。我們來看一下下圖中的流程圖。

![29.png](https://ucc.alicdn.com/pic/developer-ecology/2b24b73055b34a6d91e675772ce0c968.png)

- **第 1 步**，在啟動的時候有一個約定，比如說在 /var/lib/kuberlet/plugins_registry 這個目錄每新加一個檔案，就相當於每新加了一個 Plugin；

啟動 Node-Driver-Registrar，它首先會向 CSI-Plugin 發起一個介面呼叫 GetPluginInfo，這個介面會返回 CSI 所監聽的地址以及 CSI-Plugin 的一個 Driver name；

- **第 2 步**，Node-Driver-Registrar 會監聽 GetInfo 和 NotifyRegistrationStatus 兩個介面；

- **第 3 步**，會在 `/var/lib/kuberlet/plugins_registry` 這個目錄下啟動一個 Socket，生成一個 Socket 檔案 ，例如："diskplugin.csi.alibabacloud.com-reg.sock"，此時 Kubelet 透過 Watcher 發現這個 Socket 後，它會透過該 Socket 向 Node-Driver-Registrar 的 GetInfo 介面進行呼叫。GetInfo 會把剛才我們所獲得的的 CSI-Plugin 的資訊返回給 Kubelet，該資訊包含了 CSI-Plugin 的監聽地址以及它的 Driver name；

- **第 4 步**，Kubelet 透過得到的監聽地址對 CSI-Plugin 的 NodeGetInfo 介面進行呼叫；

- **第 5 步**，呼叫成功之後，Kubelet 會去更新一些狀態資訊，比如節點的 Annotations、Labels、status.allocatable 等資訊，同時會建立一個 CSINode 物件；

- **第 6 步**，透過對 Node-Driver-Registrar 的 NotifyRegistrationStatus 介面的呼叫告訴它我們已經把 CSI-Plugin 註冊成功了。

透過以上 6 步就實現了 CSI Plugin 序號產生器制。

### CSI 元件之 External-Attacher
External-Attacher 主要是透過 CSI Plugin 的介面來實現資料卷的掛載與解除安裝功能。它透過觀察 VolumeAttachment 物件來實現狀態的判斷。VolumeAttachment 物件則是透過 AD Controller 來呼叫 Volume Plugin 中的 CSI Attacher 來建立的。CSI Attacher 是一個 In-Tree 類，也就是說這部分是 Kubernetes 完成的。

當 VolumeAttachment 的狀態是 False 時，External-Attacher 就去呼叫底層的一個 Attach 功能；若期望值為 False，就透過底層的 ControllerPublishVolume 介面實現 Detach 功能。同時，External-Attacher 也會同步一些 PV 的資訊在裡面。

![30.png](https://ucc.alicdn.com/pic/developer-ecology/8d02f8f2e2784362831363770e3ae6fa.png)

## CSI 部署
我們現在來看一下塊儲存的部署情況。

之前提到 CSI 的 Controller 分為兩部分，一個是 Controller Server Pod，一個是 Node Server Pod。

我們只需要部署一個 Controller Server，如果是多備份的，可以部署兩個。Controller Server 主要是透過多個外部外掛來實現的，比如說一個 Pod 中可以定義多個 External 的 Container 和一個包含 CSI Controller Server 的 Container，這時候不同的 External 元件會和 Controller Server 組成不同的功能。

而 Node Server Pod 是個 DaemonSet，它會在每個節點上進行註冊。Kubelet 會直接透過 Socket 的方式直接和 CSI Node Server 進行通訊、呼叫 Attach/Detach/Mount/Unmount 等。

Driver Registrar 只是做一個註冊的功能，會在每個節點上進行部署。

![31.png](https://ucc.alicdn.com/pic/developer-ecology/ef96ad51a5de42d2995e0a8b000ae5cc.png)

檔案儲存和塊儲存的部署情況是類似的。只不過它會把 Attacher 去掉，也沒有 VolumeAttachment 物件。

![32.png](https://ucc.alicdn.com/pic/developer-ecology/9f482d24daa04d2a80ee56ce662faa84.png)

## CSI 使用示例
和 Flexvolume 一樣，我們看一下它的定義模板。

可以看到，它和其它的定義並沒什麼區別。主要的區別在於型別為 CSI，裡面會定義 driver，volumeHandle，volumeAttribute，nodeAffinity 等。

- driver 就是定義是由哪一個外掛來去實現掛載；
- volumeHandle 主要是指示 PV 的唯一標籤；
- volumeAttribute 用於附加引數，比如 PV 如果定義的是 OSS，那麼就可以在 volumeAttribute 定義 bucket、訪問的地址等資訊在裡面；
- nodeAffinity 則可以定義一些排程資訊。與 Flexvolume 類似，還可以透過 selector 和 Label 定義一些繫結條件。

中間的圖給出了一個動態排程的例子，它和其它型別的動態排程是一樣的。只不過在定義 provisioner 的時候指定了一個 CSI 的 provisioner。

![33.png](https://ucc.alicdn.com/pic/developer-ecology/70345fe4428147e6a929248ed402e0cf.png)

下面給出了一個具體的掛載例子。

Pod 啟動之後，我們可以看到 Pod 已經把一個 /dev/vdb 掛載到 /data 上了。同理，它有一個 GlobalPath 和一個 PodPath 的叢集在裡面。我們可以把一個 /dev/vdb 掛載到一個 GlobalPath 裡面，它就是一個 CSI 的一個 PV 在本節點上唯一確定的目錄。一個 PodPath 就是一個 Pod 所確定的一個本地節點的目錄，它會把 Pod 所對應的目錄對映到我們的容器中去。

![34.png](https://ucc.alicdn.com/pic/developer-ecology/726a4f02be694475850a691ee07201ac.png)

## CSI 的其它功能
除了掛載、解除安裝之外，CSI 化提供了一些附加的功能。例如，在定義模板的時候往往需要一些使用者名稱和密碼資訊，此時我們就可透過 **Secret** 來進行定義。之前我們所講的 Flexvolume 也支援這個功能，只不過 CSI 可以根據不同的階段定義不同的 Secret 型別，比如掛載階段的 Secret、Mount 階段的 Secret、Provision 階段的 Secret。

**Topology **是一個拓撲感知的功能。當我們定義一個資料卷的時候，叢集中並不是所有節點都能滿足該資料卷的需求，比如我們需要掛載不同的 zone 的資訊在裡面，這就是一個拓撲感知的功能。這部分在第 10 講已有詳細的介紹，大家可以進行參考。

**Block Volume **就是 volumeMode 的一個定義，它可以定義成 Block 型別，也可以定義成檔案系統型別，CSI 支援 Block 型別的 Volume，就是說掛載到 Pod 內部時，它是一個塊裝置，而不是一個目錄。

**Skip Attach **和 **PodInfo On Mount** 是剛才我們所講過的 CSI Driver 中的兩個功能。

![35.png](https://ucc.alicdn.com/pic/developer-ecology/00d0b04477a64cb2a1e09b5f4f43d672.png)

## CSI 的近期 Features

![36.png](https://ucc.alicdn.com/pic/developer-ecology/916bf4d196714c74981ce2867afff97b.png)

CSI 還是一個比較新的實現方式。近期也有了很多更新，比如 ExpandCSIVolumes 可以實現檔案系統擴容的功能；VolumeSnapshotDataSource 可以實現資料卷的快照功能；VolumePVCDataSource 實現的是可以定義 PVC 的資料來源；我們以前在使用 CSI 的時候只能透過 PVC、PV 的方式定義，而不能直接在 Pod 裡面定義 Volume，CSIInlineVolume 則可以讓我們可以直接在 Volume 中定義一些 CSI 的驅動。

阿里雲在 GitHub 上開源了 [CSI 的實現](https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver)，大家有興趣的可以看一下，做一些參考。

# 四、本文總結

本文主要介紹了 Kubernetes 叢集中儲存卷相關的知識，主要有以下三點內容：

- 第一部分講述了 Kubernetes 儲存架構，主要包括儲存卷概念、掛載流程、系統元件等相關知識；
- 第二部分講述了 Flexvolume 外掛的實現原理、部署架構、使用示例等；
- 第三部分講述了 CSI 外掛的實現原理、資源物件、功能元件、使用示例等；

希望上述知識點能讓各位同學有所收穫，特別是在處理儲存卷相關的設計、開發、故障處理等方面有所幫助。

# 雲原生網路研討會邀您參加

## 網研會議題
Kubernetes SIG-Cloud-Provider-Alibaba 介紹

## 舉辦日期
2020 年 2 月 12 日 10:00（時區：北京）

## 會議語言
中文

## 講師介紹
![3.png](https://ucc.alicdn.com/pic/developer-ecology/03f1ac96d92347419a1d9f5e32260a62.png)

## 議題介紹
SIG Cloud Provider 是 Kubernetes 的重要興趣小組，致力於推動所有云廠商以標準的能力提供 Kubernetes 服務。SIG-Cloud-Provider-Alibaba 是 SIG Cloud Provider 在國內唯一的子專案。

本次研討會將首次完整介紹阿里雲對 Kubernetes 社群的佈局。在產品層面，阿里雲提供了完整的容器產品家族；在開源領域，阿里雲也圍繞 Kubernetes 提供了十個類別，20 多個開源專案，提供了完整的 Kubernetes 生命週期管理。阿里雲會依託 SIG-Cloud-Provider-Alibaba，尋求和開發者更密切的互動，也號召更多的開發者一起貢獻。

## 參會收益

- 透明可控：對於研究性質的開發者，可以基於提供外掛自行搭建 Kubernetes 叢集；對於容器服務 ACK 的使用者，也可以更加透明的瞭解相關實現。 
- 共建協同：對阿里雲上使用 Kubernetes 的計算、網路、儲存等領域有需求的開發者，可以提 Issue 或參與到開源元件開發中一起貢獻，並參與 RoadMap 的制定。 
- 平滑演進：阿里雲 Kubernetes 開源外掛提供了 Day 1 的部署能力，但是對企業的運維、升級、穩定性掌控等提出了更高的要求。如果需要 Day 2 的持續升級、高可用保障、糾錯推薦等專家服務，可以平滑演進到容器服務 ACK。

## 如何參與？
點選註冊報名參會： [https://zoom.com.cn/webinar/register/8015799062779/WN_dIrSRs1zQ-uXNXmuAThuog](https://zoom.com.cn/webinar/register/8015799062779/WN_dIrSRs1zQ-uXNXmuAThuog)

# 招聘

## TL;DR
阿里雲 - 雲原生應用平臺 - 基礎軟體中臺團隊（原容器平臺基礎軟體團隊）誠邀 Kubernetes/容器/ Serverless/應用交付技術領域專家（ P6-P8 ）加盟。

工作年限：建議 P6-7 三年起，P8 五年起，具體看實際能力。 工作地點：

- 國內：北京，杭州，深圳；
- 海外：舊金山灣區、西雅圖

簡歷立刻回覆，2~3 周出結果。節後入職。

## 工作內容
基礎產品事業部是阿里雲智慧事業群的核心研發部門，負責計算、儲存、網路、安全、中介軟體、系統軟體等研發。而云原生應用平臺基礎軟體終態團隊致力於打造穩定、標準、先進的雲原生應用系統平臺，推動行業面向雲原生技術升級與革命。

在這裡，既有 CNCF TOC 和 SIG 聯席主席，也有 etcd 創始人、K8s Operator 創始人與 Kubernetes 核心維護成員組成的、國內最頂尖的 Kubernetes 技術團隊。

在這裡，你將同來自全球的雲原生技術領域專家們（如 Helm 專案的創始人、Istio 專案的創始人）密切合作，在獨一無二的場景與規模中從事 Kubernetes、Service Mesh、Serverless、Open Application Model （ OAM ）等雲端計算生態核心技術的研發與落地工作，在業界標杆級的平臺上，既賦能阿里巴巴全球經濟體，更服務全世界的開發者使用者。

1. 以 Kubernetes 為核心，推動並打造下一代 "以應用為中心" 的基礎技術體系；在阿里經濟體場景中，研發和落地“以應用為中心”的基礎設施架構和基於 Open Application Model （ OAM ）的下一代 NoOps 體系，讓 Kubernetes 與雲原生技術棧發揮出真正的價值和能量；
1. 研發多環境複雜應用交付核心技術；結合阿里與生態中的核心業務場景，打造多環境複雜應用交付的業界標準與核心依賴（對標 Google Cloud Anthos 和 Microsoft Azure Arc ）；
1. 雲原生應用平臺核心產品及後端架構設計與開發工作；在生態核心技術與前沿架構的加持下，在世界級雲廠商的平臺場景中，用技術打造持續的雲產品生命力與競爭力；
1. 持續推動阿里經濟體應用平臺架構演進，包括 Serverless 基礎設施、標準雲原生標準 PaaS 構建、新一代應用交付體系構建等核心技術工作。

技術要求：Go/Rust/Java/C++，Linux，分散式系統

## 簡歷提交

lei.zhang AT [alibaba-inc.com](http://alibaba-inc.com/)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

從零開始入門 K8s | Kubernetes 儲存架構及外掛使用

相關文章