kubernetes 存儲卷與數據持久化

一 總述

1 存儲卷概念

POD 自身具有生命周期，因此其內部運行的容器及相關數據無法完成持久化，docker支持配置容器使用存儲卷將數據持久存儲于自身文件系統之外的存儲系統，其可以是節點文件系統或網絡文件系統。相應的Kubernetes 提供的存儲卷屬于POD資源級別，共享與POD內的所有容器，可用于在勇氣的文件系統之外存儲應用程序的相關數據，甚至還可獨立于POD生命周期之外實現數據持久化

存儲卷： 定義在POD資源之上，可被其內部的所有容器掛載的共享目錄，它關聯至某外部的存儲設備之上的存儲空間，從而獨立于容器自身的文件系統，而數據是否具有持久能力則取決于存儲卷自身能否支持持久化

2 存儲卷類型

1 節點級別的存儲卷

empty: 其生命周期和POD資源相同
hostPath：其雖然可實現持久化存儲，但若POD被調度至其他節點，則該節點的存儲資源需要被遷移到指定節點，否則將無法持久化

2 網絡級別存儲卷

NFS
ceph
GlusterFS
...

其可實現數據的持久化存儲

3 特殊存儲卷

secret： 用于向POD傳遞某些敏感信息，如密碼、私鑰、證書等。
configmap：用于向POD中注入非敏感數據，如配置文件，其可實現容器配置文件集中化定義和管理

3 存儲卷使用方式

1 直接在POD中進行指定和配置

POD中定義的存儲有兩部分組成：
1 pods.spec.volumes： 用于定義在POD之上掛載的存儲卷列表，及存儲的來源
核心字段
pods.spec.volumes.name ： 用于定義此存儲卷的名稱，下面的掛載中需要通過此名稱關聯此存儲卷
pods.spec.volumes.TYPE：用于指定此存儲卷的類型， 如emptydir、NFS、gitRepo等

2 pods.spec.containers.volumeMounts ： 用于定義存儲卷被掛載到POD的位置及其相關的掛載形式
核心字段
pods.spec.containers.volumeMounts.mountPath ：用于定義掛載到目標容器的具體位置，如/usr/share/nginx/html
pods.spec.containers.volumeMounts.name： 用于引用上述存儲卷名稱。
pods.spec.containers.volumeMounts.readOnly ： 指定存儲卷是否為只讀存儲卷。默認為false，及為讀寫存儲卷。
pods.spec.containers.volumeMounts.subPath： 定義掛載存儲卷時使用的子路徑，及在mountPath指定的路徑下使用一個子路徑作為其掛載點。

2 通過PV和PVC 進行引用和配置

二 臨時存儲卷

1 概述

emptyDir 存儲卷生命周期與其POD相同，其長用于對數據緩存或臨時存儲，數據的共享等。
gitRepo 存儲卷可以看做是emptyDir存儲卷的一種實際應用，使用該存儲卷的POD創建資源可以通過掛載目錄訪問指定的代碼倉庫中的數據，使用gitRepo存儲卷的POD資源在創建時，會首先創建一個空目錄（emptyDir）并克隆（clone）一份指定的GIT倉庫中的數據到該目錄，而后再創建容器并掛載該存儲卷。

2 emptyDir存儲卷

pods.spec.volumes.emptyDir 其主要包含兩個字段

pods.spec.volumes.emptyDir.medium：此目錄所在的存儲介質類型，取值有"default"或 "memory"，默認為"default"，表示使用節點的默認存儲介質。"memory"則表示基于RAM的臨時文件系統tmpfs，空間受限于內存，但性能好，通常用于為容器中提供緩存空間。

pods.spec.volumes.emptyDir.sizeLimit： 用于指定當前存儲卷的限額，默認為nil,表示不限制。

實例

#[root@master1 emptyDir]# cat demo.yaml 
apiVersion: v1
kind: Pod
metadata:
    name: demo-empty
    namespace: default
