Kubernetes 3種存儲傻傻分不清楚！

作者：高慶 2018-12-17 12:30:05

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

在Docker容器時(shí)代，我們就對Volume很熟悉了，一般來說我們是通過創(chuàng)建Volume數(shù)據(jù)卷，然后掛載到指定容器的指定路徑下，以實(shí)現(xiàn)容器數(shù)據(jù)的持久化存儲或者是多容器間的數(shù)據(jù)共享，當(dāng)然這里說的都是單機(jī)版的容器解決方案。

[[252662]]

進(jìn)入到容器集群時(shí)代后，我們看到Kubernetes按時(shí)間順序先后提供了emptyDir、hostPath和local的本地磁盤存儲卷解決方案。

emptyDir、hostPath都是Kubernetes很早就實(shí)現(xiàn)和支持了的技術(shù)，local volume方式則是從k8s v1.7才剛剛發(fā)布的alpha版本，目前在k8s v1.10中發(fā)布了local volume的beta版本，部分功能在早期版本中并不支持。

在展開之前，我們先討論一個(gè)問題，就是既然都已經(jīng)實(shí)現(xiàn)容器云平臺了，我們?yōu)槭裁催€要關(guān)注這幾款本地存儲卷的貨呢?

粗略歸納了下，有以下幾個(gè)原因：

特殊使用場景需求，如需要個(gè)臨時(shí)存儲空間，運(yùn)行cAdvisor需要能訪問到node節(jié)點(diǎn)/sys/fs/cgroup的數(shù)據(jù)，做本機(jī)單節(jié)點(diǎn)的k8s環(huán)境功能測試等等。
容器集群只是做小規(guī)模部署，滿足開發(fā)測試、集成測試需求。
作為分布式存儲服務(wù)的一種補(bǔ)充手段，比如我在一臺node主機(jī)上插了塊SSD，準(zhǔn)備給某個(gè)容器吃小灶。
目前主流的兩個(gè)容器集群存儲解決方案是ceph和glusterfs，二者都是典型的網(wǎng)絡(luò)分布式存儲，所有的數(shù)據(jù)讀、寫都是對磁盤IO和網(wǎng)絡(luò)IO的考驗(yàn)，所以部署存儲集群時(shí)至少要使用萬兆的光纖網(wǎng)卡和光纖交換機(jī)。如果你都沒有這些硬貨的話，強(qiáng)上分布式存儲方案的結(jié)果就是收獲一個(gè)以”慢動作”見長的容器集群啦。
分布式存儲集群服務(wù)的規(guī)劃、部署和長期的監(jiān)控、擴(kuò)容與運(yùn)行維護(hù)是專業(yè)性很強(qiáng)的工作，需要有專職的技術(shù)人員做長期的技術(shù)建設(shè)投入。

我們并不是說分布式存儲服務(wù)不好，很多公司在云平臺建設(shè)的實(shí)踐中，往往是需要結(jié)合使用幾種通用的與專用的存儲解決方案，才能最終滿足大部分的使用需求。

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

1、emptyDir

emptyDir類型的Volume在Pod分配到Node上時(shí)被創(chuàng)建，Kubernetes會在Node上自動分配一個(gè)目錄，因此無需指定宿主機(jī)Node上對應(yīng)的目錄文件。這個(gè)目錄的初始內(nèi)容為空，當(dāng)Pod從Node上移除時(shí)，emptyDir中的數(shù)據(jù)會被***刪除。

注：容器的crashing事件并不會導(dǎo)致emptyDir中的數(shù)據(jù)被刪除。

***實(shí)踐

根據(jù)官方給出的***使用實(shí)踐的建議，emptyDir可以在以下幾種場景下使用：

apiVersion: v1 
kind: Pod 
metadata: 
 name: test-pod 
spec: 
 containers: 
 - image: busybox 
   name: test-emptydir 
   command: [ "sleep", "3600" ] 
   volumeMounts: 
   - mountPath: /data 
     name: data-volume 
 volumes: 
 - name: data-volume 
   emptyDir: {}

