從零開始入門 K8s | 應用存儲和持久化數據卷：核心知識

做者 | 至天 阿里巴巴高級研發工程師

1、Volumes 介紹

Pod Volumes

首先來看一下 Pod Volumes 的使用場景：

• 場景一：若是 pod 中的某一個容器在運行時異常退出，被 kubelet 從新拉起以後，如何保證以前容器產生的重要數據沒有丟失？
• 場景二：若是同一個 pod 中的多個容器想要共享數據，應該如何去作？

以上兩個場景，其實均可以藉助 Volumes 來很好地解決，接下來首先看一下 Pod Volumes 的常見類型：

1. 本地存儲，經常使用的有 emptydir/hostpath；
2. 網絡存儲：網絡存儲當前的實現方式有兩種，一種是 in-tree，它的實現代碼是放在 K8s 代碼倉庫中的，隨着 K8s 對存儲類型支持的增多，這種方式會給 K8s 自己的維護和發展帶來很大的負擔；而第二種實現方式是 out-of-tree，它的實現實際上是給 K8s 自己解耦的，經過抽象接口將不一樣存儲的 driver 實現從 K8s 代碼倉庫中剝離，所以 out-of-tree 是後面社區主推的一種實現網絡存儲插件的方式；
3. Projected Volumes：它實際上是將一些配置信息，如 secret/configmap 用卷的形式掛載在容器中，讓容器中的程序能夠經過 POSIX 接口來訪問配置數據；
4. PV 與 PVC 就是今天要重點介紹的內容。

 

Persistent Volumes

接下來看一下 PV（Persistent Volumes）。既然已經有了 Pod Volumes，爲何又要引入 PV 呢？咱們知道 pod 中聲明的 volume 生命週期與 pod 是相同的，如下有幾種常見的場景：<br />

• 場景一：pod 重建銷燬，如用 Deployment 管理的 pod，在作鏡像升級的過程當中，會產生新的 pod而且刪除舊的 pod ，那新舊 pod 之間如何複用數據？
• 場景二：宿主機宕機的時候，要把上面的 pod 遷移，這個時候 StatefulSet 管理的 pod，其實已經實現了帶卷遷移的語義。這時經過 Pod Volumes 顯然是作不到的；
• 場景三：多個 pod 之間，若是想要共享數據，應該如何去聲明呢？咱們知道，同一個 pod 中多個容器想共享數據，能夠藉助 Pod Volumes 來解決；當多個 pod 想共享數據時，Pod Volumes 就很難去表達這種語義；
• 場景四：若是要想對數據卷作一些功能擴展性，如：snapshot、resize 這些功能，又應該如何去作呢？

以上場景中，經過 Pod Volumes 很難準確地表達它的複用/共享語義，對它的擴展也比較困難。所以 K8s 中又引入了 **Persistent Volumes **概念，它能夠將存儲和計算分離，經過不一樣的組件來管理存儲資源和計算資源，而後解耦 pod 和 Volume 之間生命週期的關聯。這樣，當把 pod 刪除以後，它使用的 PV 仍然存在，還能夠被新建的 pod 複用。

PVC 設計意圖

瞭解 PV 後，應該如何使用它呢？

用戶在使用 PV 時實際上是經過 PVC，爲何有了 PV 又設計了 PVC 呢？主要緣由是爲了簡化 K8s 用戶對存儲的使用方式，作到職責分離。一般用戶在使用存儲的時候，只用聲明所需的存儲大小以及訪問模式。

訪問模式是什麼？其實就是：我要使用的存儲是能夠被多個 node 共享仍是隻能單 node 獨佔訪問(注意是 node level 而不是 pod level)？只讀仍是讀寫訪問？用戶只用關心這些東西，與存儲相關的實現細節是不須要關心的。

經過 PVC 和 PV 的概念，將用戶需求和實現細節解耦開，用戶只用經過 PVC 聲明本身的存儲需求。PV是有集羣管理員和存儲相關團隊來統一運維和管控，這樣的話，就簡化了用戶使用存儲的方式。能夠看到，PV 和 PVC 的設計其實有點像面向對象的接口與實現的關係。用戶在使用功能時，只需關心用戶接口，不需關心它內部複雜的實現細節。

既然 PV 是由集羣管理員統一管控的，接下來就看一下 PV 這個對象是怎麼產生的。

Static Volume Provisioning

第一種產生方式：靜態產生方式 - 靜態 Provisioning。

