第8章 共享存儲原理
8.1 共享存儲機制概述
8.2 PV詳解
8.2.1 PV的關鍵配置參數
8.2.2 PV生命周期的各個階段
8.3 PVC詳解
8.4 PV和PVC的生命周期
8.4.1 資源供應
8.4.2 資源綁定
8.4.3 資源使用
8.4.4 資源釋放
8.4.5 資源回收
8.5 StorageClass詳解
8.5.1 StorageClass的關鍵配置參數
8.5.2 設置默認的StorageClass
8.6 動態存儲管理實戰：GlusterFS
8.6.1 準備工作
8.6.2 創建GlusterFS管理服務容器集群
8.6.3 創建Heketi服務
8.6.4 為Heketi設置GlusterFS集群
8.6.5 定義StorageClass
8.6.6 定義PVC
8.6.7 Pod使用PVC的存儲資源
8.7 CSI存儲機制詳解
8.7.1 CSI的設計背景
8.7.2 CSI存儲插件的關鍵組件和部署架構
8.7.3 CSI存儲插件的使用示例
8.7.4 CSI的發展

8.1 共享存儲機制概述
Kubernetes對于有狀態的容器應用或者對數據需要持久化的應用，不僅需要將容器內的目錄掛載到宿主機的目錄或者emptyDir臨時存儲卷，
而且需要更加可靠的存儲來保存應用產生的重要數據，以便容器應用在重建之后仍然可以使用之前的數據。
不過，存儲資源和計算資源（CPU/內存）的管理方式完全不同。
為了能夠屏蔽底層存儲實現的細節，讓用戶方便使用，同時讓管理員方便管理，
Kubernetes從1.0版本就引入PersistentVolume（PV）和PersistentVolumeClaim（PVC）兩個資源對象來實現對存儲的管理子系統。
PV是對底層網絡共享存儲的抽象，將共享存儲定義為一種“資源”，比如Node也是一種容器應用可以“消費”的資源。
PV由管理員創建和配置，它與共享存儲的具體實現直接相關，
例如GlusterFS、iSCSI、RBD或GCE或AWS公有云提供的共享存儲，通過插件式的機制完成與共享存儲的對接，以供應用訪問和使用。
PVC則是用戶對存儲資源的一個“申請”。就像Pod“消費”Node的資源一樣，PVC能夠“消費”PV資源。PVC可以申請特定的存儲空間和訪問模式。
使用PVC“申請”到一定的存儲空間仍然不能滿足應用對存儲設備的各種需求。
通常應用程序都會對存儲設備的特性和性能有不同的要求，包括讀寫速度、并發性能、數據冗余等更高的要求，
Kubernetes從1.4版本開始引入了一個新的資源對象StorageClass，用于標記存儲資源的特性和性能。
到1.6版本時，StorageClass和動態資源供應的機制得到了完善，實現了存儲卷的按需創建，在共享存儲的自動化管理進程中實現了重要的一步。
通過StorageClass的定義，管理員可以將存儲資源定義為某種類別（Class），正如存儲設備對于自身的配置描述（Profile），例如“快速存儲”“慢速存儲”“有數據冗余”“無數據冗余”等。
用戶根據StorageClass的描述就能夠直觀地得知各種存儲資源的特性，就可以根據應用對存儲資源的需求去申請存儲資源了。
Kubernetes從1.9版本開始引入容器存儲接口Container Storage Interface（CSI）機制，
目標是在Kubernetes和外部存儲系統之間建立一套標準的存儲管理接口，通過該接口為容器提供存儲服務，類似于CRI（容器運行時接口）和CNI（容器網絡接口）。
下面對Kubernetes的PV、PVC、StorageClass、動態資源供應和CSI等共享存儲管理機制進行詳細說明。

8.2 PV詳解
PV作為存儲資源，主要包括存儲能力、訪問模式、存儲類型、回收策略、后端存儲類型等關鍵信息的設置。
下面的例子聲明的PV具有如下屬性：
5GiB存儲空間，訪問模式為ReadWriteOnce，存儲類型為slow（要求在系統中已存在名為slow的StorageClass），
回收策略為Recycle，并且后端存儲類型為nfs（設置了NFS Server的IP地址和路徑）：
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
storageClassName: slow
PersistentVolumeReclaimPolicy: Recycle
nfs:
server: 172.17.0.2
image: /tmp
Kubernetes支持的PV類型如下：
AWSElasticBlockStore：AWS公有云提供的ElasticBlockStore。
AzureFile：Azure公有云提供的File。
AzureDisk：Azure公有云提供的Disk。
CephFS：一種開源共享存儲系統。
FC（Fibre Channel）：光纖存儲設備。
FlexVolume：一種插件式的存儲機制。
Flocker：一種開源共享存儲系統。
GCEPersistentDisk：GCE公有云提供的PersistentDisk。
Glusterfs：一種開源共享存儲系統。
HostPath：宿主機目錄，僅用于單機測試。
iSCSI：iSCSI存儲設備。
Local：本地存儲設備，從Kubernetes 1.7版本引入，到1.14版本時更新為穩定版，目前可以通過指定塊（Block）設備提供Local PV，
或通過社區開發的sig-storage-local-static-provisioner插件（https://github.com/kubernetes-sigs/sigstorage-local-static-provisioner）來管理Local PV的生命周期。
NFS：網絡文件系統。
Portworx Volumes：Portworx提供的存儲服務。
Quobyte Volumes：Quobyte提供的存儲服務。
RBD（Ceph Block Device）：Ceph塊存儲。
ScaleIO Volumes：DellEMC的存儲設備。
StorageOS：StorageOS提供的存儲服務。
VsphereVolume：VMWare提供的存儲系統。
每種存儲類型都有各自的特點，在使用時需要根據它們各自的參數進行設置。

