kubernetes之K8s核心原理--第二篇（五）

六、 共享存儲原理

  Kubernetes對有狀態或者對數據需要持久化的應用，不僅需要將容器內的目錄掛載到宿主機的目錄或者empDir臨時存儲卷，而且需要更加可靠的存儲來保存應用產生的重要數據，以便于容器應用重建以后，仍然可以使用之前的數據。為了能夠屏蔽底層存儲實現的細節，讓用戶方便使用，同時能讓管理員方便管理，kubernetes從v1.0版本就引入了persistentVolume和persistentVolumeCliam兩個資源對象來實現對存儲的管理。
  persistentVolume（PV）是對底層網絡共享存儲的抽象，將共享存儲定義為一種“資源”，比如節點也是一種容器應用可以消費的資源。PV由管理員進行創建和配置，它與共享存儲的具體實現直接相關，例如：GlusterFS、iSCSI、RBD或者GEC/AWS公有云提供的共享存儲，通過插件式的機制完成與共享存儲的對接，以供應用訪問和使用。  persistentVolumeCliam（PVC）則是用戶對于存儲資源的一個“申請”。就像Pod“消費”node的資源一樣，PVC會“消費”PV資源。PVC可以申請特定的存儲空間和訪問模式。
  使用PVC“申請”到一定的存儲空間仍然不足以滿足應用對于存儲設備的各種需求。通常應用程序都會對存儲設備的特性和性能有不同的要求。包括讀寫速度、并發性能、數據冗余等更高的要求，kubernetes從v1.4開始引入了一個新的資源對象storageClass，用于標記存儲資源的特性和性能。到v1.6版本時，storageClass和動態資源應用機制得到了完善，實現了存儲卷的按需創建。
那么下面小編將對PV、PVC、storageClass和動態資源供應等共享存儲管理機制進行詳細說明。

1. PV詳解介紹

  PV作為存儲資源，主要包括存儲能力、訪問模式、存儲類型、回收策略、后端存儲類型等關鍵信息的設置。以下面配置為例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  nfs:
    path: /tmp
    server: 172.17.0.2

上面這個例子就創建了一個5G空間，訪問模式為ReadWriteOnce,存儲類型為”slow”(這里需要要求系統已經創建了名為slow的storageClass 資源對象)，回收策略為“recycle”，并且后端存儲類型為nfs（并設置了NFS server的IP和路徑）
Kubernetes支持的PV的類型如下：
 ? GCEPersistentDisk #GEC公有云提供的PersistentDisk
 ? AWSElasticBlockStore #AWS公有云提供的ElasticBlockStore
 ? AzureFile #Azure公有云提供的File
 ? AzureDisk #AzureDisk提供的Disk
 ? FC (Fibre Channel)
 ? Flexvolume
 ? Flocker
 ? NFS #網絡文件系統
 ? iSCSI
 ? RBD (Ceph Block Device) #Ceph存儲塊
 ? CephFS
 ? Cinder (OpenStack block storage) #openStack Cinder塊存儲
 ? Glusterfs
 ? VsphereVolume
 ? Quobyte Volumes
 ? HostPath #宿主機目錄，僅用于單機測試
 ? Portworx Volumes
 ? ScaleIO Volumes
 ? StorageOS

（1） PV的關鍵配置參數

① 存儲能力（capacity）
 描述存儲設備具備的能力，目前僅支持對存儲空間的設置（storage：xxx）

② 訪問模式（Access Modes）
 對PV進行訪問模式的設置，用于描述用戶應用對存儲資源的訪問權限。訪問模式如下：
  ? ReadWriteOnce：讀寫權限，并且只能被單個node掛載
  ? ReadOnlyMany：只讀權限，可以被多個node掛載
  ? ReadWriteMany：讀寫權限，可以被多個node掛載
注意：PV可以可能支持多種訪問模式，但PV在掛載時只能使用一種訪問模式，多種訪問模式不能同時生效。
對于不同類型的PV有不同的訪問模式，在PV的定義時需要與他們匹配：

③ 存儲類別（class）
 PV可以設定其存儲的類別，通過storageClassName參數指定一個storageClass資源對象的名稱。具有特定“類別”的PV只能與請求了該“類別”的PVC進行綁定。未設定“類別”的PV則只能與不請求任何“類別”的PVC進行綁定。storageClass資源對象會在后面的動態資源供應中大展神威。