spec:
    volumes:  #定義掛載的存儲卷
        - name: html  # 指定存儲卷名稱
          emptyDir: {}  # 指定存儲卷類型
    containers:
        - name: nginx1
          image: nginx:1.14
          ports:
            - name: http
              containerPort: 80
          volumeMounts:  #指定掛載存儲卷
            - name: html  #指定掛載存儲卷名稱 
              mountPath: /usr/share/nginx/html  #指定掛載存儲卷目錄
              readOnly: true  # 指定掛載存儲卷讀寫方式
        - name: nginx2  # 配置另一個容器，用于指定寫入臨時存儲卷
          image: alpine
          volumeMounts:
            - name: html
              mountPath: /html
          command: ["/bin/sh","-c"]  # 配置寫入存儲卷數據
          args:
            - while true; do
                echo $(date) >> /html/index.html;
                sleep 5;
              done

部署

kubectl apply -f demo.yaml 

查看

測試

3 gitRepo存儲卷

1 核心字段

pods.spec.volumes.gitRepo.repository: git倉庫URL，其是必選字段
pods.spec.volumes.gitRepo.directory: 目標目錄名稱，名稱中不能包含".."字符，"."表示將倉庫中的數據直接復制到卷目錄中，否則，為復制到卷目錄中以用戶指定的字符串為名稱的子目錄中。
pods.spec.volumes.gitRepo.revision: 特定的revision提交的哈希碼。

使用gitRepo存儲卷的POD資源運行的工作節點上必須安裝GIT程序，否則克隆倉庫的操作將無法完成，在1.12起，gitRepo存儲卷已經被廢棄。

2 實戰

1 安裝git

yum -y install git

2 創建實例并掛載存儲卷

[root@master em]# cat demo.yaml 
apiVersion: v1
kind: Pod
metadata:
    name: demo
    namespace: default
spec:
    containers:
        - name: demo
          image: nginx:1.14
          ports:
            - name: http
              containerPort: 80
          volumeMounts:
            - name: html
              mountPath: /usr/share/nginx/html
    volumes:
        - name: html
          gitRepo:
            directory: "."
            repository:  https://gitee.com/ChangPaoZhe/test
            revision: "develop"

3 部署

kubectl apply -f demo.yaml 

4 查看并測試

三 節點存儲卷

1 概述

Hostpath 類型的存儲卷時將工作節點上某個文件系統的目錄或文件掛載到POD中的一種存儲卷，可獨立于POD資源的生命周期，因此具有持久性，但其在本地，因此只能應用于特定情況下的存儲卷的使用需求。

2 核心字段

配置 hostPath 存儲卷的嵌套字段共有兩個：
1 用于指定工作節點上的目錄路徑的必選字段
pods.spec.volumes.hostPath.path

2 指定存儲卷類型type，它支持使用的卷類型包含
pods.spec.volumes.hostPath.type

A DirectoryOrCreate: 指定的路徑不存在時自動將其創建為權限為0755的空目錄，屬主屬組均為kubelet；
B Directory： 必須存在的文件路徑
C FileOrCreate： 指定的路徑不存在時自動將其創建的權限為0644的空文件，屬主和屬組同樣是kubelet。
D File： 必須存在的文件路徑
E Socket： 必須存在的socket 文件路徑
F CharDevice： 必須存在的字符設備文件路徑
G BlockDevice： 必須存在的塊設備文件路徑

3 實例

#[root@master em]# cat demo1.yaml 
apiVersion: v1
kind: Pod
metadata:
    name: demo1
spec:
    containers:
        - name: demo1
          image: ikubernetes/filebeat:5.6.7-alpine
          env:    #設置環境變量
            - name: REDIS_HOST
              value: redis.ilinux.io:6379
            - name: LOG_DEVEL
              value: info
          volumeMounts:  # 設置容器掛載 
            - name: varlog
              mountPath: /var/log
            - name: socket
              mountPath: /var/run/docker.sock
            - name: varlib
              mountPath: /var/lib/docker/containers
              readOnly: true
    volumes:
        - name: varlog  # 設置節點掛載名稱
          hostPath:  # 設置節點掛載路徑
            path: /var/log  
        - name: varlib
          hostPath:
            path: /var/lib/docker/containers
        - name: socket  
          hostPath:
            path: /var/run/docker.sock

部署

kubectl apply -f demo1.yaml 