8.2.1 PV的關鍵配置參數
1.存儲能力（Capacity）
描述存儲設備具備的能力，目前僅支持對存儲空間的設置（storage=xx），未來可能加入IOPS、吞吐率等指標的設置。
2.存儲卷模式（Volume Mode）
Kubernetes從1.13版本開始引入存儲卷類型的設置（volumeMode=xxx），可選項包括Filesystem（文件系統）和Block（塊設備），默認值為Filesystem。
目前有以下PV類型支持塊設備類型：
AWSElasticBlockStore
AzureDisk
FC
GCEPersistentDisk
iSCSI
Local volume
RBD（Ceph Block Device）
VsphereVolume（alpha）
下面的例子為使用塊設備的PV定義：
apiVersion: v1
kind: PersistentVolume
metadata:
name: block_pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
storageClassName: slow
PersistentVolumeReclaimPolicy: Retain
volumeMode: block
fc:
targetWWNs: ["xxxxxx"]
lun: 0
readOnly: false
3.訪問模式（Access Modes）
對PV進行訪問模式的設置，用于描述用戶的應用對存儲資源的訪問權限。
訪問模式如下:
ReadWriteOnce（RWO）：讀寫權限，并且只能被單個Node掛載。
ReadOnlyMany（ROX）：只讀權限，允許被多個Node掛載。
ReadWriteMany（RWX）：讀寫權限，允許被多個Node掛載。
某些PV可能支持多種訪問模式，但PV在掛載時只能使用一種訪問模式，多種訪問模式不能同時生效。
表8.1描述了不同的存儲提供者支持的訪問模式。
HostPath（宿主機目錄）僅支持ReadWriteOnce訪問模式
NFS（網絡文件系統）支持 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 三種訪問模式。
Glusterfs（開源共享存儲系統）支持 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 三種訪問模式。

4.存儲類別（Class）
PV可以設定其存儲的類別，通過storageClassName參數指定一個StorageClass資源對象的名稱。
具有特定類別的PV只能與請求了該類別的PVC進行綁定。
未設定類別的PV則只能與不請求任何類別的PVC進行綁定。

