作者 | 阚俊寶 阿裡巴巴進階技術專家
本文整理自《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 步：
- 第一步：使用者建立一個包含 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 的存儲架構。
- 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 的狀态遷移圖。
建立好一個 PV 以後，我們就處于一個 Available 的狀态，當一個 PVC 和一個 PV 綁定的時候，這個 PV 就進入了 Bound 的狀态，此時如果我們把 PVC 删掉，Bound 狀态的 PV 就會進入 Released 的狀态。
一個 Released 狀态的 PV 會根據自己定義的 ReclaimPolicy 字段來決定自己是進入一個 Available 的狀态還是進入一個 Deleted 的狀态。如果 ReclaimPolicy 定義的是 "recycle" 類型，它會進入一個 Available 狀态，如果轉變失敗，就會進入 Failed 的狀态。
相對而言，PVC 的狀态遷移圖就比較簡單。
一個建立好的 PVC 會處于 Pending 狀态，當一個 PVC 與 PV 綁定之後，PVC 就會進入 Bound 的狀态，當一個 Bound 狀态的 PVC 的 PV 被删掉之後，該 PVC 就會進入一個 Lost 的狀态。對于一個 Lost 狀态的 PVC，它的 PV 如果又被重新建立，并且重新與該 PVC 綁定之後，該 PVC 就會重新回到 Bound 狀态。
下圖是一個 PVC 去綁定 PV 時對 PV 篩選的一個流程圖。就是說一個 PVC 去綁定一個 PV 的時候，應該選擇一個什麼樣的 PV 進行綁定。
- 首先它會檢查 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 的狀态遷移。
通過系統标簽 "pv.kubernetes.io/bind-completed" 來辨別一個 PVC 的狀态。
- 如果該标簽為 True，說明我們的 PVC 已經綁定完成，此時我們隻需要去同步一些内部的狀态；
- 如果該标簽為 False，就說明我們的 PVC 處于未綁定狀态。
這個時候就需要檢查整個叢集中的 PV 去進行篩選。通過 findBestMatch 就可以去篩選所有的 PV，也就是按照之前提到的五個綁定條件來進行篩選。如果篩選到 PV，就執行一個 Bound 操作，否則就去做一個 Provision 的操作，自己去建立一個 PV。
再看 VolumeWorker 的操作。它實作的則是 PV 的狀态遷移。
通過 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 期望挂載到哪個節點上、挂載的狀态是什麼樣子的等等。
下圖是 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 的狀态進行更新。
以上就是 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 實作邏輯圖。
我們可以看到，最外層是一個循環，内部則是根據不同的對象，包括 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 中實作的，它會去調用遠端的一個存儲挂載到本地。
從類型上來看，Volume Plugins 可以分為很多種。In-Tree 中就包含了 幾十種常見的存儲實作，但一些公司的自己定義私有類型，有自己的 API 和參數，公共存儲插件是無法支援的，這時就需要 Out-of-Tree 類的存儲實作，比如 CSI、FlexVolume。
Volume Plugins 的具體實作會放到後面去講。這裡主要看一下 Volume Plugins 的插件管理。
Kubernetes會在 PV Controller、AD Controller 以及 Volume Manager 中來做插件管理。通過 VolumePlguinMg 對象進行管理。主要包含 Plugins 和 Prober 兩個資料結構。
Plugins 主要是用來儲存 Plugins 清單的一個對象，而 Prober 是一個探針，用于發現新的 Plugin，比如 FlexVolume、CSI 是擴充的一種插件，它們是動态建立和生成的，是以一開始我們是無法預知的，是以需要一個探針來發現新的 Plugin。
下圖是插件管理的整個過程。
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 進行篩選的。
存儲卷具體排程資訊的實作可以參考《
從零開始入門 K8s | 應用存儲和持久化資料卷：存儲快照與拓撲排程》，這裡會有一個更加詳細的介紹。
二、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"。
下面是一個指令格式和調用的執行個體。
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 的挂載過程。
我們首先看 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 操作，将我們的本地目錄映射到容器中。這樣完成一次挂載過程。
解除安裝流程就是一個逆過程。上述過程描述的是一個塊裝置的挂載過程，對于檔案存儲類型，就無需 Attach、MountDevice操作，隻需要 Mount 操作，是以檔案系統的 Flexvolume 實作較為簡單，隻需要 Mount 和 Unmount 過程即可。
Flexvolume 的代碼示例
其中主要實作的是 init()、doMount()、doUnmount() 方法。在執行該腳本的時候對傳入的參數進行判斷來決定執行哪一個指令。
在 Github 上還有很多 Flexvolume 的示例，大家可以自行參考查閱。阿裡雲提供了一個
Flexvolume 的實作，有興趣的可以參考一下。
Flexvolume 的使用
下圖給出了一個 Flexvolume 類型的 PV 模闆。它和其它模闆實際上沒有什麼差別，隻不過類型被定義為 flexVolume 類型。flexVolume 中定義了 driver、fsType、options。
- driver 定義的是我們實作的某種驅動，比如圖中的是 aliclound/disk，也可以是 aliclound/nas 等；
- fsType 定義的是檔案系統類型，比如 "ext4"；
- options 包含了一些具體的參數，比如定義雲盤的 id 等。
我們也可以像其它類型一樣，通過 selector 中的 matchLabels 定義一些篩選條件。同樣也可以定義一些相應的排程資訊，比如定義 zone 為 cn-shenzhen-a。
下面是一個具體的運作結果。在 Pod 内部我們挂載了一個雲盤，其所在本地裝置為 /dev/vdb。通過 mount | grep disk 我們可以看到相應的挂載目錄，首先它會将 /dev/vdb 挂載到 GlobalPath 中；其次會将 GlobalPath 通過 mount 指令挂載到一個 Pod 所定義的本地子目錄中去；最後會把該本地子目錄映射到 /data 上。
三、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 的具體概念。
下圖給出了 CSI 的接口。主要分為三類：通用管控接口、節點管控接口、中心管控接口。
- 通用管控接口主要傳回 CSI 的一些通用資訊，像插件的名字、Driver 的身份資訊、插件所提供的能力等；
- 節點管控接口的 NodeStageVolume 和 NodeUnstageVolume 就相當于 Flexvolume 中的 MountDevice 和 UnmountDevice。NodePublishVolume 和 NodeUnpublishVolume 就相當于 SetUp 和 TearDown 接口；
- 中心管控接口的 CreateVolume 和 DeleteVolume 就是我們的 Provision 和 Delete 存儲卷的一個接口，ControllerPublishVolume 和 ControllerUnPublishVolume 則分别是 Attach 和 Detach 的接口。
CSI 的系統結構
CSI 是通過 CRD 的形式實作的，是以 CSI 引入了這麼幾個對象類型：VolumeAttachment、CSINode、CSIDriver 以及 CSI Controller Server 與 CSI Node Server 的一個實作。
在 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 組合則可以完成快照的建立和删除。
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 就會執行一個挂載操作。
第二個對象是 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 資訊。
第三個對象是 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。
CSI 元件之 Node-Driver-Registrar
Node-Driver-Registrar 主要實作了 CSI Plugin 注冊的一個機制。我們來看一下下圖中的流程圖。
- 第 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
- 第 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 的資訊在裡面。
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 隻是做一個注冊的功能，會在每個節點上進行部署。
檔案存儲和塊存儲的部署情況是類似的。隻不過它會把 Attacher 去掉，也沒有 VolumeAttachment 對象。
CSI 使用示例
和 Flexvolume 一樣，我們看一下它的定義模闆。
可以看到，它和其它的定義并沒什麼差別。主要的差別在于類型為 CSI，裡面會定義 driver，volumeHandle，volumeAttribute，nodeAffinity 等。
- driver 就是定義是由哪一個插件來去實作挂載；
- volumeHandle 主要是訓示 PV 的唯一标簽；
- volumeAttribute 用于附加參數，比如 PV 如果定義的是 OSS，那麼就可以在 volumeAttribute 定義 bucket、通路的位址等資訊在裡面；
- nodeAffinity 則可以定義一些排程資訊。與 Flexvolume 類似，還可以通過 selector 和 Label 定義一些綁定條件。
中間的圖給出了一個動态排程的例子，它和其它類型的動态排程是一樣的。隻不過在定義 provisioner 的時候指定了一個 CSI 的 provisioner。
下面給出了一個具體的挂載例子。
Pod 啟動之後，我們可以看到 Pod 已經把一個 /dev/vdb 挂載到 /data 上了。同理，它有一個 GlobalPath 和一個 PodPath 的叢集在裡面。我們可以把一個 /dev/vdb 挂載到一個 GlobalPath 裡面，它就是一個 CSI 的一個 PV 在本節點上唯一确定的目錄。一個 PodPath 就是一個 Pod 所确定的一個本地節點的目錄，它會把 Pod 所對應的目錄映射到我們的容器中去。
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 中的兩個功能。
CSI 的近期 Features
CSI 還是一個比較新的實作方式。近期也有了很多更新，比如 ExpandCSIVolumes 可以實作檔案系統擴容的功能；VolumeSnapshotDataSource 可以實作資料卷的快照功能；VolumePVCDataSource 實作的是可以定義 PVC 的資料源；我們以前在使用 CSI 的時候隻能通過 PVC、PV 的方式定義，而不能直接在 Pod 裡面定義 Volume，CSIInlineVolume 則可以讓我們可以直接在 Volume 中定義一些 CSI 的驅動。
阿裡雲在 GitHub 上開源了
CSI 的實作，大家有興趣的可以看一下，做一些參考。
四、本文總結
本文主要介紹了 Kubernetes 叢集中存儲卷相關的知識，主要有以下三點内容：
- 第一部分講述了 Kubernetes 存儲架構，主要包括存儲卷概念、挂載流程、系統元件等相關知識；
- 第二部分講述了 Flexvolume 插件的實作原理、部署架構、使用示例等；
- 第三部分講述了 CSI 插件的實作原理、資源對象、功能元件、使用示例等；
希望上述知識點能讓各位同學有所收獲，特别是在處理存儲卷相關的設計、開發、故障處理等方面有所幫助。
雲原生網絡研讨會邀您參加
網研會議題
Kubernetes SIG-Cloud-Provider-Alibaba 介紹
舉辦日期
2020 年 2 月 12 日 10:00（時區：北京）
會議語言
中文
講師介紹
議題介紹
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招聘
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 ）等雲計算生态核心技術的研發與落地工作，在業界标杆級的平台上，既賦能阿裡巴巴全球經濟體，更服務全世界的開發者使用者。
- 以 Kubernetes 為核心，推動并打造下一代 "以應用為中心" 的基礎技術體系；在阿裡經濟體場景中，研發和落地“以應用為中心”的基礎設施架構和基于 Open Application Model （ OAM ）的下一代 NoOps 體系，讓 Kubernetes 與雲原生技術棧發揮出真正的價值和能量；
- 研發多環境複雜應用傳遞核心技術；結合阿裡與生态中的核心業務場景，打造多環境複雜應用傳遞的業界标準與核心依賴（對标 Google Cloud Anthos 和 Microsoft Azure Arc ）；
- 雲原生應用平台核心産品及後端架構設計與開發工作；在生态核心技術與前沿架構的加持下，在世界級雲廠商的平台場景中，用技術打造持續的雲産品生命力與競争力；
- 持續推動阿裡經濟體應用平台架構演進，包括 Serverless 基礎設施、标準雲原生标準 PaaS 建構、新一代應用傳遞體系建構等核心技術工作。
技術要求：Go/Rust/Java/C++，Linux，分布式系統
履歷送出
lei.zhang AT
alibaba-inc.com“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”