查看下創(chuàng)建出來的pod，這里只截取了與volume有關(guān)的部分，其他無關(guān)內(nèi)容直接省略：

# kubectl describe pod test-pod 
Name:         test-pod 
Namespace:    default 
Node:         kube-node2/172.16.10.102 
...... 
   Environment:    <none> 
   Mounts: 
     /data from data-volume (rw) 
...... 
Volumes: 
 data-volume: 
   Type:    EmptyDir (a temporary directory that shares a pod's lifetime) 
   Medium: 
......

可以進(jìn)入到容器中查看下實(shí)際的卷掛載結(jié)果：

# kubectl exec -it test-pod -c test-emptydir /bin/sh

2、hostPath

hostPath類型則是映射node文件系統(tǒng)中的文件或者目錄到pod里。在使用hostPath類型的存儲卷時(shí)，也可以設(shè)置type字段，支持的類型有文件、目錄、File、Socket、CharDevice和BlockDevice。

下面是來自官網(wǎng)對hostPath的使用場景和注意事項(xiàng)的介紹。

使用場景：

當(dāng)運(yùn)行的容器需要訪問Docker內(nèi)部結(jié)構(gòu)時(shí)，如使用hostPath映射/var/lib/docker到容器;
當(dāng)在容器中運(yùn)行cAdvisor時(shí)，可以使用hostPath映射/dev/cgroups到容器中;
注意事項(xiàng)：
配置相同的pod(如通過podTemplate創(chuàng)建)，可能在不同的Node上表現(xiàn)不同，因?yàn)椴煌?jié)點(diǎn)上映射的文件內(nèi)容不同
當(dāng)Kubernetes增加了資源敏感的調(diào)度程序，hostPath使用的資源不會被計(jì)算在內(nèi)
宿主機(jī)下創(chuàng)建的目錄只有root有寫權(quán)限。你需要讓你的程序運(yùn)行在privileged container上，或者修改宿主機(jī)上的文件權(quán)限。

hostPath volume 實(shí)驗(yàn)

下面我們在測試k8s環(huán)境中創(chuàng)建一個(gè)hostPath volume使用示例。

apiVersion: v1 
kind: Pod 
metadata: 
 name: test-pod2 
spec: 
 containers: 
 - image: busybox 
   name: test-hostpath 
   command: [ "sleep", "3600" ] 
   volumeMounts: 
   - mountPath: /test-data 
     name: test-volume 
 volumes: 
 - name: test-volume 
   hostPath: 
     # directory location on host 
     path: /data 
     # this field is optional 
     type: Directory

查看下pod創(chuàng)建結(jié)果，觀察volumes部分：

# kubectl describe pod test-pod2 
Name:         test-pod2 
Namespace:    default 
Node:         kube-node2/172.16.10.102 
...... 
   Mounts: 
     /test-data from test-volume (rw) 
...... 
Volumes: 
 test-volume: 
   Type:          HostPath (bare host directory volume) 
   Path:          /data 
   HostPathType:  Directory 
......

我們登錄到容器中，進(jìn)入掛載的/test-data目錄中，創(chuàng)建個(gè)測試文件。

# kubectl exec  -it test-pod2 -c test-hostpath /bin/sh 
/ # echo 'testtesttest' > /test-data/test.log 
/ # exit

我們在運(yùn)行該pod的node節(jié)點(diǎn)上，可以看到如下的文件和內(nèi)容。

[root@kube-node2 test-data]# cat /test-data/test.log 
testtesttest

現(xiàn)在，我們把該pod刪除掉，再看看node節(jié)點(diǎn)上的hostPath使用的目錄與數(shù)據(jù)會有什么變化。

[root@kube-node1 ~]# kubectl delete pod test-pod2 
pod "test-pod2" deleted

到運(yùn)行原pod的node節(jié)點(diǎn)上查看如下。

[root@kube-node2 test-data]# ls -l 
total 4 
-rw-r--r-- 1 root root 13 Nov 14 00:25 test.log 
[root@kube-node2 test-data]# cat /test-data/test.log 
testtesttest

