從零開始入門 K8s | 應用儲存和持久化資料卷：核心知識
作者 | 至天 阿里巴巴高階研發工程師
一、Volumes 介紹
Pod Volumes
首先來看一下 Pod Volumes 的使用場景：
- 場景一：如果 pod 中的某一個容器在執行時異常退出，被 kubelet 重新拉起之後，如何保證之前容器產生的重要資料沒有丟失？
- 場景二：如果同一個 pod 中的多個容器想要共享資料，應該如何去做？
以上兩個場景，其實都可以藉助 Volumes 來很好地解決，接下來首先看一下 Pod Volumes 的常見型別：
- 本地儲存，常用的有 emptydir/hostpath；
- 網路儲存：網路儲存當前的實現方式有兩種，一種是 in-tree，它的實現程式碼是放在 K8s 程式碼倉庫中的，隨著 K8s 對儲存型別支援的增多，這種方式會給 K8s 本身的維護和發展帶來很大的負擔；而第二種實現方式是 out-of-tree，它的實現其實是給 K8s 本身解耦的，通過抽象介面將不同儲存的 driver 實現從 K8s 程式碼倉庫中剝離，因此 out-of-tree 是後面社群主推的一種實現網路儲存外掛的方式；
- Projected Volumes：它其實是將一些配置資訊，如 secret/configmap 用卷的形式掛載在容器中，讓容器中的程式可以通過 POSIX 介面來訪問配置資料；
- PV 與 PVC 就是今天要重點介紹的內容。
Persistent Volumes
接下來看一下 PV（Persistent Volumes）。既然已經有了 Pod Volumes，為什麼又要引入 PV 呢？我們知道 pod 中宣告的 volume 生命週期與 pod 是相同的，以下有幾種常見的場景：
- 場景一：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 物件，做到按需分配，在沒有增加使用者使用難度的同時也解放了叢集管理員的運維工作。
二、用例解讀
接下來看一下 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 帶儲存的遷移就是通過這種方式。
三、操作演示
接下來，我會在實際的環境中給大家演示一下，靜態 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 也會被刪除掉。
我們的演示部分就到這裡了。
四、架構設計
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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。