靜態 Provisioning：由集羣管理員事先去規劃這個集羣中的用戶會怎樣使用存儲，它會先預分配一些存儲，也就是預先建立一些 PV；而後用戶在提交本身的存儲需求（也就是 PVC）的時候，K8s 內部相關組件會幫助它把 PVC 和 PV 作綁定；以後用戶再經過 pod 去使用存儲的時候，就能夠經過 PVC 找到相應的 PV，它就可使用了。

靜態產生方式有什麼不足呢？能夠看到，首先須要集羣管理員預分配，預分配實際上是很難預測用戶真實需求的。舉一個最簡單的例子：若是用戶須要的是 20G，然而集羣管理員在分配的時候可能有 80G 、100G 的，但沒有 20G 的，這樣就很難知足用戶的真實需求，也會形成資源浪費。有沒有更好的方式呢？

Dynamic Volume Provisioning

第二種訪問方式：動態 Dynamic Provisioning。

動態供給是什麼意思呢？就是說如今集羣管理員不預分配 PV，他寫了一個模板文件，這個模板文件是用來表示建立某一類型存儲（塊存儲，文件存儲等）所需的一些參數，這些參數是用戶不關心的，給存儲自己實現有關的參數。用戶只須要提交自身的存儲需求，也就是 PVC 文件，並在 PVC 中指定使用的存儲模板（StorageClass）。

K8s 集羣中的管控組件，會結合 PVC 和 StorageClass 的信息動態，生成用戶所須要的存儲（PV），將 PVC 和 PV 進行綁定後，pod 就可使用 PV 了。經過 StorageClass 配置生成存儲所須要的存儲模板，再結合用戶的需求動態建立 PV 對象，作到按需分配，在沒有增長用戶使用難度的同時也解放了集羣管理員的運維工做。

2、用例解讀

接下來看一下 Pod Volumes、PV、PVC 及 StorageClass 具體是如何使用的。

Pod Volumes 的使用

首先來看一下 Pod Volumes 的使用。如上圖左側所示，咱們能夠在 pod yaml 文件中的 Volumes 字段中，聲明咱們卷的名字以及卷的類型。聲明的兩個卷，一個是用的是 emptyDir，另一個用的是 hostPath，這兩種都是本地卷。在容器中應該怎麼去使用這個卷呢？它其實能夠經過 volumeMounts 這個字段，volumeMounts 字段裏面指定的 name 其實就是它使用的哪一個卷，mountPath 就是容器中的掛載路徑。

這裏還有個 subPath，subPath 是什麼？

先看一下，這兩個容器都指定使用了同一個卷，就是這個 cache-volume。那麼，在多個容器共享同一個卷的時候，爲了隔離數據，咱們能夠經過 subPath 來完成這個操做。它會在卷裏面創建兩個子目錄，而後容器 1 往 cache 下面寫的數據其實都寫在子目錄 cache1 了，容器 2 往 cache 寫的目錄，其數據最終會落在這個卷裏子目錄下面的 cache2 下。

還有一個 readOnly 字段，readOnly 的意思其實就是隻讀掛載，這個掛載你往掛載點下面其實是沒有辦法去寫數據的。

另外 emptyDir、hostPath 都是本地存儲，它們之間有什麼細微的差異呢？emptyDir 實際上是在 pod 建立的過程當中會臨時建立的一個目錄，這個目錄隨着 pod 刪除也會被刪除，裏面的數據會被清空掉；hostPath 顧名思義，其實就是宿主機上的一個路徑，在 pod 刪除以後，這個目錄仍是存在的，它的數據也不會被丟失。這就是它們二者之間一個細微的差異。

靜態 PV 使用

接下來再看一下，PV 和 PVC 是怎麼使用的。

先看一個靜態 PV 建立方式。靜態 PV 的話，首先是由管理員來建立的，管理員咱們這裏以 NAS，就是阿里雲文件存儲爲例。我須要先在阿里雲的文件存儲控制檯上去建立 NAS 存儲，而後把 NAS 存儲的相關信息要填到 PV 對象中，這個 PV 對象預建立出來後，用戶能夠經過 PVC 來聲明本身的存儲需求，而後再去建立 pod。建立 pod 仍是經過咱們剛纔講解的字段把存儲掛載到某一個容器中的某一個掛載點下面。

那麼接下來看一下 yaml 怎麼寫。集羣管理員首先是在雲存儲廠商那邊先去把存儲建立出來，而後把相應的信息填寫到 PV 對象中。