在使用hostPath volume卷時(shí)，即便pod已經(jīng)被刪除了，volume卷中的數(shù)據(jù)還在!

單節(jié)點(diǎn)的k8s本地測試環(huán)境與hostPath volume

有時(shí)我們需要搭建一個(gè)單節(jié)點(diǎn)的k8s測試環(huán)境，就利用到hostPath作為后端的存儲卷，模擬真實(shí)環(huán)境提供PV、StorageClass和PVC的管理功能支持。

apiVersion: storage.k8s.io/v1 
kind: StorageClass 
metadata: 
 namespace: kube-system 
 name: standard 
 annotations: 
   storageclass.beta.kubernetes.io/is-default-class: "true" 
 labels: 
   addonmanager.kubernetes.io/mode: Reconcile 
provisioner: kubernetes.io/host-path

該場景僅能用于單節(jié)點(diǎn)的k8s測試環(huán)境中

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

二者都是node節(jié)點(diǎn)的本地存儲卷方式;

emptyDir可以選擇把數(shù)據(jù)存到tmpfs類型的本地文件系統(tǒng)中去，hostPath并不支持這一點(diǎn);
hostPath除了支持掛載目錄外，還支持File、Socket、CharDevice和BlockDevice，既支持把已有的文件和目錄掛載到容器中，也提供了“如果文件或目錄不存在，就創(chuàng)建一個(gè)”的功能;
emptyDir是臨時(shí)存儲空間，完全不提供持久化支持;
hostPath的卷數(shù)據(jù)是持久化在node節(jié)點(diǎn)的文件系統(tǒng)中的，即便pod已經(jīng)被刪除了，volume卷中的數(shù)據(jù)還會留存在node節(jié)點(diǎn)上;

4、local volume的概念

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

Local volume 允許用戶通過標(biāo)準(zhǔn)PVC接口以簡單且可移植的方式訪問node節(jié)點(diǎn)的本地存儲。 PV的定義中需要包含描述節(jié)點(diǎn)親和性的信息，k8s系統(tǒng)則使用該信息將容器調(diào)度到正確的node節(jié)點(diǎn)。

配置要求

使用local-volume插件時(shí)，要求使用到了存儲設(shè)備名或路徑都相對固定，不會隨著系統(tǒng)重啟或增加、減少磁盤而發(fā)生變化。
靜態(tài)provisioner配置程序僅支持發(fā)現(xiàn)和管理掛載點(diǎn)(對于Filesystem模式存儲卷)或符號鏈接(對于塊設(shè)備模式存儲卷)。對于基于本地目錄的存儲卷，必須將它們通過bind-mounted的方式綁定到發(fā)現(xiàn)目錄中。

StorageClass與延遲綁定

官方推薦在使用local volumes時(shí)，創(chuàng)建一個(gè)StorageClass并把volumeBindingMode字段設(shè)置為“WaitForFirstConsumer”。

雖然local volumes還不支持動態(tài)的provisioning管理功能，但我們?nèi)匀豢梢詣?chuàng)建一個(gè)StorageClass并使用延遲卷綁定的功能，將volume binding延遲至pod scheduling階段執(zhí)行。

這樣可以確保PersistentVolumeClaim綁定策略將Pod可能具有的任何其他node節(jié)點(diǎn)約束也進(jìn)行評估，例如節(jié)點(diǎn)資源要求、節(jié)點(diǎn)選擇器、Pod親和性和Pod反親和性。

kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 
 name: local-storage 
provisioner: kubernetes.io/no-provisioner 
volumeBindingMode: WaitForFirstConsumer

外部static provisioner

配置local volume后，可以使用一個(gè)外部的靜態(tài)配置器來幫助簡化本地存儲的管理。 Provisioner 配置程序?qū)⑼ㄟ^為每個(gè)卷創(chuàng)建和清理PersistentVolumes來管理發(fā)現(xiàn)目錄下的卷。