這類Pod資源通常受控于daemonset類型的POD控制器，起運行與集群中的每個工作節點上，負責收集工作節點上系統級別的相關數據，但其不同節點的文件或許不完全相同，于是，那些要求事先必須存在的文件或目錄的滿足狀態也可能會不同，在節點中創建的文件或目錄默認僅有root可寫，若期望容器內的進程有寫權限，則要么將其設置為特權容器，要么修改節點上的目錄路徑權限。

四 網絡存儲卷

1 概述

專用的網絡存儲卷：
1 傳統的NAS或SAM設備（如 NFS，iscsi，fc）
2 分布式存儲 （clusterFS，RBD）
3 云端存儲
4 構建在各類存儲系統上的抽象管理層等

2 NFS 存儲卷

1 核心字段

pods.spec.volumes.nfs
NFS 存儲卷在POD對象終止后僅僅是被卸載而非刪除，其能夠實現調度的持久化存儲
核心字段：
pods.spec.volumes.nfs.server ： 用于指定NFS服務器的IP地址或主機名，必選字段

pods.spec.volumes.nfs.path： NFS 服務到處的文件系統路徑，必選字段

pods.spec.volumes.nfs.readOnly：是否以只讀方式掛載，默認為false。

2 實例

1 部署無密碼的NFS 服務。部署結果如下

2 配置相關實例并進行部署

apiVersion: v1
kind: Pod
metadata:
    name: demo2
    namespace: default
spec:
    containers:
        - name: demo2
          image: nginx:1.14
          ports:
            - name: http
              containerPort: 80
          volumeMounts:
            - name: html
              mountPath: /usr/share/nginx/html
    volumes:
        - name: html
          nfs:
            server: 192.168.90.110
            path: /data/nfs/v1
            readOnly: false

部署

 kubectl apply -f demo2.yaml 

查看

配置相關網頁

測試結果

.

3 GlusterFS 存儲卷

1 總述

GlusterFS （cluster filesystem）是一個開源的分布式文件系統，是水平擴展存儲解決方案gluster的核心, glusterfs 通過擴展能夠支持數PB存儲容量和處理數千客戶端，glusterfs 借助TCP/IP 或 infiniBand RDMA網絡將物理分布式的存儲資源聚集在一起，使用單一全局名稱空間來管理數據，另外，glusterfs 基于可堆疊的用戶空間設計，可為各種不同數據負載提供優異的性能，是另一種流行的分布式存儲解決方案，要配置POD資源使用glusterfs存儲卷，需滿足：
1 存在某可用的glusterfs 存儲集群
2 glusterfs 集群中創建一個能滿足POD資源數據存儲需要的卷
3 在k8S 集群內的各個節點上安裝glusterfs客戶端程序包

另外，若需要基于glusterfs使用存儲卷的動態供給機制，還需要事先部署heketi，他用于為glusterfs集群提供restful 風格的管理接口，glusterfs 幾圈及hekei 的配置包含

2 核心字段

Endpoints<string>： endpoints 資源的名稱，此資源要事先存在，用于提供gluster集群的部分節點信息作為其訪問入口，必選字段

Path <string>： 用于到glusterfs集群的卷路徑，如kube-redis，必選字段
readOnly<boolean>： 是否為只讀卷

注意
部署實例請參考 ：https://blog.csdn.net/phn_csdn/article/details/75153913?utm_source=debugrun&utm_medium=referral
需在節點上安裝
yum install -y glusterfs glusterfs-fuse

實例

[root@master all]# cat demo4.yaml 
apiVersion: v1
kind: Endpoints
metadata:
    name: gluster  #設置名稱
subsets:   
    - addresses:  # 設置其相關主機名和端口號
        - ip: 192.168.90.120
      ports:
        - port: 24007
          name: glusterd
    - addresses:
        - ip: 192.168.90.110
      ports:
        - port: 24007
          name: glusterd
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: demo-gfs-dep
    namespace: default
spec:
    replicas: 3
    selector:
        matchLabels:
            app: gfs
    template:
        metadata:
            name: demo-gfs
            namespace: default
            labels:
                app: gfs
        spec:
            containers:
                - name: demo-gfs
                  image: nginx:1.14
                  ports:
                    - name: http
                      containerPort: 80
                  volumeMounts:
                    - name: html
                      mountPath: /usr/share/nginx/html
            volumes:
                - name: html
                  glusterfs:  # 配置掛載類型
                    endpoints: gluster  # endpoint 名稱
                    path: models  # glusterfs 共享目錄的塊名稱，不是其共享目錄的目錄結構
                    readOnly: false

