Kubernetes的存儲之Volume

在虛擬化的一系列解決方案中，數據的持久化都是需要我們非常關心的問題，dokcer是這樣，Kubernetes也是這樣。不過在Kubernetes中，有一個數據卷的概念。

一、Volume簡介

我們經常都會說：容器、Pod都是很短暫的！其含義就是容器和Pod的生命周期都是很短暫的，會被頻繁地銷毀和創建。容器銷毀時，保存在容器內部文件系統中的數據都會被清除。

Volume的生命周期獨立于容器，Pod中的容器可能被銷毀和重啟，但Volume會被保留。

Kubernetes Volume主要解決了以下兩個問題：
1）數據持久性：通常情況下，容器運行起來后，寫到其文件系統的文件是暫時性的。當容器崩潰后，kubelet會將這個容器不斷的重啟，當達到重啟的次數后，容器仍然不可用，那么就會將這個容器kill掉，重新生成新的容器。此時，新運行的容器并沒有原容器中的數據，因為容器是由鏡像創建的；
2）數據共享：同一個Pod中運行的容器之間，經常會存在共享文件/共享文件夾的需求；

從根本上來說，一個數據卷僅僅是一個可以被Pod訪問的目錄或文件。這個目錄是怎么來的，取決于該數據卷的類型。同一個Pod中的兩個容器可以將一個數據卷掛載到不同的目錄下。

Volume 提供了對各種 backend 的抽象，容器在使用 Volume 讀寫數據的時候不需要關心數據到底是存放在本地節點的文件系統中呢還是云硬盤上。對它來說，所有類型的 Volume 都只是一個目錄。

二、Volume之emptyDir

1）emptyDir簡介

emptyDir 是最基礎的 Volume 類型。正如其名字所示，一個 emptyDir Volume 是 Host 上的一個空目錄。

emptyDir Volume 對于容器來說是持久的，對于 Pod 則不是。當 Pod 從節點刪除時，Volume 的內容也會被刪除。但如果只是容器被銷毀而 Pod 還在，則 Volume 不受影響。類似于docker數據持久化中的docker manager volume方式！

2）emptyDir使用示例

[root@master yaml]# vim emptyDir.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: producer-consumer          #定義Pod的名稱
spec:
  containers:
  - image: busybox
    name: producer              #定義容器的名稱
    volumeMounts:
    - mountPath: /producer_dir            #指定容器內的路徑
      name: shared-volume                 #表示把shared-volume掛載到容器中
    args:               #當容器運行完成后，執行以下的寫操作
    - /bin/sh
    - -c
    - echo "hello k8s" > /producer_dir/hello; sleep 30000

  - image: busybox
    name: consumer             #定義容器的名稱
    volumeMounts:
    - mountPath: /consumer_dir
      name: shared-volume                     #與上一個容器一樣
    args:
    - /bin/sh
    - -c
    - cat /consumer_dir/hello; sleep 30000

  volumes:
  - name: shared-volume           #定義數據卷的名稱，必須與以上掛載的數據卷名稱一致
    emptyDir: {}             #定義一個類型為emptyDir的數據卷，名稱為shared-volume
[root@master yaml]# kubectl apply -f emptyDir.yam        #生成所需的Pod資源
[root@master yaml]# kubectl exec -it producer-consumer -c producer /bin/sh
#進入第一個容器進行驗證
/ # cat /producer_dir/hello 
hello k8s
[root@master yaml]# kubectl exec -it producer-consumer -c consumer /bin/sh
#進行第二個容器進行驗證
/ # cat /consumer_dir/hello 
hello k8s

到此可以看出這個pod中的兩個容器指定的目錄內容都是一樣的，具體是本地的那個目錄還需進一步進行驗證。