Local storage provisioner要求管理員在每個(gè)節(jié)點(diǎn)上預(yù)配置好local volumes，并指明該local volume是屬于以下哪種類型：

Filesystem volumeMode (default) PVs – 需要掛載到發(fā)現(xiàn)目錄下面。
Block volumeMode PVs – 需要在發(fā)現(xiàn)目錄下創(chuàng)建一個(gè)指向節(jié)點(diǎn)上的塊設(shè)備的符號鏈接。

一個(gè)local volume，可以是掛載到node本地的磁盤、磁盤分區(qū)或目錄。

Local volumes雖然可以支持創(chuàng)建靜態(tài)PersistentVolume，但到目前為止仍不支持動態(tài)的PV資源管理。

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

創(chuàng)建基于Local volumes的PV的示例

apiVersion: v1 
kind: PersistentVolume 
metadata: 
 name: example-pv 
spec: 
 capacity: 
   storage: 100Gi 
 volumeMode: Filesystem 
 accessModes: 
 - ReadWriteOnce 
 persistentVolumeReclaimPolicy: Delete 
 storageClassName: local-storage 
 local: 
   path: /mnt/disks/ssd1 
 nodeAffinity: 
   required: 
     nodeSelectorTerms: 
     - matchExpressions: 
       - key: kubernetes.io/hostname 
         operator: In 
         values: 
         - example-node

nodeAffinity字段是必須配置的，k8s依賴于這個(gè)標(biāo)簽為你定義的Pods在正確的nodes節(jié)點(diǎn)上找到需要使用的local volumes。
使用volumeMode字段時(shí)，需要啟用BlockVolume 這一Alpha feature特性。
volumeMode字段的默認(rèn)值是Filesystem，但也支持配置為Block，這樣就會把node節(jié)點(diǎn)的local volume作為容器的一個(gè)裸塊設(shè)備掛載使用。

數(shù)據(jù)安全風(fēng)險(xiǎn)

local volume仍受node節(jié)點(diǎn)可用性方面的限制，因此并不適用于所有應(yīng)用程序。如果node節(jié)點(diǎn)變得不健康，則local volume也將變得不可訪問，使用這個(gè)local volume的Pod也將無法運(yùn)行。使用local voluems的應(yīng)用程序必須能夠容忍這種降低的可用性以及潛在的數(shù)據(jù)丟失，是否會真得導(dǎo)致這個(gè)后果將取決于node節(jié)點(diǎn)底層磁盤存儲與數(shù)據(jù)保護(hù)的具體實(shí)現(xiàn)了。

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

二者都基于node節(jié)點(diǎn)本地存儲資源實(shí)現(xiàn)了容器內(nèi)數(shù)據(jù)的持久化功能，都為某些特殊場景下提供了更為適用的存儲解決方案;

前者時(shí)間很久了，所以功能穩(wěn)定，而后者因?yàn)槟贻p，所以功能的可靠性與穩(wěn)定性還需要經(jīng)歷時(shí)間和案例的歷練，尤其是對Block設(shè)備的支持還只是alpha版本;

二者都為k8s存儲管理提供了PV、PVC和StorageClass的方法實(shí)現(xiàn);

local volume實(shí)現(xiàn)的StorageClass不具備完整功能，目前只支持卷的延遲綁定;
hostPath是單節(jié)點(diǎn)的本地存儲卷方案，不提供任何基于node節(jié)點(diǎn)親和性的pod調(diào)度管理支持;
local volume適用于小規(guī)模的、多節(jié)點(diǎn)的k8s開發(fā)或測試環(huán)境，尤其是在不具備一套安全、可靠且性能有保證的存儲集群服務(wù)時(shí);

6、local volume的安裝配置方法

local-volume項(xiàng)目及地址

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

Step 1：配置k8s集群使用本地磁盤存儲

如果使用block塊設(shè)備，則需要啟用Alpha的功能特性：k8s v1.10+

$ export KUBE_FEATURE_GATES=”BlockVolume=true”