部署

kubectl apply -f demo4.yaml 

查看

一個節點創建一個文件夾，其他節點均可見

在其中注入內容

對象存儲節點查看

訪問測試

五 持久存儲卷

1 概述

上述網絡存儲卷的缺點是：管理員用戶必須清晰了解所用到的網絡存儲系統的訪問細節才能完成存儲卷相關的配置任務，這與kubernetes的向用戶和開發隱藏底層架構的目標相背離，對于存儲資源的好是能夠像計算資源一樣，用戶和開發人員無需了解POD資源掛載情況，無需了解存儲系統是什么設備以及位于何處，為此，kubernetes的PersistentVolume子系統在用戶與管理員之間添加了一個抽象層，從而使得存儲系統的使用和管理直接解耦

2 persistentVolume（PV）

1 總述

對底層共享存儲的抽象，將共享存儲作為一種可由用戶申請使用的資源，實現了"存儲消費"機制，通過存儲插件，PV支持使用多種網絡存儲或云端存儲等多種后端存儲系統。如NFS、RBD和Cinder等。PV 是集群級別的資源，其不屬于任何名稱空間，用戶對PV資源的使用需要PVC（persistendVolumeClaim）提出申請來完成綁定，是PV資源的消費者，其向PV申請特定大小的空間及相關的訪問模式，從而創建出PVC存儲卷，而后再由POD資源通過persistentVolumeClaim 存儲卷關聯使用。

盡管PVC使得用戶可以以抽象的方式訪問存儲資源，但很多時候還是會涉及PV的不少屬性，其兩者銜接方面的偏差必然導致用戶的需求無法及時得到有效滿足。自kubernetes 1.4 版本來時引入了storageclass資源類型，其可用于將存儲資源定義為具有顯著特性的類別（class）而不是具體的PV，用戶通過PVC 直接向意向的類別發出申請，匹配由管理員事先創建的PV，或者由其按需為用戶動態創建的PV,這樣做便免去了事先創建PV的過程。

2 創建PV

1 PV 組成部分

pv.spec.capacity  ： 用于定義當前PV的容量，支持空間設定
pv.spec.accessModes： 訪問模式，
ReadWriteOnce:  僅僅可被單節點讀寫掛載，命令行中簡寫為RWO ReadOnlyMany : 可被多個節點只讀掛載，命令簡寫為ROX 
ReadWriteMany: 可被多個節點同時讀寫掛載，命令行中簡寫為RWX 

各存儲卷支持的讀寫模式

pv.spec.persistentVolumeReclaimPolicy： PV 空間被釋放時的處理機制，可用類型為Retain（默認，保留）、recycle（回收）或 delete（刪除）
Retain 保持不動，由管理員手動處理
recycle： 空間回收，及刪除存儲卷目錄下的所有文件，目前僅NFS 和 hostPath 支持此操作
delete： 刪除存儲卷，僅部分云端存儲系統支持，如AWS  GCE  Azure disk 和 cinder 
pv.spec.volumeMode：卷類型，用于指定此卷可被用作文件系統還是裸設備，默認為文件系統
pv.spec.storageClassName：當前PV所屬的storageClass名稱，默認為空
pv.spec.mountOptions ：掛載選擇組成的列表，如ro、soft或 hard 等

2 創建PV

[root@master1 pv]# cat demo.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv1
    labels:
        app: v1
spec:
    accessModes: ["ReadWriteMany"]  #設置訪問模式，其可同時設置多個
    capacity:  #定義PV存儲大小
        storage: 5Gi  
    nfs:   #設置NFS 參數
        path: /data/v1  # 設置NFS 掛載地址
        server: 192.168.1.100  # 設置NFS服務器地址，其可以是域名
        readOnly: false  #設置其可讀寫
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv2
    labels:
        app: v2