剛剛建立的阿里雲 NAS 文件存儲對應的 PV，有個比較重要的字段：capacity，即建立的這個存儲的大小，accessModes，建立出來的這個存儲它的訪問方式，咱們後面會講解總共有幾種訪問方式。

而後有個 ReclaimPolicy，ReclaimPolicy 的意思就是：這塊存儲在被使用後，等它的使用方 pod 以及 PVC 被刪除以後，這個 PV 是應該被刪掉仍是被保留呢？其實就是 PV 的回收策略。

接下來看看用戶怎麼去使用該 PV 對象。用戶在使用存儲的時候，須要先建立一個 PVC 對象。PVC 對象裏面，只須要指定存儲需求，不用關心存儲自己的具體實現細節。存儲需求包括哪些呢？首先是須要的大小，也就是 resources.requests.storage；而後是它的訪問方式，即須要這個存儲的訪問方式，這裏聲明爲 ReadWriteMany，也即支持多 node 讀寫訪問，這也是文件存儲的典型特性。

上圖中左側，能夠看到這個聲明：它的 size 和它的access mode，跟咱們剛纔靜態建立這塊 PV 實際上是匹配的。這樣的話，當用戶在提交 PVC 的時候，K8s 集羣相關的組件就會把 PV 的 PVC bound 到一塊兒。以後，用戶在提交 pod yaml 的時候，能夠在卷裏面寫上 PVC 聲明，在 PVC 聲明裏面能夠經過 claimName 來聲明要用哪一個 PVC。這時，掛載方式其實跟前面講的同樣，當提交完 yaml 的時候，它能夠經過 PVC 找到 bound 着的那個 PV，而後就能夠用那塊存儲了。這是靜態 Provisioning 到被 pod 使用的一個過程。

動態 PV 使用

而後再看一下動態 Provisioning。動態 Provisioning 上面提到過，系統管理員再也不預分配 PV，而只是建立一個模板文件。

這個模板文件叫 StorageClass，在 StorageClass 裏面，咱們須要填的重要信息：第一個是 provisioner，provisioner 是什麼？它其實就是說我當時建立 PV 和對應的存儲的時候，應該用哪一個存儲插件來去建立。

這些參數是經過 K8s 建立存儲的時候，須要指定的一些細節參數。對於這些參數，用戶是不須要關心的，像這裏 regionld、zoneld、fsType 和它的類型。ReclaimPolicy 跟咱們剛纔講解的 PV 裏的意思是同樣的，就是說動態建立出來的這塊 PV,當使用方使用結束、Pod 及 PVC 被刪除後，這塊 PV 應該怎麼處理，咱們這個地方寫的是 delete，意思就是說當使用方 pod 和 PVC 被刪除以後，這個 PV 也會被刪除掉。

接下來看一下，集羣管理員提交完 StorageClass，也就是提交建立 PV 的模板以後，用戶怎麼用，首先仍是須要寫一個 PVC 的文件。

PVC 的文件裏存儲的大小、訪問模式是不變的。如今須要新加一個字段，叫 StorageClassName，它的意思是指定動態建立 PV 的模板文件的名字，這裏 StorageClassName 填的就是上面聲明的 csi-disk。

在提交完 PVC以後，K8s 集羣中的相關組件就會根據 PVC 以及對應的 StorageClass 動態生成這塊 PV 給這個 PVC 作一個綁定，以後用戶在提交本身的 yaml 時，用法和接下來的流程和前面的靜態使用方式是同樣的，經過 PVC 找到咱們動態建立的 PV，而後把它掛載到相應的容器中就可使用了。

PV Spec 重要字段解析

接下來，咱們講解一下 PV 的一些重要字段：

• Capacity：這個很好理解，就是存儲對象的大小；
• **AccessModes：**也是用戶須要關心的，就是說我使用這個 PV 的方式。它有三種使用方式。
  • 一種是單 node 讀寫訪問；
  • 第二種是多個 node 只讀訪問，是常見的一種數據的共享方式；
  • 第三種是多個 node 上讀寫訪問。

用戶在提交 PVC 的時候，最重要的兩個字段 —— Capacity 和 AccessModes。在提交 PVC後，K8s 集羣中的相關組件是如何去找到合適的 PV 呢？首先它是經過爲 PV 創建的 AccessModes 索引找到全部可以知足用戶的 PVC 裏面的 AccessModes 要求的 PV list，而後根據 PVC 的 Capacity，StorageClassName, Label Selector 進一步篩選 PV，若是知足條件的 PV 有多個，選擇 PV 的 size 最小的，accessmodes 列表最短的 PV，也即最小適合原則。