注：如果是已經(jīng)部署好的k8s v1.10+集群，需要為幾個(gè)主要組件均開啟對該特性的支持后，才能使用block塊設(shè)備功能。如果k8s是低于1.10版本，則還需要啟用其它的幾個(gè)功能特性，因?yàn)樵诘桶姹局羞@些功能特性還都是alpha版本的。

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

Option 1: GCE（Google Compute Engine）集群

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

$ NODE_LOCAL_SSDS_EXT=<n>,<scsi|nvme>,fs cluster/kube-up.sh 
$ kubectl create -f provisioner/deployment/kubernetes/gce/class-local-ssds.yaml 
$ kubectl create -f provisioner/deployment/kubernetes/gce/provisioner_generated_gce_ssd_volumes.yaml

Option 2: GKE(Google Kubernetes Engine)集群

GKE集群將自動格式化并掛載所請求的Local SSDs。在GKE documentation中有更詳細(xì)的說明。

然后，跳至步驟4。

Option 3: 使用裸機(jī)環(huán)境搭建的集群

1.根據(jù)應(yīng)用程序的使用要求對每個(gè)節(jié)點(diǎn)上的本地?cái)?shù)據(jù)磁盤進(jìn)行分區(qū)和格式化。 2.定義一個(gè)StorageClass，并在一個(gè)發(fā)現(xiàn)目錄下掛載所有要使用的存儲文件系統(tǒng)。發(fā)現(xiàn)目錄是在configmap中指定，見下文。 3.如上所述，使用KUBEFEATUREGATES配置Kubernetes API Server, controller-manager, scheduler, 和所有節(jié)點(diǎn)上的 kubelets。 4.如果沒有使用默認(rèn)的Kubernetes調(diào)度程序策略，則必須啟用以下特性：

Pre-1.9: NoVolumeBindConflict
9+: VolumeBindingChecker

說明：在我們使用測試環(huán)境中，是一套3節(jié)點(diǎn)的k8s測試環(huán)境，為了模擬測試local volume功能，直接結(jié)合使用了下面option4中提供的ram disks測試方法，創(chuàng)建了3個(gè)tmpfs格式的文件系統(tǒng)掛載資源。

Option 4: 使用一個(gè)本機(jī)單節(jié)點(diǎn)的測試集群

創(chuàng)建/mnt/disks目錄，并在該目錄下掛載幾個(gè)子目錄。下面是使用三個(gè)ram disks做一個(gè)真實(shí)存儲卷的模擬測試。

$ mkdir /mnt/fast-disks 
$ for vol in vol1 vol2 vol3; 
do 
   mkdir -p /mnt/fast-disks/$vol 
   mount -t tmpfs $vol /mnt/fast-disks/$vol 
done

(2)創(chuàng)建單機(jī)k8s本地測試集群

$ ALLOW_PRIVILEGED=true LOG_LEVEL=5 FEATURE_GATES=$KUBE_FEATURE_GATES hack/local-up-cluster.sh

Step 2: 創(chuàng)建一個(gè)StorageClass (1.9+)

要延遲卷綁定直到pod調(diào)度并處理單個(gè)pod中的多個(gè)本地PV，必須創(chuàng)建StorageClass并將volumeBindingMode設(shè)置為WaitForFirstConsumer。

# Only create this for K8s 1.9+ 
apiVersion: storage.k8s.io/v1 
kind: StorageClass 
metadata: 
 name: fast-disks 
provisioner: kubernetes.io/no-provisioner 
volumeBindingMode: WaitForFirstConsumer 
# Supported policies: Delete, Retain 
reclaimPolicy: Delete 
$ kubectl create -f provisioner/deployment/kubernetes/example/default_example_storageclass.yaml

yaml文件請到local volume項(xiàng)目文件中查找需要使用的yaml文件

Step 3: 創(chuàng)建local persistent volumes

Option 1: local volume static provisioner 方式

配置一個(gè)外部的靜態(tài)配置器。

(1)生成Provisioner的ServiceAccount，Roles，DaemonSet和ConfigMap規(guī)范，并對其進(jìn)行自定義配置。