[root@master yaml]# kubectl get pod -o wide           
NAME                READY   STATUS    RESTARTS   AGE     IP           NODE     NOMINATED NODE   READINESS GATES
producer-consumer   2/2     Running   0          7m58s   10.244.2.2   node02   <none>           <none>
#可以看出這個pod是運行在node02上的
[root@node02 ~]# docker ps | grep busybox          #由于容器較多，根據使用的鏡像名稱進行篩選
4fbd734e1763        busybox                "/bin/sh -c 'cat /co…"    8 minutes ago       Up 8 minutes                            k8s_consumer_producer-consumer_default_003a002d-caec-4202-a020-1ae8d6ff7eba_0
b441c2ff2217        busybox                "/bin/sh -c 'echo \"h…"   8 minutes ago       Up 8 minutes                            k8s_producer_producer-consumer_default_003a002d-caec-4202-a020-1ae8d6ff7eba_0
[root@node02 ~]# docker inspect 4fbd734e1763         #根據容器的ID查看容器的詳細信息
#找到Mounts字段，如下：
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/var/lib/kubelet/pods/003a002d-caec-4202-a020-1ae8d6ff7eba/volumes/kubernetes.io~empty-dir/shared-volume",
                                #此處指定的便是docker host本地的目錄
                "Destination": "/consumer_dir",             #容器中的目錄
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },
[root@node02 ~]# docker inspect b441c2ff2217
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/var/lib/kubelet/pods/003a002d-caec-4202-a020-1ae8d6ff7eba/volumes/kubernetes.io~empty-dir/shared-volume",
                "Destination": "/producer_dir",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },
#可以看出這兩個容器的源目錄是一樣，掛載的是docker host本地的同一個目錄                       
[root@node02 ~]# cd /var/lib/kubelet/pods/003a002d-caec-4202-a020-1ae8d6ff7eba/volumes/kubernetes.io~empty-dir/shared-volume
[root@node02 shared-volume]# cat hello 
hello k8s
#驗證內容

由于是Kubernetes集群的環境，刪除一個容器比較麻煩，直接將pod刪除，查看docker host本地的數據是否存在！

[root@master yaml]# kubectl delete -f emptyDir.yaml
#master節點將pod刪除
[root@node02 ~]# cd /var/lib/kubelet/pods/003a002d-caec-4202-a020-1ae8d6ff7eba/volumes/kubernetes.io~empty-dir/shared-volume
-bash: cd: /var/lib/kubelet/pods/003a002d-caec-4202-a020-1ae8d6ff7eba/volumes/kubernetes.io~empty-dir/shared-volume: 沒有那個文件或目錄
#node02進行驗證，發現目錄已經消失

3）emptyDir總結

emptyDir 是Docker Host 上創建的臨時目錄，其優點是能夠方便地為 Pod 中的容器提供共享存儲，不需要額外的配置。但它不具備持久性，如果 Pod 不存在了，emptyDir 也就沒有了。根據這個特性，emptyDir 特別適合 Pod 中的容器需要臨時共享存儲空間的場景！

簡單來說就是，如果容器被刪除，數據依然存在；如果Pod被刪除，數據將不會存在！

三、Volume之HostPath

hostPath Volume 的作用是將 Docker Host 文件系統中已經存在的目錄 mount 給 Pod 的容器。大部分應用都不會使用 hostPath Volume，因為這實際上增加了 Pod 與節點的耦合，限制了 Pod 的使用。不過那些需要訪問 Kubernetes 或 Docker 內部數據（配置文件和二進制庫）的應用則需要使用 hostPath。類似于docker數據持久化中的bind mount方式！

當然也可以進行創建，這里就偷個懶，使用Kubernetes集群自帶的YAML文件進行介紹！

[root@master yaml]# kubectl edit --namespace=kube-system pod kube-apiserver-master 
#查看apiserver組件的yaml文件

如圖：

如果 Pod 被銷毀了，hostPath 對應的目錄也還會被保留，從這點看，hostPath 的持久性比 emptyDir 強。不過一旦 Host 崩潰，hostPath 也就沒法訪問了。

由于使用場景較少，以上兩種方式這里就不詳細介紹了！

四、Volume之Persistent Volume

Persistent Volume概述