④ 回收策略（Reclaim Policy）
 目前支持以下三種回收策略：
  ? 保留（Retain）：保留數據，需要手工處理
  ? 回收空間（Recycle）：簡單清除文件的操作（例如執行rm -rf /xx/*）
  ? 刪除（Delete）：與PV相連的后端存儲完成volume的刪除操作（如AWS EBS、GCE PD、Azure Disk、OpenStack Cinder等設備的內部volume清理）
注意：目前只有NFS和hostPath支持“Recycle”，AWS EBS、GCE PD、Azure Disk、OpenStack Cinder支持“Delete”。

（2） PV的生命周期

 某個PV在生命周期中，可能處于以下4個節點之一：
  ? Available：可用狀態，還與某個PVC綁定
  ? Bound：已經與某個PVC綁定
  ? Released：綁定的PVC已經刪除，資源已經釋放，但沒有被集群回收
  ? Failed：自動資源回收失敗

（3） PV掛載參數

 在將一個PV掛載到一個node上時，根據后端存儲的特點，可能需要設置額外的掛載參數，目前可以通過在PV的定義中，設置一個名為“volume.beta.kubernetes.io/mount/options”的annotation來實現。下面小編通過一個gcePersistentDisk設置掛載參數為例：

apiVersion: "v1"
kind: PersistentVolume
metadata:
  name: gce-disk-1
  annotations:
    volume.beta.kubernetes.io/mount/options: discard
sepc:
  capacity: 
    storage: 10Gi
  accessModes:
   - ReadWriteOnce
   gcePersistentDisk:
     fsType: ext4
     pdName: gce-disk-1

2. PVC詳細介紹

  上面我們了解了PV的定義，這里我們就使用它，這時就需要PVC了。PVC作為用戶對存儲資源的需求申請，主要包括存儲空間申請、訪問模式。PV選擇條件和存儲類別等信息的設置。
 接下來小編也是通過一個例子，向大家介紹如果定義PVC去使用PV:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
sepc:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

 申請8G空間，訪問模式為“ReadWriteOnce”、PV選擇條件包括標簽為“release=stable”并且包含條件為“environment in dev”的標簽，存儲類別為slow（系統中已經存在）。
 其中對PVC的關鍵配置詳細介紹：
  ? 資源請求（resources）：僅支持存儲空間大小請求
  ? 資源請求（resources）：僅支持存儲空間大小請求
  ? PV的選擇條件：通過label selector去篩選可以使用的PV，系統將根據標簽找到合適得到PV，并且將PV與PVC綁定
  ? 存儲類別：PVC在定義時可以設定需要的后端存儲的類別，以降低對后端存儲特性的依賴。只有設置了該class的PV才能被系統篩選出來，并且與該PVC綁定
 這里針對PVC是否設置class需求，小編進行詳細的說明一下：
  這里分為兩種情況：
   ? 系統啟用了defaultStorageClass
    ? 如果啟用了defaultStorageClass但是，系統中不存在默認的storageClass，那么等效于不啟用defaultStorageClass的情況
    ? 如果啟用了defaultStorageClass并且系統中有默認的storageClass，則系統自動的為PVC創建一個PV（使用默認的defaultStorageClass），并將它們綁定
   ? 系統未啟用defaultStorageClass
    ? 如果設置了storageClass為“”或者沒有設置storageClass字段，那么只能選擇未設定storageclass的PV與之進行匹配和綁定
 設置默認的storageClass的方法是，在storageClass上定義一個annotation“storageclass.kubernetes.io/is-default-class=true”,但是不能給多個storageClass都設置annotation，如果這樣的話由于不唯一，系統無法為PVC創建相應的PV。
使用PV與PVC綁定的注意項：
? PV和PVC都受namespace的 限制，只有相同namespace中的PV和PVC才能綁定，并只有相同namespace下pod才能掛載PVC。
? 當在PVC定義中同時設置了selector和storageClassName，只有二者同時滿足條件才能將PV和PVC綁定。

3. PV和PVC的生命周期

PV可以看做可用的存儲資源，PVC則是對存儲資源的請求，PV和PVC的相互關系如下圖所示：

接下來由圖我們逐一介紹：

（1） 資源供應（provisioning）

 Kubernetes支持兩種資源供應模式：靜態模式和動態模式。資源供應的結果就是創建好的PV。
  ? 靜態模式：集群管理員手工創建許多PV，在定義PV時需要將后端存儲的特性進行設置。
  ? 動態模式：集群管理員無須手動創建PV，而是通過storageClass的設置對后端存儲進行描述，標記為某種“類型”。此時要求PVC對存儲的類型進行聲明，系統將自動完成PV的創建于PVC的綁定。

（2） 資源綁定（binding）

 在用戶定義好PVC之后，系統將根據PVC對存儲資源的請求在已經存在的PV中選擇一個滿足PVC要求的PV，一旦找到，就將該PV與用戶定義的PVC進行綁定，然后用戶的應用就可以使用這個PVC。如果系統中沒有滿足PVC要求的PV，PVC則會無限期的處于pending狀態，直到等待系統管理員創建了一個符合其要求的PV。PV一旦綁定到某個PVC上，就被這個PVC獨占，不能與其他的PVC進行綁定了。這樣的話容易造成資源的浪費，如果使用的是動態模式，則系統在為PVC找到合適的storageClass后將自動創建一個PV并完成與PVC的綁定。

（3） 資源使用（Using）

 Pod使用volume的定義，將PVC掛載到容器內的某個路徑進行使用。Volume的類型為“persistentVolumeClaim”，在后面的示例中再進行詳細的說明。在容器應用掛載了一個PVC之后，就能被持續獨占使用。不過，多個pod可以掛載同一個PVC。

（4） 資源釋放

 當用戶對存儲資源使用完畢之后，用戶可以刪除PVC，與該PVC綁定的PV將會被標價為“已釋放”，但還不能立刻與其他PVC進行綁定。通過之前PVC寫入的數據可能還留在存儲設備上，只有在清除之后該PV才能再次使用。

（5） 資源回收

 對于PV，管理員可以設置回收策略，用于設置與之綁定的PVC釋放資源之后，對于遺留數據如何處理。只有PV的存儲空間完成回收，才能供新的PVC綁定和使用。

 最后小編通過兩幅圖，來介紹一下靜態資源供應模式和動態資源供應模式的原理，為下面一節內容做鋪墊：
      
               靜態模式下的PV和PVC原理

      
              動態模式下storageClass、PV、PVC原理

4. StorageClass詳細介紹

（1） StorageClass介紹以及簡單定義

  StorageClass作為對存儲資源的抽象定義，對用戶設置的PVC申請屏蔽后端存儲的細節，一方面減輕用戶對于存儲資源細節的關注，另一方面也減輕了管理員手工管理PV的工作，由系統自動完成PV的創建和綁定，實現了動態的資源供應。
  對于StorageClass的定義主要包括：名稱、后端存儲的提供者和后端存儲的相關參數配置。StorageClass一旦被創建出來，將無法修改。如需要修改，只能刪除原先創建的StorageClass重新構建。下面是一個定義StorageClass的例子：

kind: storageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type:  gp2

上面的例子就定義了一個名為“standard”，提供者為“aws-ebs”，其參數為gp2的StorageClass。
其中定義StorageClass中有兩個重點參數：
? provisioner（提供者）:描述存儲資源的提供者，也可以看做是后端存儲驅動。目前provisioner都是以“Kubernetes.io/”為開頭
? parameters（參數）：后端資源提供者的參數設置，不同的provisioner包括不同的參數設置

（2）幾種常見的provisioner對StorageClass的定義：

①AWS EBS存儲卷

kind: storageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner:
  kubernetes.io/aws-ebs
parameters:
  type: io1
  zone: us-east-1d
  iopsPerGB: "10"

參數說明：
? type：可選有：io1、gp2、sc1、st1，默認是gp2
? zone：AWS zone名稱
? iopPerGB：僅用于io1類型的volume，意為每秒每G的I/O操作數量
? encrypted：是否加密
? kmsKeyId：加密時的Amazon Resource Name
② GCE PD存儲卷

kind: storageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  zone: us-centrall-a

參數說明：
? type：可選項有：pd-standard、pd-ssd，默認是pd-standard
? zone：GCE zone名稱
③ GlusterFS存儲卷

apiVersion: storage.k8s.io/v1
kind: storageClass
metadata:
  name: slow
provisioner: kubernetes.io/glusterfs
parameters:
  resturl:  "http://127.0.0.1:8081"
  clusterid: 44ad5as1fd5ae1fde1fwe1d5we1d5
  restauthenabled: "true"
  restuser: "admin"
  secreNamespace: "default"
      secreName: "heketi-sercret"
  gidMin: "40000"
  gidMax: "50000"
  volumetype: "replicate:3"

參數說明：
? resturl：Gluster REST服務（Heketi）URL地址，用于自動完成GlusterFSvolume的設置
? restauthenabled：訪問Gluster REST服務啟用安全機制
? restuser：訪問Gluster REST服務的用戶名
? secretNamespace和secretName：保存訪問Gluster REST服務密碼的Secret的資源對象名
? clustered：GlusterFS 的cluster ID
? gidMin和gidMax：storageClass的GID的范圍，用于動態創建資源供應時PV設置的GID
? volumetype：GlusterFS的volume類型設置，例如：replicate:3表示replicate類型3個副本
④ OpenStack Cinder存儲卷

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold
provisioner: kubernetes.io/cinder
parameters:
  type: fast
  availability: nova

參數說明：
? type：cinder的volumetype，默認為空
? availability：availability zone ，默認為空

（3） 設置默認的storageClass

  要在系統中設置一個默認的storageClass，首先需要啟動名為“DefaultStorageClass”的admission controller，即在kube-apiserver的命令參數中的--admission-control中增加：DefaultStorageClass
例：--admission-control=“xxx,xxx,xxx, DefaultStorageClass”

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold
  annotations: storageclass.beta.kubernetes.io/is-default-class="true"
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

然后創建這個storageClass，此時我們在通過命令可查看：

[::root]kubelet get sc -n=xxx

注意：默認的storageClass只能設置一個，否則系統會因為多個default引起沖突，而不知道篩選哪一個為默認的，最終導致默認的storageClass不生效。

5. 動態存儲管理實戰，GlusterFS

  這個案例從定義storageClass、創建storageFS和Heketi服務、用戶申請PVC到創建Pod使用存儲資源，對storageClass和動態資源分配進行詳細說明，進一步分析kubernetes的存儲機制。
  這里的案例是參考至：
https://www.cnblogs.com/xiaoqshuo/p/10096682.html 和《kubernetes權威指南》

（1） 概念介紹

1） 分布式文件系統-GlusterFS概述

  GlusterFS是Scale-Out存儲解決方案Gluster的核心，它是一個開源的分布式文件系統，具有強大的橫向擴展能力，通過擴展能夠支持數PB存儲容量和處理數千客戶端。GlusterFS借助TCP/IP或InfiniBand RDMA網絡將物理分布的存儲資源聚集在一起，使用單一全局命名空間來管理數據。GlusterFS基于可堆疊的用戶空間設計，可為各種不同的數據負載提供優異的性能。
  GlusterFS支持運行在任何標準IP網絡上標準應用程序的標準客戶端，用戶可以在全局統一的命名空間中使用NFS/CIFS等標準協議來訪問應用數據。GlusterFS使得用戶可擺脫原有的獨立、高成本的封閉存儲系統，能夠利用普通廉價的存儲設備來部署可集中管理、橫向擴展、虛擬化的存儲池，存儲容量可擴展至TB/PB級。
  GlusterFS以原始數據格式（如EXT3、EXT4、XFS、ZFS）儲存數據，并實現多種數據自動修復機制。
架構圖：

這里只是帶大家了解一下GlusterFS，便于理解后面PVC掛載的內容，無需過多深入。

2） Heketi服務

  Heketi服務是一個提供REST ful API管理GlusterFS卷框架，并能夠在kubernetes、openstack等云平臺上實現動態存儲資源供應，支持GlusterFS多集群管理，便于管理員對GlusterFS進行操作，如下圖簡單介紹了Heketi服務的作用：

（2） 實戰搭建

① 在各個計劃用于GlusterFS的node上安裝GlusterFS客戶端

#yum install glusterfs glusterfs-fuse -y

② 在master的kube-apiserver服務和待啟動GlusterFS的各個node上的kubelet服務的啟動參數中入：--allow-privileged=true
③ 載入指定的個別模塊

modprobe dm_snapshot 
modprobe dm_mirror 
modprobe dm_thin_pool

④ 為要部署GlusterFS的node打上標簽，為了將GlusterFS容器定向部署到安裝了GlusterFS的node上

[root@k8s-master01 ~]# kubectl label node k8s-node-1 storagenode=glusterfs 
node/k8s-node-1 labeled 
[root@k8s-master01 ~]# kubectl label node k8s-node-2 storagenode=glusterfs 
node/k8s-node-2 labeled 
[root@k8s-master01 ~]# kubectl label node k8s-node-3 storagenode=glusterfs 
node/k8s-node-3 labeled

⑤ 創建GlusterFS管理服務容器集群
#glusterfs-daemonset.yaml：

kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: glusterfs
  labels:
    glusterfs: daemonset
  annotations:
    description: GlusterFS DaemonSet
    tags: glusterfs
spec:
  template:
    metadata:
      name: glusterfs
      labels:
        glusterfs-node: pod
    spec:
      nodeSelector:
        storagenode: glusterfs
      hostNetwork: true
      containers:
      - image: gluster/gluster-centos:latest
        name: glusterfs
        volumeMounts:
        - name: glusterfs-heketi
          mountPath: "/var/lib/heketi"
        - name: glusterfs-run
          mountPath: "/run"
        - name: glusterfs-lvm
          mountPath: "/run/lvm"
        - name: glusterfs-etc
          mountPath: "/etc/glusterfs"
        - name: glusterfs-log
          mountPath: "/var/log/glusterfs"
        - name: glusterfs-config
          mountPath: "/var/lib/glusterd"
        - name: glusterfs-dev
          mountPath: "/dev"
        - name: glusterfs-misc
          mountPath: "/var/lib/misc/glusterfsd"
        - name: glusterfs-cgroup
          mountPath: "/sys/fs/cgroup"
          readOnly: true
        - name: glusterfs-ssl
          mountPath: "/etc/ssl"
          readOnly: true
        securityContext:
          capabilities: {}
          privileged: true
        readinessProbe:
          timeoutSeconds: 3
          initialDelaySeconds: 60
          exec:
            command:
            - "/bin/bash"
            - "-c"
            - systemctl status glusterd.service
        livenessProbe:
          timeoutSeconds: 3
          initialDelaySeconds: 60
          exec:
            command:
            - "/bin/bash"
            - "-c"
            - systemctl status glusterd.service
      volumes:
      - name: glusterfs-heketi
        hostPath: 
         path: "/var/lib/heketi"
      - name: glusterfs-run
      - name: glusterfs-lvm
        hostPath:
          path: "/run/lvm"
      - name: glusterfs-etc
        hostPath:
          path: "/etc/glusterfs"
      - name: glusterfs-log
        hostPath:
          path: "/var/log/glusterfs"
      - name: glusterfs-config
        hostPath:
          path: "/var/lib/glusterd"
      - name: glusterfs-dev
        hostPath:
          path: "/dev"
      - name: glusterfs-misc
        hostPath:
          path: "/var/lib/misc/glusterfsd"
      - name: glusterfs-cgroup
        hostPath:
          path: "/sys/fs/cgroup"
      - name: glusterfs-ssl
        hostPath:
          path: "/etc/ssl"

#kubelet create -f glusterfs-daemonset.yaml #創建
#kubectl get pods #查看
NAME READY STATUS RESTARTS AGE 
glusterfs-fvxh7 1/1 Running 0 47m 
glusterfs-jjw7b 1/1 Running 0 47m 
glusterfs-td875 1/1 Running 0 47m

⑥創建Heketi服務
在部署Heketi之前，需要為他創建一個ServiceAccount對象：
#heketi-service-account.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: heketi-service-account

#kubelet create -f heketi-service-account.yaml

#heketi-deployment-svc.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: deploy-heketi
  labels:
    glusterfs: heketi-deployment
    deploy-heketi: heketi-deployment
  annotations:
    description: Defines how to deploy Heketi
spec:
  relicas: 1
  template:
    metadata:
      name: deploy-heketi
      labels:
        glusterfs: heketi-pod
    spec:
      ServiceAccountName: heketi-service-account
      containers:
      - image: heketi/heketi:dev
        name: deploy-heketi
        env:
        - name: HEKETI_EXECUTOR
          value: kubernetes
        - name: HEKETI_FSTAB
          value: "/var/lib/heketi/fstab"
        - name: HEKETI_SNAPSHOT_LIMIT
          value: "14"
        - name: HEKETI_KUBE_GLUSTER_DAEONSET
          value: "y"
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: db
          mountPath: "/var/lib/heketi"
        readinessProbe:
          timeoutSeconds: 3
          initialDelaySeconds: 3
          httpGet:
            path: "/hello"
            port: 8080
        livenessProbe:
          timeoutSeconds: 3
          initialDelaySeconds: 30
          httpGet:
            path: "/hello"
            port: 8080
    volumes:
    - name: db
      hostPath:
        path: "/heketi-data"
--- 
kind: Service
apiVersion: v1
metadata:
  name: deploy-heketi
  labels:
    glusterfs: heketi-service
    deploy-heketi: support
  annotations: 
    description: Exposes Heketi Service 
spec:
  selector:
    name: deploy-heketi
  ports:
  - name: deploy-heketi
    port: 8080
    targetPort: 8080

#kubelete create -f heketi-deployment-svc.yaml

⑦ 為Heketi設置GlusterFS集群
在Heketi能管理GlusterFS集群之前，需要為其設置GlusterFS集群信息。可以使用json配置文件傳入，并且Heketi要求一個GlusterFS集群至少有3各節點。
#topology.json

{
    "clusters": [
        {
            "nodes": [
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "k8s-node-1"
                            ],
                            "storage": [
                                "192.168.2.100"
                            ]
                        },
                        "zone": 1
                    },
                    "devices": [
                        {
                            "name": "/dev/sdb"
                        }
                    ]
                },
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "k8s-node-2"
                            ],
                            "storage": [
                                "192.168.2.101"
                            ]
                        },
                        "zone": 1
                    },
                    "devices": [
                        {
                            "name": "/dev/sdc"
                        }
                    ]
                },
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "k8s-node-3"
                            ],
                            "storage": [
                                "192.168.2.102"
                            ]
                        },
                        "zone": 1
                    },
                    "devices": [
                        {
                            "name": "/dev/sdb"
                        }
                    ]
                }
            ]
        }
    ]
}

然后進入Heketi的容器中，執行：

#export HEKETI_CLI_SERVER=http://localhost:8080
#heketi-cli topology load –json= topology.json

完成以上操作，Heketi就完成了GlusterFS集群的創建，同時在GlusterFS集群的各個節點上的/dev/sdb盤上成功創建了PV和VG。
注意：/dev/sdb一定要是未創建文件系統的裸設備。
#查看GFS信息

[root@k8s-node-1 kubernetes]# heketi-cli topology info

（3） 測試

集群創建成功之后，當然我們要試試，storageClass的功能能不能用啊：
① 定義storageClass
#storageclass-gluster-heketi.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-heketi
provisioner: kubernetes-io/glusterfs
parameters:
  resturl: "http://172.17.2.2:8080"
  restauthenabled: "false"

② 定義PVC
#pvc-gluster-heketi.yaml(使用動態資源供應模式)

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-gluster-heketi
spec:
  storageClassName: gluster-heketi
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

#可以通過命令查看pv，和自動創建的PVC

#kubelet get pvc
#kubelet get pv

③ 使用pod掛載PVC
#pod-use-pvc.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-use-pvc
spec:
  containers:
  - name: pod-use-pvc
    image: busybox
    command:
    - sleep
    - "3600"
    volumeMounts:
    - name: gluster-volume
      mountPath: "/pv-data"
      readOnly: false
  volumes:
  - name: gluster-volume
    persistentVolumeClaim:
      claimName: pvc-gluster-heketi

#kubelet create -f pod-use-pvc.yaml #創建這個pod

然后進入容器：

#kubelet exec -it pod-use-pvc /bin/sh

在其中的/pv-data 目錄創建文件，然后驗證文件在GlusterFS集群中是否生效！

文章內容參考至《kubernetes權威指南》