• ReclaimPolicy：這個就是剛纔提到的，個人用戶方 PV 的 PVC 在刪除以後，個人 PV 應該作如何處理？常見的有三種方式。
  • 第一種方式咱們就不說了，如今 K8s 中已經不推薦使用了；
  • 第二種方式 delete，也就是說 PVC 被刪除以後，PV 也會被刪除；
  • 第三種方式 Retain，就是保留，保留以後，後面這個 PV 須要管理員來手動處理；
• StorageClassName：StorageClassName 這個咱們剛纔說了，咱們動態 Provisioning 時必須指定的一個字段，就是說咱們要指定到底用哪個模板文件來生成 PV ；
• NodeAffinity：就是說我建立出來的 PV，它能被哪些 node 去掛載使用，實際上是有限制的。而後經過 NodeAffinity 來聲明對node的限制，這樣其實對 使用該 PV 的 pod 調度也有限制，就是說 pod 必需要調度到這些能訪問 PV 的 node 上，才能使用這塊 PV，這個字段在咱們下一講講解存儲拓撲調度時在細說。

PV 狀態流轉

接下來咱們看一下 PV 的狀態流轉。首先在建立 PV 對象後，它會處在短暫的pending 狀態；等真正的 PV 建立好以後，它就處在 available 狀態。

available 狀態意思就是可使用的狀態，用戶在提交 PVC 以後，被 K8s 相關組件作完 bound（即：找到相應的 PV），這個時候 PV 和 PVC 就結合到一塊兒了，此時二者都處在 bound 狀態。當用戶在使用完 PVC，將其刪除後，這個 PV 就處在 released 狀態，以後它應該被刪除仍是被保留呢？這個就會依賴咱們剛纔說的 ReclaimPolicy。

這裏有一個點須要特別說明一下：當 PV 已經處在 released 狀態下，它是沒有辦法直接回到 available 狀態，也就是說接下來沒法被一個新的 PVC 去作綁定。若是咱們想把已經 released 的 PV 複用，咱們這個時候一般應該怎麼去作呢？

第一種方式：咱們能夠新建一個 PV 對象，而後把以前的 released 的 PV 的相關字段的信息填到新的 PV 對象裏面，這樣的話，這個 PV 就能夠結合新的 PVC 了；第二種是咱們在刪除 pod 以後，不要去刪除 PVC 對象，這樣給 PV 綁定的 PVC 仍是存在的，下次 pod 使用的時候，就能夠直接經過 PVC 去複用。K8s 中的 StatefulSet 管理的 Pod 帶存儲的遷移就是經過這種方式。

3、操做演示

接下來，我會在實際的環境中給你們演示一下，靜態 Provisioning 以及動態 Provisioning 具體操做方式。

靜態 Provisioning 例子

靜態 Provisioning 主要用的是阿里雲的 NAS 文件存儲；動態 Provisioning 主要用了阿里雲的雲盤。它們須要相應存儲插件，插件我已經提早部署在個人 K8s 集羣中了(csi-nasplugin* 是爲了在 K8s 中使用阿里雲 NAS 所需的插件，csi-disk *是爲了在 K8s 中使用阿里云云盤所須要的插件)。

咱們接下來先看一下靜態 Provisioning 的 PV 的 yaml 文件。

volumeAttributes 是我在阿里雲 nas 控制檯預先建立的 NAS 文件系統的相關信息，咱們主要須要關心的有 capacity 爲 5Gi; accessModes 爲多 node 讀寫訪問; reclaimPolicy：Retain，也就是當我使用方的 PVC 被刪除以後，我這個 PV 是要保留下來的；以及在使用這個卷的過程當中使用的 driver。

而後咱們把對應的 PV 建立出來：

咱們看一下上圖 PV 的狀態，已經處在 Available，也就是說它已經能夠被使用了。

再建立出來 nas-pvc：

咱們看這個時候 PVC 已經新建立出來了，並且也已經和咱們上面建立的 PV 綁定到一塊兒了。咱們看一下 PVC 的 yaml 裏面寫的什麼。

其實很簡單 ，就是我須要的大小以及我須要的 accessModes。提交完以後，它就與咱們集羣中已經存在的 PV 作匹配，匹配成功以後，它就會作 bound。

接下來咱們去建立使用 nas-fs 的 pod：

上圖看到，這兩個 Pod 都已經處在 running 狀態了。