spec:
    accessModes: ["ReadWriteOnce","ReadWriteMany"]  #設置訪問模式，其可同時設置多個
    capacity:  #定義PV存儲大小
        storage: 5Gi  
    nfs:   #設置NFS 參數
        path: /data/v2  # 設置NFS 掛載地址
        server: 192.168.1.100  # 設置NFS服務器地址，其可以是域名
        readOnly: false  #設置其可讀寫
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv3
    labels:
        app: v3
spec:
    accessModes: ["ReadWriteMany","ReadOnlyMany"]  #設置訪問模式，其可同時設置多個
    capacity:  #定義PV存儲大小
        storage: 10Gi  
    nfs:   #設置NFS 參數
        path: /data/v3  # 設置NFS 掛載地址
        server: 192.168.1.100  # 設置NFS服務器地址，其可以是域名
        readOnly: false  #設置其可讀寫
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv4
    labels:
        app: v4
spec:
    accessModes: ["ReadWriteOnce","ReadWriteMany","ReadOnlyMany"]  #設置訪問模式，其可同時設置多個
    capacity:  #定義PV存儲大小
        storage: 5Gi  
    nfs:   #設置NFS 參數
        path: /data/v4  # 設置NFS 掛載地址
        server: 192.168.1.100  # 設置NFS服務器地址，其可以是域名
        readOnly: false  #設置其可讀

3 部署

kubectl apply -f demo.yaml

4 查看

5 PV 資源狀態

Available ： 可用狀態的自由資源，尚未被PVC綁定
Bound： 已經被綁定的PVC
released： 綁定的PVC已經被刪除，但資源尚未被集群回收
Failed ： 因自動回收資源失敗而處于故障狀態

3 創建PVC

1 總述

PersistentVolumeClaim 是存儲卷類型資源，通過申請占用某個PV 而創建，其與PV是一對一的關系，用戶無需關心底層實現細節，只需指定目標空間大小，訪問模式、PV標簽選擇器和storageClass等相關信息即可。

2 PVC 核心字段

pv.spec.accessModes： PVC訪問模式，與PV定義相同
        ReadWriteOnce:  僅僅可被單節點讀寫掛載，命令行中簡寫為RWO 
        ReadOnlyMany : 可被多個節點只讀掛載，命令簡寫為ROX 
        ReadWriteMany: 可被多個節點同時讀寫掛載，命令行中簡寫為RWX 
pvc.spec.resources： 當前PVC 存儲卷需要占用的資源量，目前僅支持空間大小，其包含limit 和 request
pvc.spec.selector： 定義PVC使用標簽選擇PV，只有滿足此選擇的PV才可能被關聯至該PVC 
pvc.spec.storageClassName： 所依賴的存儲類的名稱
pvc.spec.volumeMode： 卷類型，用于指定此卷可被用于文件系統該是裸格式的塊設備，默認是文件系統
pvc.spec.volumeName： 用于直接指定要綁定的PV的卷名 

3 創建PVC

[root@master1 pv]# cat demopvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: pvc1
    labels:
        app: pvc1
spec:
    accessModes: ["ReadWriteMany"]
    resources:
        requests:
            storage: 5Gi
    selector:  #使用標簽進行選擇為PV2
        matchLabels:
            app: v2
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: pvc2
    labels:
        app: pvc2
spec:
    accessModes: ["ReadWriteOnce","ReadWriteMany","ReadOnlyMany"]   # 使用模式匹配只能是PV4
    resources:
        requests:
            storage: 5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: pvc3
    labels:
        app: pvc3
spec:
    accessModes: ["ReadWriteMany"]
    resources:  #使用大小匹配為PV3
        requests:
            storage: 8Gi

創建PVC

kubectl apply -f demopvc.yaml 

查看服務

4 PVC 綁定POD

1 核心字段

pods.spec.volumes.persistentVolumeClaim.claimName
綁定的PVC的名稱,必選字段

pods.spec.volumes.persistentVolumeClaim.readOnly
綁定的模式

2 實例

#[root@master1 pv]# cat pod.yaml 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: dem-po
    namespace: default