此步驟使用helm模板生成需要的配置規(guī)格。有關(guān)設(shè)置說明，請參閱helm README。

使用默認(rèn)值生成Provisioner的配置規(guī)格，請運(yùn)行：

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

這里是將模板經(jīng)過渲染后得到最終使用的各項(xiàng)資源定義文件。如果是使用自定義的配置文件的話：

helm template ./helm/provisioner --values custom-values.yaml > ./provisioner/deployment/kubernetes/provisioner_generated.yaml

(2)部署Provisioner

如果用戶對Provisioner的yaml文件的內(nèi)容感到滿意，就可以使用kubectl創(chuàng)建Provisioner的DaemonSet和ConfigMap了。

# kubectl create -f ./provisioner/deployment/kubernetes/provisioner_generated.yaml 
configmap "local-provisioner-config" created 
daemonset.extensions "local-volume-provisioner" created 
serviceaccount "local-storage-admin" created 
clusterrolebinding.rbac.authorization.k8s.io "local-storage-provisioner-pv-binding" created 
clusterrole.rbac.authorization.k8s.io "local-storage-provisioner-node-clusterrole" created 
clusterrolebinding.rbac.authorization.k8s.io "local-storage-provisioner-node-binding" created

(3)檢查已自動發(fā)現(xiàn)的local volumes

一旦啟動，外部static provisioner將發(fā)現(xiàn)并自動創(chuàng)建出 local-volume PVs。

我們查看下上面測試中創(chuàng)建出的PVs有哪些：

# kubectl get pv 
NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE 
local-pv-436f0527   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-77a4ffb0   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-97f7ec5c   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-9f0ddba3   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-a0dfdc91   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-a52333e3   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-bed86926   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-d037a0d1   495Mi      RWO            Delete           Available             fast-disks               2m 
local-pv-d26c3252   495Mi      RWO            Delete           Available             fast-disks               2m

因?yàn)槭怯?個(gè)node節(jié)點(diǎn)，每個(gè)上面的/mnt/fast-disks自動發(fā)現(xiàn)目錄下掛載了3個(gè)文件系統(tǒng)，所以這里查詢的結(jié)果是生成了9個(gè)PVs

查看某一個(gè)PV的詳細(xì)描述信息：

# kubectl describe pv local-pv-436f0527 
Name:              local-pv-436f0527 
Labels:            <none> 
Annotations:       pv.kubernetes.io/provisioned-by=local-volume-provisioner-kube-node2-c3733876-b56f-11e8-990b-080027395360 
Finalizers:        [kubernetes.io/pv-protection] 
StorageClass:      fast-disks 
Status:            Available 
Claim:             
Reclaim Policy:    Delete 
Access Modes:      RWO 
Capacity:          495Mi 
Node Affinity:     
 Required Terms:   
   Term 0:        kubernetes.io/hostname in [kube-node2] 
Message:           
Source: 
   Type:  LocalVolume (a persistent volume backed by local storage on a node) 
   Path:  /mnt/fast-disks/vol2 
Events:    <none>

此時(shí)就可以直接通過引用名為fast-disks的storageClassName名稱來聲明使用上述PV并將其綁定到PVC。

Option 2: 手動創(chuàng)建 local persistent volume

參照前文介紹local volume概念的章節(jié)中已經(jīng)講解過的PersistentVolume使用示例。

Step 4: 創(chuàng)建 local persistent volume claim

kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
 name: example-local-claim 
spec: 
 accessModes: 
 - ReadWriteOnce 
 resources: 
   requests: 
     storage: 50Mi 
 storageClassName: fast-disks

請?jiān)谑褂脮r(shí)替換為您實(shí)際的存儲容量需求和storageClassName值。

# kubectl create -f local-pvc.yaml 
persistentvolumeclaim "example-local-claim" created 
# kubectl get pvc 
NAME                  STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE 
example-local-claim   Pending     
# kubectl describe pvc example-local-claim 
Name:          example-local-claim 
Namespace:     default 
StorageClass:  fast-disks 
Status:        Pending 
Volume:         
Labels:        <none> 
Annotations:   <none> 
Finalizers:    [kubernetes.io/pvc-protection] 
Capacity:       
Access Modes:   
Events: 
 Type    Reason                Age               From                         Message 
 ----    ------                ----              ----                         -------

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