咱們先看一下這個 pod yaml：

pod yaml 裏面聲明瞭剛纔咱們建立出來的 PVC 對象，而後把它掛載到 nas-container 容器中的 /data 下面。咱們這個 pod 是經過 deployment 建立兩個副本，經過反親和性，將兩個副本調度在不一樣的 node 上面。

上圖咱們能夠看一下，兩個 Pod 所在的宿主機是不同的。

以下圖所示：咱們登錄到第一個上面，findmnt 看一下它的掛載信息，這個其實就掛載在我聲明的 nas-fs 上，那咱們再在下面 touch 個 test.test.test 文件，咱們也會登錄到另一個容器，看一下它有沒有被共享。

咱們退出再登錄另一個 pod（剛纔登錄的是第一個，如今登錄第二個）。

以下圖所示：咱們也 findmnt 一下，能夠看到，這兩個 pod 的遠程掛載路徑同樣，也就是說咱們用的是同一個 NAS PV，咱們再看一下剛纔建立出來的那個是否存在。

能夠看到，這個也是存在的，就說明這兩個運行在不一樣node上的 pod 共享了同一個 nas 存儲。

接下來咱們看一下把兩個 pod 刪掉以後的狀況。先刪 Pod，接着再刪一下對應的 PVC(K8s 內部對 pvc 對象由保護機制，在刪除 pvc 對象時若是發現有 pod 在使用 pvc，pvc 是刪除不掉的)，這個可能要稍等一下。

看一下下圖對應的 PVC 是否是已經被刪掉了。

上圖顯示，它已經被刪掉了。再看一下，剛纔的 nas PV 仍是在的，它的狀態是處在 Released 狀態，也就是說剛纔使用它的 PVC 已經被刪掉了，而後它被 released 了。又由於咱們 RECLAIN POLICY 是 Retain，因此它這個 PV 是被保留下來的。

動態 Provisioning 例子

接下來咱們來看第二個例子，動態 Provisioning 的例子。咱們先把保留下來的 PV 手動刪掉，能夠看到集羣中沒有 PV了。接下來演示一下動態 Provisioning。

首先，先去建立一個生成 PV 的模板文件，也就是 storageclass。看一下 storageclass 裏面的內容，其實很簡單。

如上圖所示，我事先指定的是我要建立存儲的卷插件(阿里云云盤插件，由阿里雲團隊開發)，這個咱們已經提早部署好了；咱們能夠看到，parameters部分是建立存儲所須要的一些參數，可是用戶不須要關心這些信息；而後是 reclaimPolicy，也就是說經過這個 storageclass 建立出來的 PV 在給綁定到一塊兒的 PVC 刪除以後，它是要保留仍是要刪除。