spec:
    selector:
        matchLabels:
            app: demo1
    replicas: 3
    template:
        metadata:
            name: dem-dem
            namespace: default
            labels:
                app: demo1
        spec:
            containers:
                - name: dem-po
                  image: nginx:1.14
                  volumeMounts:
                    - name: html
                      mountPath: /usr/share/nginx/html
            volumes:
                - name: html
                  persistentVolumeClaim:
                    claimName: pvc1

部署

kubectl apply -f pod.yaml 

查看

測試

4 存儲類

1 概念

存儲類（StorageClass）簡稱sc，其是kubernetes資源類型中的一種，是由管理員為管理PV方便而按需創建的類別，其可理解為PV的特性描述

通過向后端存儲傳輸信息而達到和前端匹配的效果

存儲類的好處之一就是支持PV的動態創建，用于用到持久性存儲時，需要通過創建PVC來綁定匹配的PV，此類操作需求量較大，或當管理員創建的PV無法滿足PVC 需求時，系統按PVC 的需求標準動態創建適配的PV會為存儲管理帶來極大靈活性。
PVC 通過對存儲類的申請而獲取到PV

存儲類對象的名稱至關重要，是用戶調用的標識，創建存儲類，除了名稱外，還需要為其定義三個關鍵字段 : provisioner（sc.provisioner 供給方）、parameter (參數 sc.provisioner)和 reclaimPolicy（回收策略sc.reclaimPolicy）

2 核心字段

1 storageClass  spec 
        storageClass  Spec 中的字段是定義存儲類時最重要的字段，其包含五個可用字段
        provisioner（供給方）： 即提供了存儲資源的存儲系統，存儲類需要依賴provisioner 來判定要使用的存儲插件以便適配到目標存儲系統，K8S 內建有多種供給方，其都是以kubernetes.io 為前綴的，其也支持用戶依據kubernetes規范自定義 provisioner。
2 parameters （參數）: 存儲類使用參數描述要關聯的存儲卷，不同的provisioner可用的參數各不相同 
3 reclaimPolicy ： 定義回收策略。可為delete 和retain，
4 volumBindingMode ： 定義如何為PVC 完成供給和綁定，默認為  "volumeBindin  immediate" 此選項僅在啟動了存儲卷調度功能時才能生效 
5 mountOptions：由當前類動態創建的PV的掛載選項列表 

注意
上述所需的環境請參考 :https://www.cnblogs.com/breezey/p/8849466.html

kubernetes 節點上須有heketi 的key，需要有heketi-client 軟件，必須要加載內核模塊modprobe dm_thin_pool

如果有密碼認證，則編碼之前hekei的密碼

下屬實例中有密碼認證

apiVersion: v1
kind: Secret
metadata:
    name: heketi-secret
    namespace: default
stringData:  # 設置其密碼
    key: Admin
type: kubernetes.io/glusterfs
---
apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
    name: glusterfs
    namespace: default
provisioner: kubernetes.io/glusterfs
parameters:
    resturl: "http://192.168.90.110:8080"    # 調用其接口
    clusterid: "84d3dcbeb048089c18807b7be943d219"  #查詢其ID并配置
    restauthenabled: "true"  # 認證模式為true
    restuser: "admin"  # 認證用戶名
    secretNamespace: "default"  # 名稱空間
    secretName: "heketi-secret"  # 認證調用secret名稱
    #restuserkey: "adminkey" #此處可以以明文的形式寫成密碼
    gidMin: "40000"  
    gidMax: "50000"
    volumetype: "replicate:2"  #設置其類型

部署

kubectl apply -f sc.yaml

查看

2 動態PV供給

動態PV供給的啟用，需要實現由管理員創建至少一個存儲類，不同的provisoner 的創建方式各不相同。

支出存儲類的存儲資源

目前，在PVC的定義中指定使用的存儲類資源的方式有兩種：一種是使用pvc.spec.storageClassName，另一種是使用"volume.beta.kubernetes.io/storage-class" 資源注解，建議使用第一種方式，以免出現設置不同導致的錯誤配置問題。
任何支持PV動態供給的存儲系統都可以在定義為存儲類后由PVC動態申請使用，存儲卷是必備資源，隨著規模的變化，其也會隨之而變動

配置PVC

#[root@master all]# cat pvc1.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: glusterfs-nginx
  namespace: default
  annotations:
    volume.beta.kubernetes.io/storage-class: "glusterfs"  #此處指定為glusterfs模式獲取
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

