Kubernetes 3 種儲存傻傻分不清楚

摘要： Kubernetes支援幾十種類型的後端儲存卷，其中有幾種儲存卷總是給人一種分不清楚它們之間有什麼區別的感覺，尤其是local與hostPath這兩種儲存卷型別，看上去都像是node本地儲存方案嘛。當然，還另有一種volume型別是emptyDir，也有相近之處。 在Docker...

Kubernetes支援幾十種類型的後端儲存卷，其中有幾種儲存卷總是給人一種分不清楚它們之間有什麼區別的感覺，尤其是local與hostPath這兩種儲存卷型別，看上去都像是node本地儲存方案嘛。當然，還另有一種volume型別是emptyDir，也有相近之處。

在Docker容器時代，我們就對Volume很熟悉了，一般來說我們是通過建立Volume資料卷，然後掛載到指定容器的指定路徑下，以實現容器資料的持久化儲存或者是多容器間的資料共享，當然這裡說的都是單機版的容器解決方案。

進入到容器叢集時代後，我們看到Kubernetes按時間順序先後提供了emptyDir、hostPath和local的本地磁碟儲存卷解決方案。

emptyDir、hostPath都是Kubernetes很早就實現和支援了的技術，local volume方式則是從k8s v1.7才剛剛釋出的alpha版本，目前在k8s v1.10中釋出了local volume的beta版本，部分功能在早期版本中並不支援。

在展開之前，我們先討論一個問題，就是既然都已經實現容器雲平臺了，我們為什麼還要關注這幾款本地儲存卷的貨呢？

粗略歸納了下，有以下幾個原因：

• 特殊使用場景需求，如需要個臨時儲存空間，執行cAdvisor需要能訪問到node節點/sys/fs/cgroup的資料，做本機單節點的k8s環境功能測試等等。

• 容器叢集只是做小規模部署，滿足開發測試、整合測試需求。

• 作為分散式儲存服務的一種補充手段，比如我在一臺node主機上插了塊SSD，準備給某個容器吃小灶。

• 目前主流的兩個容器叢集儲存解決方案是ceph和glusterfs，二者都是典型的網路分散式儲存，所有的資料讀、寫都是對磁碟IO和網路IO的考驗，所以部署儲存叢集時至少要使用萬兆的光纖網絡卡和光纖交換機。如果你都沒有這些硬貨的話，強上分散式儲存方案的結果就是收穫一個以”慢動作”見長的容器叢集啦。

• 分散式儲存叢集服務的規劃、部署和長期的監控、擴容與執行維護是專業性很強的工作，需要有專職的技術人員做長期的技術建設投入。

我們並不是說分散式儲存服務不好，很多公司在雲平臺建設的實踐中，往往是需要結合使用幾種通用的與專用的儲存解決方案，才能最終滿足大部分的使用需求。

所以，如果這裡有一款場景適合你的話，不妨瞭解一下這幾款本地儲存卷的功能特點、使用技巧與異同。

1、emptyDir

emptyDir型別的Volume在Pod分配到Node上時被建立，Kubernetes會在Node上自動分配一個目錄，因此無需指定宿主機Node上對應的目錄檔案。 這個目錄的初始內容為空，當Pod從Node上移除時，emptyDir中的資料會被永久刪除。

注：容器的crashing事件並不會導致emptyDir中的資料被刪除。

最佳實踐

根據官方給出的最佳使用實踐的建議，emptyDir可以在以下幾種場景下使用：

檢視下創建出來的pod，這裡只截取了與volume有關的部分，其他無關內容直接省略：

可以進入到容器中檢視下實際的卷掛載結果：

2、hostPath

hostPath型別則是對映node檔案系統中的檔案或者目錄到pod裡。在使用hostPath型別的儲存卷時，也可以設定type欄位，支援的型別有檔案、目錄、File、Socket、CharDevice和BlockDevice。

下面是來自官網對hostPath的使用場景和注意事項的介紹。

使用場景：

• 當執行的容器需要訪問Docker內部結構時，如使用hostPath對映/var/lib/docker到容器；

• 當在容器中執行cAdvisor時，可以使用hostPath對映/dev/cgroups到容器中；

注意事項：

• 配置相同的pod（如通過podTemplate建立），可能在不同的Node上表現不同，因為不同節點上對映的檔案內容不同

• 當Kubernetes增加了資源敏感的排程程式，hostPath使用的資源不會被計算在內

• 宿主機下建立的目錄只有root有寫許可權。你需要讓你的程式執行在privileged container上，或者修改宿主機上的檔案許可權。

hostPath volume 實驗

下面我們在測試k8s環境中建立一個hostPath volume使用示例。

檢視下pod建立結果，觀察volumes部分：

我們登入到容器中，進入掛載的/test-data目錄中，建立個測試檔案。