普通Volume和使用它的Pod之間是一種靜態綁定關系，在定義Pod的文件里，同時定義了它使用的Volume。Volume 是Pod的附屬品，我們無法單獨創建一個Volume，因為它不是一個獨立的K8S資源對象。

而Persistent Volume 簡稱PV是一個K8S資源對象，所以我們可以單獨創建一個PV。它不和Pod直接發生關系，而是通過Persistent Volume Claim，簡稱PVC來實現動態綁定。Pod定義里指定的是PVC，然后PVC會根據Pod的要求去自動綁定合適的PV給Pod使用。

既然有了PV這個概念，那么PVC（PersistentVolumeClaim）這個概念也不得不說一下，PVC代表用戶使用存儲的請求，應用申請PV持久化空間的一個申請、聲明。K8s集群可能會有多個PV，你需要不停的為不同的應用創建多個PV。

如圖：

1）PV是集群中的存儲資源，通常由集群管理員創建和管理；
2）StorageClass用于對PV進行分類，如果配置正確，Storage也可以根據PVC的請求動態創建PV；
3）PVC是使用該資源的請求，通常由應用程序提出請求，并指定對應的StorageClass和需求的空間大小；
4）PVC可以作為數據卷的一種，被掛載到Pod中使用；

PV與PVC的管理過程如下：
1）在主機上劃分出一個單獨的目錄用于PV使用，并且定義其可用大小；
2）創建PVC這個資源對象，便于申請PV的存儲空間；
3）Pod中添加數據卷，數據卷關聯到PVC；
4）Pod中包含容器，容器掛載數據卷；

下面通過一個案例來詳細了解一下Persistent Volume！

案例實現過程：
1）底層采用NFS存儲，然后再NFS的目錄下劃分1G的容量供PV調度；
2）創建PVC來申請PV的存儲空間；
3）創建Pod，使用PVC申請的存儲空間來實現數據的持久化；

1）搭建NFS存儲

本次案例直接在master節點上創建NFS存儲！

[root@master ~]# yum -y install nfs-utils rpcbind
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# systemctl start nfs-server
[root@master ~]# systemctl start rpcbind
[root@master ~]# showmount -e
Export list for master:
/nfsdata *

2）創建PV資源對象

[root@master ~]# vim test-pv.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv
spec:
  capacity:
    storage: 1Gi          #指定該PV資源分配的容器為1G
  accessModes:         #指定訪問模式
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle       #指定回收策略（實驗環境，實際環境很少會這樣做）
  storageClassName: nfs           #指定存儲類名字
  nfs:                          #需要與存儲類名字一致
    path: /nfsdata/test-pv                //指定NFS的目錄
    server: 192.168.1.4                  //指定NFS的IP地址

上述yaml文件中，主要字段的解釋：
1）accessModes（訪問模式）

• ReadWriteOnce：以讀寫的方式掛載到單個節點；
• ReadWriteMany：以讀寫的方式掛載到多個節點 ；
• ReadOnlyMany：以只讀的方式掛載到多個節點；

2）persistentVolumeReclaimPolicy（PV的回收策略）

• Recycle：自動清除PV中的數據，自動回收；
• Retain：需要手動回收；
• Delete：刪除云存儲資源（云存儲專用）；

[root@master ~]# kubectl apply -f test-pv.yaml
[root@master ~]# kubectl get pv         #查看PV的狀態
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
test-pv   1Gi        RWO            Recycle          Available           nfs                     21s
#注意其PV的狀態必須是 Available才可正常使用

3）創建PVC資源對象

[root@master ~]# vim test-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:             #定義訪問模式，必須與PV定義的訪問模式一致
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi            #直接請求i使用最大的容量
  storageClassName: nfs           #定義的名稱需與PV定義的名稱一致
[root@master ~]# kubectl apply -f test-pvc.yaml
[root@master ~]# kubectl get pvc          #查看PVC的狀態
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc   Bound    test-pv   1Gi        RWO            nfs            102s
[root@master ~]# kubectl get pv           #查看PV的狀態
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS   REASON   AGE
test-pv   1Gi        RWO            Recycle          Bound    default/test-pvc   nfs                     14m
#注意PV與PVC的狀態都是Bound，表示PV與PVC的關聯成功