部署

kubectl apply -f pvc1.yaml 

查看

5 PV 和PVC 生命周期

1總述

PV 是集群級別資源，而PVC則是資源需求，PVC發起對PV的申請，則兩個綁定，其PV和PVC是一一對應的關系，可用于響應PVC的PV必須能夠容納PVC的請求條件

2 存儲供給

1 靜態供給

靜態供給是由集群管理員手動創建的一定數量的PV的資源供給方式，這些PV負責處理存儲系統的細節，并將由其抽象成易用的存儲資源供用戶使用，靜態提供的PV可能屬于某存儲類，也可能沒有存儲類

2 動態供給

不存在某靜態的PV匹配到用戶的PVC申請時，kubernetes集群會嘗試為PVC動態創建符合需求的PV，此即為動態供給，這種方式依賴于存儲類的綁定，PVC必須向一個事先存在的存儲類發起動態分配PV的請求，沒有指定存儲類的PVC請求將會被禁止使用動態創建PV的方式。

3 存儲綁定

用戶基于一系列存儲需求和訪問模式定義好PVC后，kubernetes系統的控制器即會為其查找匹配的PV，并于找到之后二者之間建立其關系，而后他們二者狀態轉換為綁定狀態，若PV是為PVC而動態創建的，則該PV專用于其PVC。
若是無法為PVC找到可匹配的PV，則PVC將一直處于未綁定狀態，直到符合條件的PV出現并完成綁定方才可用

1 存儲使用
pod資源基于pod.spec.volumes.persistentVolumeClaim卷類型的定義，將選定的PVC關聯為存儲卷，而后即可為內部的容器使用，對于支持多中訪問方式的存儲卷來說，用戶需要額外指定使用模式，一旦完成將存儲卷掛載至POD對象內的容器中，其應用即可使用關聯的PV提供存儲空間

2 PVC 保護
為了避免使用中的存儲卷被移除而導致數據丟失，自kubernetes 1.9 開始當POD資源占用此PVC時，其不能刪除PVC。

4 存儲回收

完成存儲卷的使用目標之后，即可刪除PVC對象以便進行資源回收，策略如下

1 留存

留存就是在刪除PVC后，kubernetes不會自動刪除PVm而僅僅是將其置于釋放狀態，不過，此狀態的PV尚且不能被其他PVC申請綁定，因為之前綁定成功的數據來存在，需要由管理員手動決定其后續處理方案，這就意味著，如果想要再次使用此類PV資源，則需要由管理員進行下面操作
1 刪除PV，這之后，此PV的數據仍然存在于外部存儲
2 手工清理存儲之上遺留的數據
3 手工刪除存儲系統級的存儲卷釋放空間，以便再次創建或直接重新創建PV

2 回收

如果可被底層存儲插件支持，資源回收策略會在存儲卷上執行數據刪除操作并讓PV資源再次變為可被claIm。另外，管理員可配置一個自定義的回收器POD模板，以便執行自定義回收操作

3 刪除 delete

對于支持delete回收策略的存儲插件來說，在PVC被刪除后會直接移除PV對象，同時移除的還有PV相關的外部存儲系統上的存儲資產，支持這種操作的存儲系統有AWS EBS、GCE PD、Azure Disk 或 Cinder，動態創建的PV資源的回收區別于相關存儲類上的定義，存儲類上相關的默認策略為Delete。

4 擴展PVC

kubernetes 從1.8版本開始增加了擴展PV空間的特定，目前其支持的擴展PVC 機制的存儲卷有：
gcePersistentDisk
awsElasticBlockStore
Cinder
glusterfs
rbd

"PersistentVolumeClaimResize"準入插件負責對支持空間大小變動的存儲卷執行更多的驗證操作，管理員需要事先啟用此插件才能使用PVC擴展機制，

對于包含文件系統的存儲卷來說，只有在新的POD資源基于讀寫模式開始使用PVC時才會執行文件系統大小的調整工作，換句話說，如果某被擴展的存儲卷已經由POD資源使用，則需要重新創建此POD對象才能出發文件系統大小的調整操作。支持空間調整的文件系統有XFS、EXT3和EXT4