一篇講透Kubernetes與GlusterFS之間的愛恨情仇
http://rdc.hundsun.com/portal/article/826.html
http://rdcqii.hundsun.com/portal/article/827.html
儲存是容器編排中非常重要的一部分。Kubernetes從v1.2開始，提供了dynamic provisioning這一強大的特性，可以給叢集提供按需分配的儲存，並能支援包括AWS-EBS、GCE-PD、Cinder-Openstack、Ceph、GlusterFS等多種雲端儲存。而GlusterFS作為分散式檔案系統的後起之秀，他們之間會擦出什麼樣的火花呢？
首先，我們來談談Kubernetes部署的應用，可以分為無狀態的和有狀態的：
▪ 無狀態的應用沒有資料，Pod（一個或若干容器的集合）掛了被重新拉起，或者在Kubernetes叢集不同的Node節點（可以認為是一臺物理機或虛擬機器）之間飄來飄去，都沒有關係；
▪ 有狀態的應用有資料需要儲存，如果容器掛了被重新拉起，容器裡面儲存的資料就沒了。
這時候我們自然而然地想到可以把資料對映到容器所在主機上，就像我們使用Docker時經常做的一樣，可是這時候有個問題是，Kubernetes叢集一般有多個Node節點，如果容器在掛了被重新拉起的時候被排程到其他的Node節點，那對映在原先主機上的資料還是在原先主機上，新的容器還是沒有原來的資料。
怎麼辦呢？
這時候就需要本文的另一位重要的主角了--
事實上，Kubernetes的選擇很多，目前Kubernetes支援的儲存有下面這些：
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (Fibre Channel)
FlexVolume
Flocker
NFS
iSCSI
RBD (Ceph Block Device)
CephFS
Cinder (OpenStack block storage)
Glusterfs
VsphereVolume
Quobyte Volumes
HostPath (就是剛才說的對映到主機的方式，多個Node節點會有問題)
VMware Photon
Portworx Volumes
ScaleIO Volumes
StorageOS
Kubernetes有這麼多選擇，GlusterFS只是其中之一，但為什麼可以脫穎而出呢？GlusterFS，是一個開源的分散式檔案系統，具有強大的橫向擴充套件能力，通過擴充套件能夠支援數PB儲存容量和處理數千客戶端。GlusterFS藉助TCP/IP或InfiniBand
RDMA網路將物理分佈的儲存資源聚集在一起，使用單一全域性名稱空間來管理資料。GlusterFS的Volume有多種模式，複製模式可以保證資料的高可靠性，條帶模式可以提高資料的存取速度，分佈模式可以提供橫向擴容支援，幾種模式可以組合使用實現優勢互補。
下面就來看看Kubernetes和GlusterFS是怎麼結合起來的吧，下面我們進入實戰解決你對兩者結合的所有困惑。
假設Kubernetes部署在
Master：
Node：
Kubernetes版本：
在每臺機器的/etc/hosts加上
（以下安裝過程--到安裝結束的地方--可以使用 http://192.168.58.228:9007/glusterfs/install/ 上的一鍵安裝包安裝）
安裝yum源（每臺機器執行）
安裝glusterfs（每臺機器執行）:
（安裝結束）
啟動glusterfs（每臺機器執行）：
組建叢集（192.168.XX.A 機器執行）：
驗證（192.168.XX.A 機器執行）：
看到其他兩個點的資訊即代表GlusterFS叢集組建成功
【Kubernetes使用GlusterFS】 有兩種方式，手動和自動，手動需要每次使用儲存時自己建立GlusterFS的卷（GlusterFS的資料儲存在卷Volume上）；自動利用Kubernetes的 Dynamic Provisioning 特性，可以由Kubernetes自動建立GlusterFS卷，但是需要先部署Heketi軟體，並且安裝GlusterFS的機器上還要有裸磁碟。
▲手動方式
1）建立GlusterFS卷
▪ 新建卷（3個副本的複製模式）
▪ 啟動卷
▪ 檢視卷：
可以看到所建立的卷的資訊。
2）Kubernetes建立PV等儲存
Kubernetes用PV（PersistentVolume）、PVC（PersistentVolumeClaim）來使用GlusterFS的儲存，PV與GlusterFS的Volume相連，相當於提供儲存裝置，所以需要由知道GlusterFS Volume的系統管理員建立（這裡我們自己就是系統管理員）；PVC消耗PV提供的儲存，由應用部署人員建立，應用直接使用PVC進而使用PV的儲存。
以下操作在Kubernetes Master節點執行
系統管理員建立 endpoint、service、pv（endpoint和service不用每次都建，可以複用）：
先建立三個檔案：
▪ glusterfs-endpoints.json：
▪ glusterfs-service.json：
▪ glusterfs-pv.yaml：
執行命令建立：
檢視endpoint、service、pv：
3）Kubernetes建立應用
應用部署人員建立pvc及應用（這裡以mysql為例）：
建立兩個檔案：
▪ glusterfs-pvc.yaml:
▪ mysql-deployment.yaml:
執行命令建立：
檢視pvc、service：
檢視pod：
可以看到 Pod 已經被排程到 192.168.XX.A 上。
mysql客戶端連線並檢視資料庫：
可以看到我們建的liao資料庫還在，說明雖然 pod 重新排程，但資料還在。
有人會疑問這裡兩次連線的都是 192.168.XX.A 的 31016 埠，為什麼說連線到了不同的Pod，這是因為Kubernetes的kube-proxy會把我們配置的Service裡對映的埠在每個Kubernetes Node上都開出來，也就是在任何一個Kubernetes Node上都能連線到Pod，Pod重新排程後，還是在任何一個Kubernetes Node上都能連線，但後面的Pod其實已經是新的了。
▲自動方式
自動方式需要先部署Heketi軟體，Heketi用來管理GlusterFS，並提供RESTful API介面供Kubernetes呼叫。Heketi需要使用裸磁碟，假設三個GlusterFS節點上都掛了一塊裸磁碟 /dev/xvde。接下來我們進入實戰模式
【部署Heketi】 部署在
安裝：（以下安裝過程--到安裝結束的地方--可以使用 http://192.168.58.228:9007/glusterfs/heketi/ 上的一鍵安裝包安裝）
改為公司yum源
安裝
（安裝結束）
修改/etc/heketi/heketi.json（省略了沒有修改的部分）:
這裡主要把埠改為8083了（防止衝突），executor 改為 ssh， sshexec 的各項配置也做了相應修改。
其中的keyfile製作方法：
輸入key（隨便起的名字）一直回車。製作完成後會在當前目錄下生成key、key.pub，把 key.pub 上傳到GlusterFS三臺伺服器的 /root/.ssh/ 下面，並重命名為 authorized_keys，/etc/heketi/heketi.json 中 的 keyfile 指向 生成的 key（包含路徑）。
啟動：
看日誌：
（Heketi資料目錄： /var/lib/heketi）
驗證：
或：
▲配置節點
新建 topology.json：
載入配置：
檢視拓撲：
建個大小為2G的volume試試：
檢視：
刪除：
新建檔案：glusterfs-storageclass.yaml:
replicate:3代表會建立三個副本複製模式的GluserFS Volume。
執行命令建立：
檢視：
【Kubernetes建立應用】
應用部署人員建立pvc及應用（本文還是以mysql為例）
建立兩個檔案：
▪ glusterfs-pvc.yaml：
▪ mysql-deployment.yaml:
執行命令建立：
檢視endpoint、service、pv，可以發現這些都自動建好了：
檢視PVC：
c可以看到PV和PVC已經繫結好。
還是可以用剛才的命令連線到mysql：
按剛才的方式測試mysql pod重新排程後資料還在不在，可以發現數據還在。
從上一篇文章可以看到手動方式需要系統管理員每次手動建GlusterFS的Volume和Kubernetes的PV，或者系統管理員事先建好一批Volume和PV。而本文所介紹的自動方式則是不需要，Kubernetes可以根據應用部署人員的需要動態建立Volume和PV，節省了很多工作量，所以，得出的結論就是推薦使用自動方式。
本文轉載自恆生技術之眼