如上圖所示：如今這個集羣中是沒有 PV 的，咱們動態提交一個 PVC 文件，先看一下它的 PVC 文件。它的 accessModes-ReadWriteOnce (由於阿里云云盤其實只能是單 node 讀寫的，因此咱們聲明這樣的方式），它的存儲大小需求是 30G，它的 storageClassName 是 csi-disk，就是咱們剛纔建立的 storageclass，也就是說它指定要經過這個模板去生成 PV。

這個 PVC 此時正處在 pending 狀態，這就說明它對應的 PV 還在建立過程當中。

稍過一會，咱們看到已經有一個新的 PV 生成，這個 PV 其實就是根據咱們提交的 PVC 以及 PVC 裏面指定的storageclass 動態生成的。以後 K8s 會將生成的 PV 以及咱們提交的 PVC，就是這個 disk PVC 作綁定，以後咱們就能夠經過建立 pod 來使用了。

再看一下 pod yaml：

pod yaml 很簡單，也是經過 PVC 聲明，代表使用這個 PVC。而後是掛載點，下面咱們能夠建立看一下。

以下圖所示：咱們能夠大概看一下 Events，首先被調度器調度，調度完以後，接下來會有個 attachdetach controller，它會去作 disk 的 attach 操做，就是把咱們對應的 PV 掛載到調度器調度的 node 上，而後Pod對應的容器才能啓動，啓動容器才能使用對應的盤。

接下來我會把 PVC 刪掉，看一下 PV 會不會根據咱們的 reclaimPolicy 隨之刪掉呢？咱們先看一下，這個時候 PVC 仍是存在的，對應的 PV 也是存在的。

而後刪一下 PVC，刪完以後再看一下：咱們的 PV 也被刪了，也就是說根據 reclaimPolicy，咱們在刪除 PVC 的同時，PV 也會被刪除掉。

咱們的演示部分就到這裏了。

4、架構設計

PV 和 PVC 的處理流程

咱們接下來看一下 K8s 中的 PV 和 PVC 體系的完整處理流程。我首先看一下這張圖的右下部分裏面提到的 csi。

csi 是什麼？csi 的全稱是 container storage interface，它是 K8s 社區後面對存儲插件實現 ( out of tree ) 的官方推薦方式。csi 的實現大致能夠分爲兩部分：

• 第一部分是由 k8s 社區驅動實現的通用的部分，像咱們這張圖中的 csi-provisioner和 csi-attacher controller；
• 另一種是由雲存儲廠商實踐的，對接雲存儲廠商的 OpenApi，主要是實現真正的 create/delete/mount/unmount 存儲的相關操做，對應到上圖中的 csi-controller-server 和 csi-node-server。

接下來看一下，當用戶提交 yaml 以後，k8s 內部的處理流程。用戶在提交 PVCyaml 的時候，首先會在集羣中生成一個 PVC 對象，而後 PVC 對象會被 csi-provisioner controller watch 到，csi-provisioner 會結合 PVC 對象以及 PVC 對象中聲明的 storageClass，經過 GRPC 調用 csi-controller-server，而後，到雲存儲服務這邊去建立真正的存儲，並最終建立出來 PV 對象。最後，由集羣中的 PV controller 將 PVC 和 PV 對象作 bound 以後，這個 PV 就能夠被使用了。

用戶在提交 pod 以後，首先會被調度器調度選中某一個合適的node，以後該 node 上面的 kubelet 在建立 pod 流程中會經過首先 csi-node-server 將咱們以前建立的 PV 掛載到咱們 pod 可使用的路徑，而後 kubelet 開始 create && start pod 中的全部 container。

PV、PVC 以及經過 csi 使用存儲流程

咱們接下來經過另外一張圖來更加詳細看一下咱們 PV、PVC 以及經過 CSI 使用存儲的完整流程。

主要分爲三個階段：

• 第一個階段(Create 階段)是用戶提交完 PVC，由 csi-provisioner 建立存儲，並生成 PV 對象，以後 PV controller 將 PVC 及生成的 PV 對象作 bound，bound 以後，create 階段就完成了；
• 以後用戶在提交 pod yaml 的時候，首先會被調度選中某一個合適的 node，等 pod 的運行 node 被選出來以後，會被 AD Controller watch 到 pod 選中的 node，它會去查找 pod 中使用了哪些 PV。而後它會生成一個內部的對象叫 VolumeAttachment 對象，從而去觸發 csi-attacher去調用 csi-controller-server 去作真正的 attache 操做，attach 操做調到雲存儲廠商 OpenAPI。這個 attach 操做就是將存儲 attach到 pod 將會運行的 node 上面。第二個階段 —— attach 階段完成；
• 而後咱們接下來看第三個階段。第三個階段發生在 kubelet 建立 pod 的過程當中，它在建立 pod 的過程當中，首先要去作一個 mount，這裏的 mount 操做是爲了將已經 attach 到這個 node 上面那塊盤，進一步 mount 到 pod 可使用的一個具體路徑，以後 kubelet 纔開始建立並啓動容器。這就是 PV 加 PVC 建立存儲以及使用存儲的第三個階段 —— mount 階段。

總的來講，有三個階段：第一個 create 階段，主要是建立存儲；第二個 attach 階段，就是將那塊存儲掛載到 node 上面(一般爲將存儲 load 到 node 的 /dev 下面)；第三個 mount 階段，將對應的存儲進一步掛載到 pod 可使用的路徑。這就是咱們的 PVC、PV、已經經過 CSI 實現的卷從建立到使用的完整流程。

本文總結

本文內容就到此爲止了，這裏爲你們簡單總結一下：

• 介紹了 K8s Volume 的使用場景，以及自己侷限性；
• 經過介紹 K8s 的 PVC 和 PV 體系，說明 K8s 經過 PVC 和 PV 體系加強了 K8s Volumes 在多 Pod 共享/遷移/存儲擴展等場景下的能力的必要性以及設計思想；
• 經過介紹 PV（存儲）的不一樣供給模式 (static and dynamic)，學習瞭如何經過不一樣方式爲集羣中的 Pod 供給所需的存儲；
• 經過 PVC&PV 在 K8s 中完整的處理流程，深刻理解 PVC&PV 的工做原理 。

阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。