我們在執行該pod的node節點上，可以看到如下的檔案和內容。

現在，我們把該pod刪除掉，再看看node節點上的hostPath使用的目錄與資料會有什麼變化。

到執行原pod的node節點上檢視如下。

在使用hostPath volume卷時，即便pod已經被刪除了，volume卷中的資料還在！

單節點的k8s本地測試環境與hostPath volume

有時我們需要搭建一個單節點的k8s測試環境，就利用到hostPath作為後端的儲存卷，模擬真實環境提供PV、StorageClass和PVC的管理功能支援。

該場景僅能用於單節點的k8s測試環境中

3、emptyDir和hostPath在功能上的異同分析

二者都是node節點的本地儲存卷方式；

• emptyDir可以選擇把資料存到tmpfs型別的本地檔案系統中去，hostPath並不支援這一點；

• hostPath除了支援掛載目錄外，還支援File、Socket、CharDevice和BlockDevice，既支援把已有的檔案和目錄掛載到容器中，也提供了“如果檔案或目錄不存在，就建立一個”的功能；

• emptyDir是臨時儲存空間，完全不提供持久化支援；

• hostPath的卷資料是持久化在node節點的檔案系統中的，即便pod已經被刪除了，volume卷中的資料還會留存在node節點上；

4、local volume的概念

這是一個很新的儲存型別，建議在k8s v1.10+以上的版本中使用。該local volume型別目前還只是beta版。

Local volume 允許使用者通過標準PVC介面以簡單且可移植的方式訪問node節點的本地儲存。 PV的定義中需要包含描述節點親和性的資訊，k8s系統則使用該資訊將容器排程到正確的node節點。

配置要求

• 使用local-volume外掛時，要求使用到了儲存裝置名或路徑都相對固定，不會隨著系統重啟或增加、減少磁碟而發生變化。

• 靜態provisioner配置程式僅支援發現和管理掛載點（對於Filesystem模式儲存卷）或符號連結（對於塊裝置模式儲存卷）。 對於基於本地目錄的儲存卷，必須將它們通過bind-mounted的方式繫結到發現目錄中。

StorageClass與延遲繫結

官方推薦在使用local volumes時，建立一個StorageClass並把volumeBindingMode欄位設定為“WaitForFirstConsumer”。

雖然local volumes還不支援動態的provisioning管理功能，但我們仍然可以建立一個StorageClass並使用延遲卷繫結的功能，將volume binding延遲至pod scheduling階段執行。

這樣可以確保PersistentVolumeClaim繫結策略將Pod可能具有的任何其他node節點約束也進行評估，例如節點資源要求、節點選擇器、Pod親和性和Pod反親和性。

外部static provisioner

配置local volume後，可以使用一個外部的靜態配置器來幫助簡化本地儲存的管理。 Provisioner 配置程式將通過為每個卷建立和清理PersistentVolumes來管理髮現目錄下的卷。

Local storage provisioner要求管理員在每個節點上預配置好local volumes，並指明該local volume是屬於以下哪種型別：

• Filesystem volumeMode (default) PVs – 需要掛載到發現目錄下面。

• Block volumeMode PVs – 需要在發現目錄下建立一個指向節點上的塊裝置的符號連結。

一個local volume，可以是掛載到node本地的磁碟、磁碟分割槽或目錄。

Local volumes雖然可以支援建立靜態PersistentVolume，但到目前為止仍不支援動態的PV資源管理。

這意味著，你需要自己手動去處理部分PV管理的工作，但考慮到至少省去了在建立pod時手動定義和使用PV的工作，這個功能還是很值得的。

建立基於Local volumes的PV的示例

• nodeAffinity欄位是必須配置的，k8s依賴於這個標籤為你定義的Pods在正確的nodes節點上找到需要使用的local volumes。

• 使用volumeMode欄位時，需要啟用BlockVolume 這一Alpha feature特性。

• volumeMode欄位的預設值是Filesystem，但也支援配置為Block，這樣就會把node節點的local volume作為容器的一個裸塊裝置掛載使用。

資料安全風險

local volume仍受node節點可用性方面的限制，因此並不適用於所有應用程式。 如果node節點變得不健康，則local volume也將變得不可訪問，使用這個local volume的Pod也將無法執行。 使用local voluems的應用程式必須能夠容忍這種降低的可用性以及潛在的資料丟失，是否會真得導致這個後果將取決於node節點底層磁碟儲存與資料保護的具體實現了。

5、hostPath與local volume在功能上的異同分析

二者都基於node節點本地儲存資源實現了容器內資料的持久化功能，都為某些特殊場景下提供了更為適用的儲存解決方案；

前者時間很久了，所以功能穩定，而後者因為年輕，所以功能的可靠性與穩定性還需要經歷時間和案例的歷練，尤其是對Block裝置的支援還只是alpha版本；