我們可以看到存儲卷延遲綁定的效果，在綁定到容器前，該P(yáng)VC的狀態(tài)會是pending

Step 5：創(chuàng)建一個(gè)測試Pod并引用上面創(chuàng)建的PVC

apiVersion: v1 
kind: Pod 
metadata: 
 name: local-pvc-pod 
spec: 
 containers: 
 - image: busybox 
   name: test-local-pvc 
   command: [ "sleep", "3600" ] 
   volumeMounts: 
   - mountPath: /data 
     name: data-volume 
 volumes: 
 - name: data-volume 
   persistentVolumeClaim: 
     claimName: example-local-claim

創(chuàng)建并查看：

# kubectl create -f example-local-pvc-pod.yaml 
pod "local-pvc-pod" created 
# kubectl get pods -o wide 
NAME                             READY     STATUS    RESTARTS   AGE       IP            NODE 
client1                          1/1       Running   67         64d       172.30.80.2   kube-node3 
local-pvc-pod                    1/1       Running   0          2m        172.30.48.6   kube-node1

查看pod中容器掛載PVC的配置詳情，這里只截取了部分信息：

# kubectl describe pod local-pvc-pod 
Name:         local-pvc-pod 
Namespace:    default 
Node:         kube-node1/172.16.10.101 
Start Time:   Thu, 15 Nov 2018 16:39:30 +0800 
Labels:       <none> 
Annotations:  <none> 
Status:       Running 
IP:           172.30.48.6 
Containers: 
 test-local-pvc: 
...... 
   Mounts: 
     /data from data-volume (rw) 
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-qkhcf (ro) 
Conditions: 
 Type           Status 
 Initialized    True 
 Ready          True 
 PodScheduled   True 
Volumes: 
 data-volume: 
   Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) 
   ClaimName:  example-local-claim 
   ReadOnly:   false 
...... 
[root@kube-node1 ~]# kubectl exec -it local-pvc-pod -c test-local-pvc /bin/sh 
/ # ls 
bin   data  dev   etc   home  proc  root  sys   tmp   usr   var 
/ # df -h 
Filesystem                Size      Used Available Use% Mounted on 
overlay                  41.0G      8.1G     32.8G  20% / 
tmpfs                    64.0M         0     64.0M   0% /dev 
tmpfs                   495.8M         0    495.8M   0% /sys/fs/cgroup 
vol3                    495.8M         0    495.8M   0% /data

再回過頭來看下PVC的狀態(tài)，已經(jīng)變成了Bound：

# kubectl get pvc 
NAME                        STATUS    VOLUME              CAPACITY   ACCESS MODES   STORAGECLASS   AGE 
example-local-claim         Bound     local-pv-a0dfdc91   495Mi      RWO            fast-disks     1h

7、一個(gè)關(guān)于local volume功能局限性問題的討論

在上面的實(shí)驗(yàn)過程中不知道大家有沒有發(fā)現(xiàn)一處問題，就是我們在定義PVC時(shí)是指定的申請50Mi的空間，而實(shí)際掛載到測試容器上的存儲空間是495.8M，剛好是我們在某個(gè)node節(jié)點(diǎn)上掛載的一個(gè)文件系統(tǒng)的全部空間。

為什么會這樣呢?這就是我們所使用的這個(gè)local persistent volume外部靜態(tài)配置器的功能局限性所在了。它不支持動態(tài)的PV空間申請管理。

也就是說，雖然通過這個(gè)靜態(tài)PV配置器，我們省去了手寫PV YAML文件的痛苦，但仍然需要手工處理這項(xiàng)工作：