如果，K8s集群中，有很多類似的PV，PVC在向PV申請空間時，不僅會考慮名稱以及訪問控制模式，還會考慮你申請空間的大小，會分配給你最合適大小的PV！

常見的狀態有：
1）Available——>閑置狀態，沒有被綁定到PVC；
2）Bound——>綁定到PVC；
3）Released——>PVC被刪除，資源沒有被利用；
4）Failed——>自動回收失敗；

4）創建一個Pod

[root@master ~]# vim test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 300000
    volumeMounts:
    - mountPath: /testdata            #定義容器中的目錄
      name: volumedata               #保證與卷的名稱一致
  volumes:
    - name: volumedata               #定義卷的名稱
      persistentVolumeClaim:
        claimName: test-pvc            #指定邏輯卷對應的PVC名稱
[root@master ~]# kubectl apply -f  test-pod.yaml 
[root@master ~]# kubectl get pod      #查看pod的狀態
NAME       READY   STATUS              RESTARTS   AGE
test-pod   0/1     ContainerCreating   0         6m26s
#注意其狀態為 ContainerCreating，表示容器正在創建，但是查看時間，這么長時間沒有創建好，不太正常

當pod狀態不正常時，一般我們可以采用以下三種方式進行排錯：
1）使用“ kubectl describe pod pod名稱”查看pod的詳細信息；
2）使用“kubectl logs pod名稱“查看pod的日志信息；
3）使用“cat /var/log/messages | grep kubelet”查看對應節點kubelet系統日志；

本次采用第一種方式排錯！

[root@master ~]# kubectl describe pod test-pod 
#最后的一條的信息如下：
mount.nfs: mounting 192.168.1.4:/nfsdata/test-pv failed, reason given by server: No such file or directory
#根據消息提示，指定本地需要掛載的目錄不存在
[root@master ~]# mkdir  -p  /nfsdata/test-pv
#創建完成目錄后，建議查看pod生成的容器運行的節點，將節點上的kubelet服務進行重啟，重啟完成后，再次查看Pod的狀態
[root@master ~]# kubectl get pod        //再次查看pod的狀態
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          32m

如果創建Pod的過程中，Pod不斷的重啟，主要是因為：
1）swap交換分區沒有被關閉，導致集群運行不正常；
2）node節點內存不足，道州集群運行不正常；

以上兩種情況都會導致Pod會不斷的重啟，可以使用“free -h”命令進行查看！

5）測試其數據持久化的效果

[root@master ~]# kubectl exec -it test-pod /bin/sh
/ # echo "test pv pvc" > /testdata/test.txt
#進入容器，創建文件進行測試
[root@master ~]# cat /nfsdata/test-pv/test.txt 
test pv pvc
#確認這個文件本地是存在的
[root@master ~]# kubectl delete -f test-pod.yaml 
#將pod進行刪除
[root@master ~]# cat /nfsdata/test-pv/test.txt 
test pv pvc
#再次查看發現pod的測試文件依然存在
[root@master ~]# kubectl delete -f test-pvc.yaml 
#將PVC進行刪除
[root@master ~]# cat /nfsdata/test-pv/tes
cat: /nfsdata/test-pv/tes: 沒有那個文件或目錄
#再次查看發現pod的測試文件不見了，因為將PVC刪除了

總結：由于我們在創建pv這個資源對象時，采用的回收策略是清除PV中的數據，然后自動回收，而PV這個資源對象是由PVC來申請使用的，所以不管是容器也好，pod也好，它們的銷毀并不會影響用于實現數據持久化的nfs本地目錄下的數據，但是，一旦這個PVC被刪除，那么本地的數據就會隨著PVC的銷毀而不復存在，也就是說，采用PV這種數據卷來實現數據的持久化，它這個數據持久化的生命周期是和PVC的生命周期是一致的。

五、mysql對數據持久化的應用