5.回收策略（Reclaim Policy）
通過PV定義中的persistentVolumeReclaimPolicy字段進行設置，可選項如下。
Retain保留：保留數據，需要手工處理。
Recycle回收空間：簡單清除文件的操作（例如執行rm -rf /thevolume/*命令）。
Delete刪除：與PV相連的后端存儲完成Volume的刪除操作（如AWS EBS、GCE PD、Azure Disk、OpenStack Cinder等設備的內部Volume清理）。
目前，只有NFS和HostPath兩種類型的存儲支持Recycle策略；AWS EBS、GCE PD、Azure Disk和Cinder volumes支持Delete策略。

6.掛載參數（Mount Options）
在將PV掛載到一個Node上時，根據后端存儲的特點，可能需要設置額外的掛載參數，可以根據PV定義中的mountOptions字段進行設置。
下面的例子為對一個類型為gcePersistentDisk的PV設置掛載參數：
apiVersion: v1
kind: PersistentVolume
metadata:
name: gce-disk-1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
mountOptions:
- hard
- nolock
- nfsvers=3
gcePersistentDisk:
fsType: "ext4"
pdName: "gce-disk-1"
目前，以下PV類型支持設置掛載參數：
AWSElasticBlockStore
AzureDisk
AzureFile
CephFS
Cinder (OpenStack block storage)
GCEPersistentDisk
Glusterfs
NFS
Quobyte Volumes
RBD (Ceph Block Device)
StorageOS
VsphereVolume
iSCSI

7.節點親和性（Node Affinity）
PV可以設置節點親和性來限制只能通過某些Node訪問Volume，可以在PV定義中的nodeAffinity字段進行設置。
使用這些Volume的Pod將被調度到滿足條件的Node上。
這個參數僅用于Local存儲卷，例如：
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-local-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
PersistentVolumeReclaimPolicy: Delete
storageClassName: local-storage
local:
path: /mnt/disks/ssd1
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- my-node
公有云提供的存儲卷（如AWS EBS、GCE PD、Azure Disk等）都由公有云自動完成節點親和性設置，無須用戶手工設置。

8.2.2 PV生命周期的各個階段
某個PV在生命周期中可能處于以下4個階段（Phaes）之一。
Available：可用狀態，還未與某個PVC綁定。
Bound：已與某個PVC綁定。
Released：綁定的PVC已經刪除，資源已釋放，但沒有被集群回收。
Failed：自動資源回收失敗。
定義了PV以后如何使用呢？這時就需要用到PVC了。下一節將對PVC進行詳細說明。

8.3 PVC詳解
PVC作為用戶對存儲資源的需求申請，主要包括存儲空間請求、訪問模式、PV選擇條件和存儲類別等信息的設置。
下例聲明的PVC具有如下屬性：
申請8GiB存儲空間，訪問模式為ReadWriteOnce，
PV 選擇條件為包含標簽“release=stable”并且包含條件為“environment In [dev]”的標簽，
存儲類別為“slow”（要求在系統中已存在名為slow的StorageClass）：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
resources:
request:
storage: 8Gi
accessModes:
- ReadWriteOnce
storageClassName: slow
selector:
matchLabels:
release: "stable"
matchExpressions:
- {key: environment, operator: In, values: [dev] }
PVC的關鍵配置參數說明如下：
資源請求（Resources）：描述對存儲資源的請求，目前僅支持request.storage的設置，即存儲空間大小。
訪問模式（Access Modes）：PVC也可以設置訪問模式，用于描述用戶應用對存儲資源的訪問權限。其三種訪問模式的設置與PV的設置相同。
存儲卷模式（Volume Modes）：PVC也可以設置存儲卷模式，用于描述希望使用的PV存儲卷模式，包括文件系統和塊設備。
PV選擇條件（Selector）：通過對Label Selector的設置，可使PVC對于系統中已存在的各種PV進行篩選。系統將根據標簽選出合適的PV與該PVC進行綁定。
選擇條件可以使用matchLabels和matchExpressions進行設置，如果兩個字段都設置了，則Selector的邏輯將是兩組條件同時滿足才能完成匹配。
存儲類別（Class）：PVC 在定義時可以設定需要的后端存儲的類別（通過storageClassName字段指定），以減少對后端存儲特性的詳細信息的依賴。
只有設置了該Class的PV才能被系統選出，并與該PVC進行綁定。
PVC也可以不設置Class需求。如果storageClassName字段的值被設置為空（storageClassName=""），則表示該PVC不要求特定的Class，系統將只選擇未設定Class的PV與之匹配和綁定。
PVC也可以完全不設置storageClassName字段，此時將根據系統是否啟用了名為DefaultStorageClass的admission controller進行相應的操作。
未啟用DefaultStorageClass：等效于PVC設置storageClassName的值為空（storageClassName=""），即只能選擇未設定Class的PV與之匹配和綁定。
啟用DefaultStorageClass：要求集群管理員已定義默認的StorageClass。如果在系統中不存在默認的StorageClass，則等效于不啟用DefaultStorageClass的情況。
如果存在默認的StorageClass，則系統將自動為PVC創建一個PV（使用默認StorageClass的后端存儲），并將它們進行綁定。
集群管理員設置默認StorageClass的方法為，在StorageClass的定義中加上一個annotation“storageclass.kubernetes.io/is-default-class= true”。
如果管理員將多個StorageClass都定義為default，則由于不唯一，系統將無法為PVC創建相應的PV。
注意，PVC和PV都受限于Namespace，PVC在選擇PV時受到Namespace的限制，只有相同Namespace中的PV才可能與PVC綁定。
Pod在引用PVC時同樣受Namespace的限制，只有相同Namespace中的PVC才能掛載到Pod內。
當Selector和Class都進行了設置時，系統將選擇兩個條件同時滿足的PV與之匹配。
另外，如果資源供應使用的是動態模式，即管理員沒有預先定義PV，僅通過StorageClass交給系統自動完成PV的動態創建，那么PVC再設定Selector時，系統將無法為其供應任何存儲資源。
在啟用動態供應模式的情況下，一旦用戶刪除了PVC，與之綁定的PV也將根據其默認的回收策略“Delete”被刪除。
如果需要保留PV（用戶數據），則在動態綁定成功后，用戶需要將系統自動生成PV的回收策略從“Delete”改成“Retain”。

8.4 PV和PVC的生命周期
我們可以將PV看作可用的存儲資源，PVC則是對存儲資源的需求，PV和PVC的相互關系遵循如圖8.1所示的生命周期。
8.4.1 資源供應
Kubernetes支持兩種資源的供應模式：靜態模式（Static）和動態模式（Dynamic）。
資源供應的結果就是創建好的PV。
靜態模式：集群管理員手工創建許多PV，在定義PV時需要將后端存儲的特性進行設置。
動態模式：集群管理員無須手工創建PV，而是通過StorageClass的設置對后端存儲進行描述，標記為某種類型。
此時要求PVC對存儲的類型進行聲明，系統將自動完成PV的創建及與PVC的綁定。
PVC可以聲明Class為""，說明該PVC禁止使用動態模式。
8.4.2 資源綁定
在用戶定義好PVC之后，系統將根據PVC對存儲資源的請求（存儲空間和訪問模式）在已存在的PV中選擇一個滿足PVC要求的PV，
一旦找到，就將該PV與用戶定義的PVC進行綁定，用戶的應用就可以使用這個PVC了。
如果在系統中沒有滿足PVC要求的PV，PVC則會無限期處于Pending狀態，直到等到系統管理員創建了一個符合其要求的PV。
PV一旦綁定到某個PVC上，就會被這個PVC獨占，不能再與其他PVC進行綁定了。
在這種情況下，當PVC申請的存儲空間比PV的少時，整個PV的空間就都能夠為PVC所用，可能會造成資源的浪費。
如果資源供應使用的是動態模式，則系統在為PVC找到合適的StorageClass后，將自動創建一個PV并完成與PVC的綁定。
8.4.3 資源使用
Pod使用Volume的定義，將PVC掛載到容器內的某個路徑進行使用。
Volume的類型為persistentVolumeClaim，在后面的示例中再進行詳細說明。
在容器應用掛載了一個PVC后，就能被持續獨占使用。
不過，多個Pod可以掛載同一個PVC，應用程序需要考慮多個實例共同訪問一塊存儲空間的問題。
8.4.4 資源釋放
當用戶對存儲資源使用完畢后，用戶可以刪除PVC，與該PVC綁定的PV將會被標記為“已釋放”，但還不能立刻與其他PVC進行綁定。
通過之前PVC寫入的數據可能還被留在存儲設備上，只有在清除之后該PV才能再次使用。
8.4.5 資源回收
對于PV，管理員可以設定回收策略，用于設置與之綁定的PVC釋放資源之后如何處理遺留數據的問題。
只有PV的存儲空間完成回收，才能供新的PVC綁定和使用。回收策略詳見下節的說明。
下面通過兩張圖分別對在靜態資源供應模式和動態資源供應模式下，PV、PVC、StorageClass及Pod使用PVC的原理進行說明。
圖8.2描述了在靜態資源供應模式下，通過PV和PVC完成綁定，并供Pod使用的存儲管理機制。
圖8.3描述了在動態資源供應模式下，通過StorageClass和PVC完成資源動態綁定（系統自動生成PV），并供Pod使用的存儲管理機制。
接下來看看StorageClass的概念和用法。

8.5 StorageClass詳解
StorageClass作為對存儲資源的抽象定義，對用戶設置的PVC申請屏蔽后端存儲的細節，
一方面減少了用戶對于存儲資源細節的關注，另一方面減輕了管理員手工管理PV的工作，由系統自動完成PV的創建和綁定，實現了動態的資源供應。
基于StorageClass的動態資源供應模式將逐步成為云平臺的標準存儲配置模式。
StorageClass的定義主要包括名稱、后端存儲的提供者（provisioner）和后端存儲的相關參數配置。
StorageClass一旦被創建出來，則將無法修改。如需更改，則只能刪除原StorageClass的定義重建。
下例定義了一個名為standard的StorageClass，提供者為aws-ebs，其參數設置了一個type，值為gp2：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2

8.5.1 StorageClass的關鍵配置參數
1.提供者（Provisioner）
描述存儲資源的提供者，也可以看作后端存儲驅動。
目前Kubernetes支持的Provisioner都以“kubernetes.io/”為開頭，用戶也可以使用自定義的后端存儲提供者。
為了符合StorageClass的用法，自定義Provisioner需要符合存儲卷的開發規范，
詳見https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-provisioning.md的說明。

2.參數（Parameters）
后端存儲資源提供者的參數設置，不同的Provisioner包括不同的參數設置。
某些參數可以不顯示設定，Provisioner將使用其默認值。
接下來通過幾種常見的Provisioner對StorageClass的定義進行詳細說明。
1）AWS EBS存儲卷
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
type: io1
zone: us-east-1d
iopsPerGB: "10"
參數說明如下（詳細說明請參考AWS EBS文檔）。
type：可選項為io1，gp2，sc1，st1，默認值為gp2。
zone：AWS zone的名稱。
iopsPerGB：僅用于io1類型的Volume，意為每秒每GiB的I/O操作數量。
encrypted：是否加密。
kmsKeyId：加密時的Amazon Resource Name。
2）GCE PD存儲卷
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
zone: us-centrall-a
參數說明如下（詳細說明請參考GCE文檔）。
type：可選項為pd-standard、pd-ssd，默認值為pd-standard。
zone：GCE zone名稱。
3）GlusterFS存儲卷
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://127.0.0.1:8081" # Gluster REST服務（Heketi）的URL地址，用于自動完成GlusterFSvolume的設置。
clusterid: "xxxx" # GlusterFS的Cluster ID
restauthenabled: "true" # 是否對Gluster REST服務啟用安全機制。
restuser: "admin" # 訪問Gluster REST 服務的用戶名。
secretNamespace: "default" # 保存訪問Gluster REST服務密碼的Secret命名空間。
secretName: "heketi-secret" # 保存訪問Gluster REST服務密碼的Secret資源對象名。
gidMin: "40000"
gidMax: "50000" # StorageClass的GID范圍，用于動態資源供應時為PV設置的GID。
volumetype: "replicate:3" # 設置GlusterFS的內部Volume類型，例如replicate:3（Replicate類型，3份副本）
參數說明如下（詳細說明請參考GlusterFS和Heketi的文檔）。
resturl：Gluster REST服務（Heketi）的URL地址，用于自動完成GlusterFSvolume的設置。
restauthenabled：是否對Gluster REST服務啟用安全機制。
restuser：訪問Gluster REST 服務的用戶名。
secretNamespace和secretName：保存訪問Gluster REST服務密碼的Secret資源對象名。
clusterid：GlusterFS的Cluster ID。
gidMin和gidMax：StorageClass的GID范圍，用于動態資源供應時為PV設置的GID。
volumetype：設置GlusterFS的內部Volume類型，例如:
replicate:3（Replicate類型，3份副本）；
disperse:4:2（Disperse類型，數據4份，冗余兩份）；
“none”（Distribute類型）。
4）OpenStack Cinder存儲卷
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gold
provisioner: kubernetes.io/cinder
parameters:
type: fast
availability: nova
參數說明如下。
type：Cinder的VolumeType，默認值為空。
availability：Availability Zone，默認值為空。
其他Provisioner的StorageClass相關參數設置請參考它們各自的配置手冊。

8.5.2 設置默認的StorageClass
要在系統中設置一個默認的StorageClass，則首先需要啟用名為DefaultStorageClass的admission controller，
即在kube-apiserver的命令行參數--admission-control中增加：
--admission-control=...,DefaultStorageClass
然后，在StorageClass的定義中設置一個annotation：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gold
annotations:
storageclass.beta.kubernetes.io/is-default-class="true"
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
通過kubectl create命令創建成功后，查看StorageClass列表，可以看到名為gold的StorageClass被標記為default：
# kubectl get sc

8.6 動態存儲管理實戰：GlusterFS
本節以GlusterFS為例，從定義StorageClass、創建GlusterFS和Heketi服務、用戶申請PVC到創建Pod使用存儲資源，
對StorageClass和動態資源分配進行詳細說明，進一步剖析Kubernetes的存儲機制。

8.6.1 準備工作
為了能夠使用GlusterFS，首先在計劃用于GlusterFS的各Node上安裝GlusterFS客戶端：
# yum install glusterfs glusterfs-fuse
GlusterFS管理服務容器需要以特權模式運行，在kube-apiserver的啟動參數中增加：
--allow-privileged=true
給要部署GlusterFS管理服務的節點打上“storagenode=glusterfs”的標簽，是為了將GlusterFS容器定向部署到安裝了GlusterFS的Node上：
# kubectl label node k8s-node-1 storagenode=glusterfs
# kubectl label node k8s-node-2 storagenode=glusterfs
# kubectl label node k8s-node-3 storagenode=glusterfs

8.6.2 創建GlusterFS管理服務容器集群
GlusterFS管理服務容器以DaemonSet的方式進行部署，確保在每個Node上都運行一個GlusterFS管理服務。
glusterfs-daemonset.yaml的內容如下：
apiVersion: extensions/v1beta1
kind: DaemonSet
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-logs
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-logs
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"
# kubectl create -f glusterfs-daemonset.yaml
# kubectl get pod

8.6.3 創建Heketi服務
Heketi 是一個提供RESTful API管理GlusterFS卷的框架，
并能夠在OpenStack、Kubernetes、OpenShift等云平臺上實現動態存儲資源供應，支持GlusterFS多集群管理，便于管理員對GlusterFS進行操作。
圖8.4簡單描述了Heketi的作用。
在部署Heketi服務之前，需要為它創建一個ServiceAccount對象（heketi-service-account.yaml）：
apiVersion: v1
kind: ServiceAccount
metadata:
name: heketi-service-account
# kubectl create -f heketi-service-account.yaml
部署Heketi服務（heketi-deployment-svc.yaml）：
apiVersion: v1
kind: Deployment
metadata:
name: deploy-heketi
labels:
glusterfs: heketi-deployment
deploy-heketi: heketi-deployment
annotations:
description: Defines how to deploy Heketi
spec:
...
---
apiVersion: v1
kind: Service
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
需要注意的是，Heketi的DB數據需要持久化保存，建議使用hostPath或其他共享存儲進行保存：
# kubectl create -f heketi-deployment-svc.yaml

8.6.4 為Heketi設置GlusterFS集群
在Heketi能夠管理GlusterFS集群之前，首先要為其設置GlusterFS集群的信息。
可以用一個topology.json配置文件來完成各個GlusterFS節點和設備的定義。
Heketi要求在一個GlusterFS集群中至少有3個節點。
在topology.json配置文件hostnames字段的manage上填寫主機名，在storage上填寫IP地址，
devices要求為未創建文件系統的裸設備（可以有多塊盤），以供Heketi自動完成PV（Physical Volume）、VG（Volume Group）和LV（Logical Volume）的創建。
topology.json文件的內容如下：
{
"clusters": [
{
"nodes": [
{
"node": {
"hostnames": {
"manage": ["k8s-node-1"],
"storage": ["192.168.18.3"]
},
"zone": 1
},
"devices": ["/dev/sdb"]
},
......其余兩個node節點配置
]
}
]
}
進入Heketi容器，使用命令行工具heketi-cli完成GlusterFS集群的創建：
# export HEKETI_CLI_SERVER=http://localhost:8080
# heketi_cli topology load --json=topology.json
經過這個操作，Heketi完成了GlusterFS集群的創建，同時在GlusterFS集群的各個節點的/dev/sdb盤上成功創建了PV和VG。
查看Heketi的topology信息，可以看到Node和Device的詳細信息，包括磁盤空間的大小和剩余空間。此時，Volume和Brick還未創建：
# heketi_cli topology info

8.6.5 定義StorageClass
準備工作已經就緒，集群管理員現在可以在Kubernetes集群中定義一個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"
Provisioner參數必須被設置為“kubernetes.io/glusterfs”。
resturl的地址需要被設置為API Server所在主機可以訪問到的Heketi服務的某個地址，可以使用服務ClusterIP+端口號、容器IP地址+端口號，或將服務映射到物理機，使用物理機IP+NodePort。
創建這個StorageClass資源對象：
# kubectl create -f storageclass-gluster-heketi.yaml

8.6.6 定義PVC
現在，用戶可以申請一個PVC了(pvc-gluster-heketi.yaml)。
例如，一個用戶申請一個1GiB空間的共享存儲資源，StorageClass使用“gluster-heketi”，未定義任何Selector，說明使用動態資源供應模式：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-gluster-heketi
spec:
resources:
request:
storage: 1Gi
accessModes:
- ReadWriteOnce
storageClassName: gluster-heketi
# kubectl create -f pvc-gluster-heketi.yaml
PVC的定義一旦生成，系統便將觸發Heketi進行相應的操作，主要為在GlusterFS集群上創建brick，再創建并啟動一個Volume。整個過程可以在Heketi的日志中查到。
查看PVC的狀態，可見其已經為Bound（已綁定）：
# kubectl get pvc
查看PV，可見系統自動創建的PV：
# kubectl get pv
查看該PV的詳細信息，可以看到其容量、引用的StorageClass等信息都已正確設置，狀態也為Bound，回收策略則為默認的Delete。同時Gluster的Endpoint和Path也由Heketi自動完成了設置：
# kubectl describe pv pvc-xxxx
至此，一個可供Pod使用的PVC就創建成功了。接下來Pod就能通過Volume的設置將這個PVC掛載到容器內部進行使用了。

8.6.7 Pod使用PVC的存儲資源（pod-use-pvc.yaml）
在Pod中使用PVC定義的存儲資源非常容易，只需設置一個Volume，其類型為persistentVolumeClaim，即可輕松引用一個PVC。
下例中使用一個busybox容器驗證對PVC的使用，注意Pod需要與PVC屬于同一個Namespace：
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
# kubectl create -f pod-use-pvc.yaml
進入容器pod-use-pvc，在/pv-data目錄下創建一些文件：
# kubectl exec -it pod-use-pvc -- /bin/sh
cd /pv-data
touch a
echo "hello" > b
可以驗證文件a和b在GlusterFS集群中是否正確生成。
至此，使用Kubernetes最新的動態存儲供應模式，配合StorageClass和Heketi共同搭建基于GlusterFS的共享存儲就完成了。
有興趣的讀者可以繼續嘗試StorageClass的其他設置，例如調整GlusterFS的Volume類型、修改PV的回收策略等。
在使用動態存儲供應模式的情況下，相對于靜態模式的優勢至少包括如下兩點：
（1）管理員無須預先創建大量的PV作為存儲資源。
（2）用戶在申請PVC時無法保證容量與預置PV的容量完全匹配。
從Kubernetes 1.6版本開始，建議用戶優先考慮使用StorageClass的動態存儲供應模式進行存儲管理。

8.7 CSI存儲機制詳解
Kubernetes從1.9版本開始引入容器存儲接口Container Storage Interface（CSI）機制，
用于在Kubernetes和外部存儲系統之間建立一套標準的存儲管理接口，通過該接口為容器提供存儲服務。
CSI到Kubernetes 1.10版本升級為Beta版，到Kubernetes 1.13版本升級為GA版，已逐漸成熟。

8.7.1 CSI的設計背景
Kubernetes通過PV、PVC、Storageclass已經提供了一種強大的基于插件的存儲管理機制，
但是各種存儲插件提供的存儲服務都是基于一種被稱為“in-tree”（樹內）的方式提供的，
這要求存儲插件的代碼必須被放進Kubernetes的主干代碼庫中才能被Kubernetes調用，屬于緊耦合的開發模式。
這種“in-tree”方式會帶來一些問題：
存儲插件的代碼需要與Kubernetes的代碼放在同一代碼庫中，并與Kubernetes的二進制文件共同發布；
存儲插件代碼的開發者必須遵循Kubernetes的代碼開發規范；
存儲插件代碼的開發者必須遵循Kubernetes的發布流程，包括添加對Kubernetes存儲系統的支持和錯誤修復；
Kubernetes社區需要對存儲插件的代碼進行維護，包括審核、測試等工作；
存儲插件代碼中的問題可能會影響Kubernetes組件的運行，并且很難排查問題；
存儲插件代碼與Kubernetes的核心組件（kubelet和kube-controller-manager）享有相同的系統特權權限，可能存在可靠性和安全性問題。
Kubernetes已有的Flex Volume插件機制試圖通過為外部存儲暴露一個基于可執行程序（exec）的API來解決這些問題。
盡管它允許第三方存儲提供商在Kubernetes核心代碼之外開發存儲驅動，但仍然有兩個問題沒有得到很好的解決：
部署第三方驅動的可執行文件仍然需要宿主機的root權限，存在安全隱患；
存儲插件在執行mount、attach這些操作時，通常需要在宿主機上安裝一些第三方工具包和依賴庫，使得部署過程更加復雜，
例如部署Ceph時需要安裝rbd庫，部署GlusterFS時需要安裝mount.glusterfs庫，等等。
基于以上這些問題和考慮，Kubernetes逐步推出與容器對接的存儲接口標準，
存儲提供方只需要基于標準接口進行存儲插件的實現，就能使用Kubernetes的原生存儲機制為容器提供存儲服務。
這套標準被稱為CSI（容器存儲接口）。
在CSI成為Kubernetes的存儲供應標準之后，存儲提供方的代碼就能和Kubernetes代碼徹底解耦，部署也與Kubernetes核心組件分離，
顯然，存儲插件的開發由提供方自行維護，就能為Kubernetes用戶提供更多的存儲功能，也更加安全可靠。
基于CSI的存儲插件機制也被稱為“out-of-tree”（樹外）的服務提供方式，是未來Kubernetes第三方存儲插件的標準方案。

8.7.2 CSI存儲插件的關鍵組件和部署架構
圖8.5描述了Kubernetes CSI存儲插件的關鍵組件和推薦的容器化部署架構。
其中主要包括兩種組件：CSI Controller和CSI Node。
1.CSI Controller
CSI Controller的主要功能是提供存儲服務視角對存儲資源和存儲卷進行管理和操作。
在Kubernetes中建議將其部署為單實例Pod，可以使用StatefulSet或Deployment控制器進行部署，設置副本數量為1，保證為一種存儲插件只運行一個控制器實例。
在這個Pod內部署兩個容器，如下所述。
（1）與Master（kube-controller-manager）通信的輔助sidecar容器。
在sidecar容器內又可以包含external-attacher和external-provisioner兩個容器，它們的功能分別如下。
external-attacher：監控VolumeAttachment資源對象的變更，觸發針對CSI端點的ControllerPublish和ControllerUnpublish操作。
external-provisioner：監控PersistentVolumeClaim資源對象的變更，觸發針對CSI端點的CreateVolume和DeleteVolume操作。
（2）CSI Driver存儲驅動容器，由第三方存儲提供商提供，需要實現上述接口。
這兩個容器通過本地Socket（Unix Domain Socket，UDS），并使用gPRC協議進行通信。
sidecar容器通過Socket調用CSI Driver容器的CSI接口，CSI Driver容器負責具體的存儲卷操作。

2.CSI Node
CSI Node的主要功能是對主機（Node）上的Volume進行管理和操作。
在Kubernetes中建議將其部署為DaemonSet，在每個Node上都運行一個Pod。
在這個Pod中部署以下兩個容器：
（1）與kubelet通信的輔助sidecar容器node-driver-registrar，主要功能是將存儲驅動注冊到kubelet中；
（2）CSI Driver存儲驅動容器，由第三方存儲提供商提供，主要功能是接收kubelet的調用，需要實現一系列與Node相關的CSI接口，
例如NodePublishVolume接口（用于將Volume掛載到容器內的目標路徑）、NodeUnpublishVolume接口（用于從容器中卸載Volume），等等。
node-driver-registrar容器與kubelet通過Node主機的一個hostPath目錄下的unix socket進行通信。
CSI Driver容器與kubelet通過Node主機的另一個hostPath目錄下的unix socket進行通信，
同時需要將kubelet的工作目錄（默認為/var/lib/kubelet）掛載給CSI Driver容器，用于為Pod進行Volume的管理操作（包括mount、umount等）。

8.7.3 CSI存儲插件的使用示例
下面以csi-hostpath插件為例，對如何部署CSI插件、用戶如何使用CSI插件提供的存儲資源進行詳細說明。
（1）設置Kubernetes服務啟動參數。為kube-apiserver、kube-controller-manager和kubelet服務的啟動參數添加：
--feature-gates=VolumeSnapshotDataSource=true,CSINodeInfo=true,CSIDriverRegistry=true
這3個特性開關是Kubernetes從1.12版本引入的Alpha版功能，CSINodeInfo和CSIDriverRegistry需要手工創建其相應的CRD資源對象。
Kubernetes 1.10版本所需的CSIPersistentVolume和MountPropagation特性開關已經默認啟用，
KubeletPluginsWatcher特性開關也在Kubernetes 1.12版本中默認啟用，無須在命令行參數中指定。
（2）創建CSINodeInfo和CSIDriverRegistry CRD資源對象。
csidriver.yaml的內容如下：
csinodeinfo.yaml的內容如下：
使用kubectl create命令完成創建：
# kubectl create -f csidriver.yaml
# kubectl create -f csinodeinfo.yaml
（3）創建csi-hostpath存儲插件相關組件，
包括csi-hostpath-attacher、csi-hostpathprovisioner和csi-hostpathplugin（其中包含csi-node-driver-registrar和hostpathplugin）。
其中為每個組件都配置了相應的RBAC權限控制規則，對于安全訪問Kubernetes資源對象非常重要。
csi-hostpath-attacher.yaml的內容如下：
csi-hostpath-provisioner.yaml的內容如下：
csi-hostpathplugin.yaml的內容如下：
使用kubectl create命令完成創建：
# kubectl create -f csi-hostpath-attacher.yaml
# kubectl create -f csi-hostpath-provisioner.yaml
# kubectl create -f csi-hostpathplugin.yaml
確保3個Pod都正常運行：
# kubectl get pods
至此就完成了CSI存儲插件的部署。
（4）應用容器使用CSI存儲。
應用程序如果希望使用CSI存儲插件提供的存儲服務，則仍然使用Kubernetes動態存儲管理機制。
首先通過創建StorageClass和PVC為應用容器準備存儲資源，然后容器就可以掛載PVC到容器內的目錄進行使用了。
創建一個StorageClass，provisioner為CSI存儲插件的類型，在本例中為csi-hostpath：
csi-storageclass.yaml的內容如下：
# kubectl create -f csi-storageclass.yaml
創建一個PVC，引用剛剛創建的StorageClass，申請存儲空間為1GiB：
csi-pvc.yaml的內容如下：
# kubectl create -f csi-pvc.yaml
查看PVC和系統自動創建的PV，狀態為Bound，說明創建成功：
# kubectl get pvc
# kubectl get pv
最后，在應用容器的配置中使用該PVC：
csi-app.yaml的內容如下：
# kubectl create -f csi-app.yaml
# kubectl get pods
在Pod創建成功之后，應用容器中的/data目錄使用的就是CSI存儲插件提供的存儲。
我們通過kubelet的日志可以查看到Volume掛載的詳細過程。

8.7.4 CSI的發展
目前可用于生產環境的CSI插件如表8.2所示。
實驗性的CSI插件如表8.3所示。
每種CSI存儲插件都提供了容器鏡像，
與external-attacher、external-provisioner、node-driver-registrar等sidecar輔助容器共同完成存儲插件系統的部署，
每個插件的部署配置詳見官網https://kubernetes-csi.github.io/docs/drivers.html中的鏈接。
Kubernetes從1.12版本開始引入存儲卷快照（Volume Snapshots）功能，
通過新的CRD自定義資源對象VolumeSnapshotContent、VolumeSnapshot和VolumeSnapshotClass進行管理。
VolumeSnapshotContent定義從當前PV創建的快照，類似于一個新的PV；
VolumeSnapshot定義需要綁定某個快照的請求，類似于PVC的定義；
VolumeSnapshotClass用于屏蔽VolumeSnapshotContent的細節，類似于StorageClass的功能。
下面是一個VolumeSnapshotContent的例子：
下面是一個VolumeSnapshot的例子：
后續要進一步完善的工作如下。
（1）將以下Alpha版功能更新到Beta版：
Raw Block類型的Volumes；
拓撲感知，Kubernetes理解和影響CSI卷的配置位置（如zone、region 等）的能力；
完善基于CRD的擴展功能（例如Skip attach、Pod info on mount等）。
（2）完善對本地短暫卷（Local Ephemeral Volume）的支持。
（3）將Kubernetes“in-tree”存儲卷插件遷移到CSI。