二者都為k8s儲存管理提供了PV、PVC和StorageClass的方法實現；

• local volume實現的StorageClass不具備完整功能，目前只支援卷的延遲繫結；

• hostPath是單節點的本地儲存卷方案，不提供任何基於node節點親和性的pod排程管理支援；

• local volume適用於小規模的、多節點的k8s開發或測試環境，尤其是在不具備一套安全、可靠且效能有保證的儲存叢集服務時；

6、local volume的安裝配置方法

local-volume專案及地址

https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume

Step 1：配置k8s叢集使用本地磁碟儲存

如果使用block塊裝置，則需要啟用Alpha的功能特性：k8s v1.10+

注：如果是已經部署好的k8s v1.10+叢集，需要為幾個主要元件均開啟對該特性的支援後，才能使用block塊裝置功能。如果k8s是低於1.10版本，則還需要啟用其它的幾個功能特性，因為在低版本中這些功能特性還都是alpha版本的。

根據大家搭建k8s的方法的不同，下面提供了四種情況下的配置說明。

使用kube-up.sh啟動的GCE叢集將自動格式化並掛載所請求的Local SSDs，因此您可以使用預先生成的部署規範部署配置器並跳至步驟4，除非您要自定義配置器規範或儲存類。

Option 2: GKE（Google Kubernetes Engine）叢集

GKE叢集將自動格式化並掛載所請求的Local SSDs。在GKE documentation中有更詳細的說明。

然後，跳至步驟4。

Option 3: 使用裸機環境搭建的叢集

1.根據應用程式的使用要求對每個節點上的本地資料磁碟進行分割槽和格式化。 2.定義一個StorageClass，並在一個發現目錄下掛載所有要使用的儲存檔案系統。 發現目錄是在configmap中指定，見下文。 3.如上所述，使用KUBE FEATURE GATES配置Kubernetes API Server, controller-manager, scheduler, 和所有節點上的 kubelets。 4.如果沒有使用預設的Kubernetes排程程式策略，則必須啟用以下特性：

• Pre-1.9: NoVolumeBindConflict

• 9+: VolumeBindingChecker

說明：在我們使用測試環境中，是一套3節點的k8s測試環境，為了模擬測試local volume功能，直接結合使用了下面option4中提供的ram disks測試方法，建立了3個tmpfs格式的檔案系統掛載資源。

Option 4: 使用一個本機單節點的測試叢集

建立/mnt/disks目錄，並在該目錄下掛載幾個子目錄。下面是使用三個ram disks做一個真實儲存卷的模擬測試。

(2)建立單機k8s本地測試叢集

Step 2: 建立一個StorageClass (1.9+)

要延遲卷繫結直到pod排程並處理單個pod中的多個本地PV，必須建立StorageClass並將volumeBindingMode設定為WaitForFirstConsumer。

yaml檔案請到local volume專案檔案中查詢需要使用的yaml檔案

Step 3: 建立local persistent volumes

Option 1: local volume static provisioner 方式

配置一個外部的靜態配置器。

（1）生成Provisioner的ServiceAccount，Roles，DaemonSet和ConfigMap規範，並對其進行自定義配置。

此步驟使用helm模板生成需要的配置規格。 有關設定說明，請參閱helm README。

使用預設值生成Provisioner的配置規格，請執行：

helm template ./helm/provisioner > ./provisioner/deployment/kubernetes/provisioner_generated.yaml

這裡是將模板經過渲染後得到最終使用的各項資源定義檔案。 如果是使用自定義的配置檔案的話：

（2）部署Provisioner

如果使用者對Provisioner的yaml檔案的內容感到滿意，就可以使用kubectl建立Provisioner的DaemonSet和ConfigMap了。

（3）檢查已自動發現的local volumes

一旦啟動，外部static provisioner將發現並自動創建出 local-volume PVs。

我們檢視下上面測試中創建出的PVs有哪些：

因為是有3個node節點，每個上面的/mnt/fast-disks自動發現目錄下掛載了3個檔案系統，所以這裡查詢的結果是生成了9個PVs

檢視某一個PV的詳細描述資訊：

此時就可以直接通過引用名為fast-disks的storageClassName名稱來宣告使用上述PV並將其繫結到PVC。

Option 2: 手動建立 local persistent volume

參照前文介紹local volume概念的章節中已經講解過的PersistentVolume使用示例。

Step 4: 建立 local persistent volume claim

請在使用時替換為您實際的儲存容量需求和storageClassName值。

Normal WaitForFirstConsumer 6s (x6 over 59s) persistentvolume-controller waiting for first consumer to be created before binding

我們可以看到儲存卷延遲繫結的效果，在繫結到容器前，該PVC的狀態會是pending

Step 5：建立一個測試Pod並引用上面建立的PVC