手工維護(hù)在ConfigMap中指定的自動發(fā)現(xiàn)目錄下掛載的文件系統(tǒng)資源，或者是block設(shè)備的符號鏈接;
我們需要對能夠使用的本地存儲資源提前做一個(gè)全局的規(guī)劃，然后劃分為各種尺寸的卷后掛載到自動發(fā)現(xiàn)目錄下，當(dāng)然了只要是還有空閑存儲資源，現(xiàn)有現(xiàn)掛載也是可以的。

那如果以前給某容器分配的一個(gè)存儲空間不夠用了怎么辦?

給大家的一個(gè)建議是使用Linux下的LVM(邏輯分區(qū)管理)來管理每個(gè)node節(jié)點(diǎn)上的本地磁盤存儲空間。

創(chuàng)建一個(gè)大的VG分組，把一個(gè)node節(jié)點(diǎn)上可以使用的存儲空間都放進(jìn)去;
按未來一段時(shí)間內(nèi)的容器存儲空間使用預(yù)期，提前批量創(chuàng)建出一部分邏輯卷LVs，都掛載到自動發(fā)現(xiàn)目錄下去;
不要把VG中的存儲資源全部用盡，預(yù)留少部分用于未來給個(gè)別容器擴(kuò)容存儲空間的資源;
使用lvextend為特定容器使用的存儲卷進(jìn)行擴(kuò)容;

8、如果容器需要使用block塊設(shè)備怎么配置

有幾點(diǎn)會與上面的配置方法上不同。

首先，是要在k8s主要的組件上均開啟用于支持block塊設(shè)備的特性。

KUBE_FEATURE_GATES="BlockVolume=true"

其次是，定義一個(gè)”Block”類型的volumeMode PVC，為容器申請一個(gè)”Block”類型的PV。

kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
 name: example-block-local-claim 
spec: 
 accessModes: 
 - ReadWriteOnce 
 resources: 
   requests: 
     storage: 50Mi 
 volumeMode: Block 
 storageClassName: fast-disks

9、Local volumes的***實(shí)踐

為了更好的IO隔離效果，建議將一整塊磁盤作為一個(gè)存儲卷使用;
為了得到存儲空間的隔離，建議為每個(gè)存儲卷使用一個(gè)獨(dú)立的磁盤分區(qū);
在仍然存在指定了某個(gè)node節(jié)點(diǎn)的親和性關(guān)系的舊PV時(shí)，要避免重新創(chuàng)建具有相同節(jié)點(diǎn)名稱的node節(jié)點(diǎn)。否則，系統(tǒng)可能會認(rèn)為新節(jié)點(diǎn)包含舊的PV。
對于具有文件系統(tǒng)的存儲卷，建議在fstab條目和該卷的mount安裝點(diǎn)的目錄名中使用它們的UUID(例如ls -l /dev/disk/by-uuid的輸出)。這種做法可確保不會安裝錯(cuò)誤的本地卷，即使其設(shè)備路徑發(fā)生了更改(例如，如果/dev/sda1在添加新磁盤時(shí)變?yōu)?dev/sdb1)。此外，這種做法將確保如果創(chuàng)建了具有相同名稱的另一個(gè)節(jié)點(diǎn)時(shí)，該節(jié)點(diǎn)上的任何卷仍然都會是唯一的，而不會被誤認(rèn)為是具有相同名稱的另一個(gè)節(jié)點(diǎn)上的卷。
對于沒有文件系統(tǒng)的原始塊存儲卷，請使用其唯一ID作為符號鏈接的名稱。根據(jù)您的環(huán)境，/dev/disk/by-id/中的卷ID可能包含唯一的硬件序列號。否則，應(yīng)自行生成一個(gè)唯一ID。符號鏈接名稱的唯一性將確保如果創(chuàng)建了另一個(gè)具有相同名稱的節(jié)點(diǎn)，則該節(jié)點(diǎn)上的任何卷都仍然是唯一的，而不會被誤認(rèn)為是具有相同名稱的另一個(gè)節(jié)點(diǎn)上的卷。

10、停用local volume的方法

當(dāng)您想要停用本地卷時(shí)，這是一個(gè)可能的工作流程。