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

六、 共享存儲原理

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

1. PV詳解介紹

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

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

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

（1） PV的關(guān)鍵配置參數(shù)

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

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

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

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

（2） PV的生命周期

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

（3） PV掛載參數(shù)

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

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詳細(xì)介紹

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

3. PV和PVC的生命周期

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

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

（1） 資源供應(yīng)（provisioning）

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

（2） 資源綁定（binding）

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

（3） 資源使用（Using）

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

（4） 資源釋放

 當(dāng)用戶對存儲資源使用完畢之后，用戶可以刪除PVC，與該P(yáng)VC綁定的PV將會被標(biāo)價為“已釋放”，但還不能立刻與其他PVC進(jìn)行綁定。通過之前PVC寫入的數(shù)據(jù)可能還留在存儲設(shè)備上，只有在清除之后該P(yáng)V才能再次使用。

（5） 資源回收

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

 最后小編通過兩幅圖，來介紹一下靜態(tài)資源供應(yīng)模式和動態(tài)資源供應(yīng)模式的原理，為下面一節(jié)內(nèi)容做鋪墊：
      
               靜態(tài)模式下的PV和PVC原理

      
              動態(tài)模式下storageClass、PV、PVC原理

4. StorageClass詳細(xì)介紹

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

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

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

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

（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"

參數(shù)說明：
? type：可選有：io1、gp2、sc1、st1，默認(rèn)是gp2
? zone：AWS zone名稱
? iopPerGB：僅用于io1類型的volume，意為每秒每G的I/O操作數(shù)量
? 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

參數(shù)說明：
? type：可選項有：pd-standard、pd-ssd，默認(rèn)是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"

參數(shù)說明：
? resturl：Gluster REST服務(wù)（Heketi）URL地址，用于自動完成GlusterFSvolume的設(shè)置
? restauthenabled：訪問Gluster REST服務(wù)啟用安全機(jī)制
? restuser：訪問Gluster REST服務(wù)的用戶名
? secretNamespace和secretName：保存訪問Gluster REST服務(wù)密碼的Secret的資源對象名
? clustered：GlusterFS 的cluster ID
? gidMin和gidMax：storageClass的GID的范圍，用于動態(tài)創(chuàng)建資源供應(yīng)時PV設(shè)置的GID
? volumetype：GlusterFS的volume類型設(shè)置，例如：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

參數(shù)說明：
? type：cinder的volumetype，默認(rèn)為空
? availability：availability zone ，默認(rèn)為空

（3） 設(shè)置默認(rèn)的storageClass

  要在系統(tǒng)中設(shè)置一個默認(rèn)的storageClass，首先需要啟動名為“DefaultStorageClass”的admission controller，即在kube-apiserver的命令參數(shù)中的--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

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

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

注意：默認(rèn)的storageClass只能設(shè)置一個，否則系統(tǒng)會因為多個default引起沖突，而不知道篩選哪一個為默認(rèn)的，最終導(dǎo)致默認(rèn)的storageClass不生效。

5. 動態(tài)存儲管理實(shí)戰(zhàn)，GlusterFS

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

（1） 概念介紹

1） 分布式文件系統(tǒng)-GlusterFS概述

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

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

2） Heketi服務(wù)

  Heketi服務(wù)是一個提供REST ful API管理GlusterFS卷框架，并能夠在kubernetes、openstack等云平臺上實(shí)現(xiàn)動態(tài)存儲資源供應(yīng)，支持GlusterFS多集群管理，便于管理員對GlusterFS進(jìn)行操作，如下圖簡單介紹了Heketi服務(wù)的作用：

（2） 實(shí)戰(zhàn)搭建

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

#yum install glusterfs glusterfs-fuse -y

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

modprobe dm_snapshot 
modprobe dm_mirror 
modprobe dm_thin_pool

④ 為要部署GlusterFS的node打上標(biāo)簽，為了將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

⑤ 創(chuàng)建GlusterFS管理服務(wù)容器集群
#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 #創(chuàng)建
#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

⑥創(chuàng)建Heketi服務(wù)
在部署Heketi之前，需要為他創(chuàng)建一個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設(shè)置GlusterFS集群
在Heketi能管理GlusterFS集群之前，需要為其設(shè)置GlusterFS集群信息?？梢允褂胘son配置文件傳入，并且Heketi要求一個GlusterFS集群至少有3各節(jié)點(diǎn)。
#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"
                        }
                    ]
                }
            ]
        }
    ]
}

然后進(jìn)入Heketi的容器中，執(zhí)行：

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

完成以上操作，Heketi就完成了GlusterFS集群的創(chuàng)建，同時在GlusterFS集群的各個節(jié)點(diǎn)上的/dev/sdb盤上成功創(chuàng)建了PV和VG。
注意：/dev/sdb一定要是未創(chuàng)建文件系統(tǒng)的裸設(shè)備。
#查看GFS信息

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

（3） 測試

集群創(chuàng)建成功之后，當(dāng)然我們要試試，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(使用動態(tài)資源供應(yīng)模式)

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

#可以通過命令查看pv，和自動創(chuàng)建的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 #創(chuàng)建這個pod

然后進(jìn)入容器：

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

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

文章內(nèi)容參考至《kubernetes權(quán)威指南》