建立並檢視：

檢視pod中容器掛載PVC的配置詳情，這裡只截取了部分資訊：

再回過頭來看下PVC的狀態，已經變成了Bound：

7、一個關於local volume功能侷限性問題的討論

在上面的實驗過程中不知道大家有沒有發現一處問題，就是我們在定義PVC時是指定的申請50Mi的空間，而實際掛載到測試容器上的儲存空間是495.8M，剛好是我們在某個node節點上掛載的一個檔案系統的全部空間。

為什麼會這樣呢？這就是我們所使用的這個local persistent volume外部靜態配置器的功能侷限性所在了。它不支援動態的PV空間申請管理。

也就是說，雖然通過這個靜態PV配置器，我們省去了手寫PV YAML檔案的痛苦，但仍然需要手工處理這項工作：

• 手工維護在ConfigMap中指定的自動發現目錄下掛載的檔案系統資源，或者是block裝置的符號連結；

• 我們需要對能夠使用的本地儲存資源提前做一個全域性的規劃，然後劃分為各種尺寸的卷後掛載到自動發現目錄下，當然了只要是還有空閒儲存資源，現有現掛載也是可以的。

那如果以前給某容器分配的一個儲存空間不夠用了怎麼辦？

給大家的一個建議是使用Linux下的LVM（邏輯分割槽管理）來管理每個node節點上的本地磁碟儲存空間。

• 建立一個大的VG分組，把一個node節點上可以使用的儲存空間都放進去；

• 按未來一段時間內的容器儲存空間使用預期，提前批量創建出一部分邏輯卷LVs，都掛載到自動發現目錄下去；

• 不要把VG中的儲存資源全部用盡，預留少部分用於未來給個別容器擴容儲存空間的資源；

• 使用lvextend為特定容器使用的儲存捲進行擴容；

8、如果容器需要使用block塊裝置怎麼配置

有幾點會與上面的配置方法上不同。

首先，是要在k8s主要的元件上均開啟用於支援block塊裝置的特性。

其次是，定義一個”Block”型別的volumeMode PVC，為容器申請一個”Block”型別的PV。

9、Local volumes的最佳實踐

• 為了更好的IO隔離效果，建議將一整塊磁碟作為一個儲存卷使用；

• 為了得到儲存空間的隔離，建議為每個儲存卷使用一個獨立的磁碟分割槽；

• 在仍然存在指定了某個node節點的親和性關係的舊PV時，要避免重新建立具有相同節點名稱的node節點。 否則，系統可能會認為新節點包含舊的PV。

• 對於具有檔案系統的儲存卷，建議在fstab條目和該卷的mount安裝點的目錄名中使用它們的UUID（例如ls -l /dev/disk/by-uuid的輸出）。 這種做法可確保不會安裝錯誤的本地卷，即使其裝置路徑發生了更改（例如，如果/dev/sda1在新增新磁碟時變為/dev/sdb1）。 此外，這種做法將確保如果建立了具有相同名稱的另一個節點時，該節點上的任何卷仍然都會是唯一的，而不會被誤認為是具有相同名稱的另一個節點上的卷。

• 對於沒有檔案系統的原始塊儲存卷，請使用其唯一ID作為符號連結的名稱。 根據您的環境，/dev/disk/by-id/中的卷ID可能包含唯一的硬體序列號。 否則，應自行生成一個唯一ID。 符號連結名稱的唯一性將確保如果建立了另一個具有相同名稱的節點，則該節點上的任何卷都仍然是唯一的，而不會被誤認為是具有相同名稱的另一個節點上的卷。

10、停用local volume的方法

當您想要停用本地卷時，這是一個可能的工作流程。

• 關閉使用這些卷的Pods；

• 從node節點上移除local volumes（比如unmounting, 拔出磁碟等等）；

• 手動刪除相應的PVCs物件；

• Provisioner將嘗試清理卷，但會由於卷不再存在而失敗；

• 手動刪除相應的PVs物件。 注：以上工作也是拜我們所使用的外部靜態配置器所賜。

參考資料：

https://blog.csdn.net/watermelonbig/article/details/84108424 

https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume https://kubernetes.io/docs/concepts/storage/volumes/

作者：高慶，百悟科技 高階運維工程師；

K8S培訓推薦

Kubernetes線下實戰培訓，採用3+1新的培訓模式（3天線下實戰培訓，1年內可免費再次參加），資深一線講師，實操環境實踐，現場答疑互動，培訓內容覆蓋：Docker方面：Docker架構、映象、資料儲存、網路、以及最佳實踐。Kubernetes實戰內容，Kubernetes設計、Pod、常用物件操作，Kuberentes排程系統、QoS、Helm、網路、儲存、CI/CD、日誌監控等。 <瞭解更多詳情>