可能通過步驟四并不能真正的理解Persistent volume的作用，下面通過創建mysql容器的方式來驗證Persistent volume的作用！

1）搭建NFS共享存儲

本次案例直接在master節點上創建NFS存儲！

[root@master ~]# yum -y install nfs-utils rpcbind
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# systemctl start nfs-server
[root@master ~]# systemctl start rpcbind
[root@master ~]# showmount -e
Export list for master:
/nfsdata *

2）創建PV資源對象

[root@master ~]# vim mysql-pv.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain                  #注意指定的回收策略為手動回收
  storageClassName: nfs
  nfs:
    path: /nfsdata/mysql-pv
    server: 192.168.1.4
[root@master ~]# kubectl apply -f mysql-pv.yaml 
[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
test-pv   1Gi        RWO            Retain           Available           nfs                     15s
[root@master ~]# mkdir -p /nfsdata/mysql-pv 

3）創建PVC資源對象

[root@master ~]# vim mysql-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs
[root@master ~]# kubectl apply -f mysql-pvc.yaml 
[root@master ~]# kubectl get pvc
NAME        STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-pvc   Bound    mysql-pv   1Gi        RWO            nfs            13s
[root@master ~]# kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
mysql-pv   1Gi        RWO            Retain           Bound    default/mysql-pvc   nfs                     8m14s

4）創建pod資源

[root@master ~]# vim mysql-pod.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mysql-pod
spec:
  selector:                     #設置給予等值的標簽選擇器
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:                      #設置環境變量，數據庫root用戶的密碼
        - name: MYSQL_ROOT_PASSWORD
          value: 123.com
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql               #這個目錄是數據庫存放數據的目錄（指定的是容器中的目錄）
      volumes:
      - name: mysql-storage
        persistentVolumeClaim:
          claimName: mysql-pvc
[root@master ~]# kubectl apply -f mysql-pod.yaml 
[root@master ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
mysql-pod-6cc889468b-gq4qz   1/1     Running   0          3s

5）測試數據持久化效果

[root@master ~]# kubectl exec -it mysql-pod-6cc889468b-gq4qz -- mysql -u root -p123.com
#直接登錄運行mysql數據庫的pod中的mysql
#插入數據進行測試
mysql> create database lzj;
mysql> use lzj;
mysql> create table my_id( id int(4) );
mysql> insert my_id values (9527);
mysql> select * from my_id;
+------+
| id   |
+------+
| 9527 |
+------+
[root@master ~]# ls /nfsdata/mysql-pv/
auto.cnf  ibdata1  ib_logfile0  ib_logfile1  lzj  mysql  performance_schema
#查看pod對應的NFS的目錄，確實有了數據
[root@master ~]# kubectl get pod -o wide             #查看pod的詳細信息
NAME                         READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
mysql-pod-6cc889468b-gq4qz   1/1     Running   0          23m   10.244.2.6   node02   <none>           <none>
#查看到pod是運行在node02節點上的
#模擬node02宕機，步驟省略，關機、掛起都可以！
[root@node01 ~]# systemctl restart kubelet
#重啟node01的kubelet服務
#接下來耐心等待pod的轉移，可能需要差不多5分鐘
^C[root@master ~]# kubectl get pod  -o wide                                #可以看到pod已經運行在node01上
NAME                         READY   STATUS        RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
mysql-pod-6cc889468b-gdf7k   1/1     Running       0          66s   10.244.1.6   node01   <none>           <none>
mysql-pod-6cc889468b-gq4qz   1/1     Terminating   0          32m   10.244.2.6   node02   <none>           <none>
[root@master ~]# kubectl exec -it mysql-pod-6cc889468b-gdf7k  -- mysql -u root -p123.com
#再次登錄到pod中運行的mysql（注意：pod的名稱）
mysql> select * from lzj.my_id;                     #再次數據是否存在
+------+
| id   |
+------+
| 9527 |
+------+
1 row in set (0.01 sec)
#數據依舊存在

——————————————本次到此結束，感謝閱讀—————————————