本文來自8月24日有容雲Docker微信群分享整理

分享嘉賓：有容雲研發總監-張朝潞

以下是分享正文：

首先介紹下有容雲UFleet產品，UFleet -- 基於原生kubernetes技術，為企業打造專屬的容器即服務（CaaS）平臺，為企業提供應用的全生命週期管理服務和相關的資源服務，為應用的構建、部署和執行提供統一的平臺，並保障應用所需的資源隨需供應。

有了解決有狀態應用對儲存的需求，UFleet沒有對接第三方儲存系統，而採用的是在UFleet平臺上融合有容雲自主研發的分散式儲存系統，從而大大提高了平臺資源整合以及利用率；下面將從四個方面來講講UFleet平臺上怎麼融合儲存系統？

一、Kubernetes有狀態儲存模型

kubernetes的儲存系統大致分為三個層次：普通Volume，Persistent Volume 和StorageClass動態儲存供應。

1.1 普通Volume（單節點）

普通Volume，最簡單的一種是“單節點儲存卷”，它和Docker的儲存卷類似，使用的是Pod所在K8S節點的本地目錄。具體有兩種：一種是emptyDir，是一個匿名的空目錄，由Kubernetes在建立Pod時建立，刪除Pod時刪除。 另外一種是 hostPath，與emptyDir的區別是，它在Pod之外獨立存在，由使用者指定路徑名。

這類和節點繫結的儲存卷在Pod遷移到其它節點後資料就會丟失，所以只能用於儲存臨時資料或用於在同一個Pod裡的容器之間共享資料。

1.2 Persistent Volume（跨節點 - 靜態方式）

普通Volume和使用它的Pod之間是一種靜態繫結關係，我們無法單獨建立一個普通volume，因為它不是一個獨立的K8S資源物件。而Persistent Volume 簡稱PV是一個K8S資源物件，所以我們可以單獨建立。它不和Pod直接發生關係，而是通過Persistent Volume Claim，簡稱PVC來實現動態繫結。靜態方式是管理員手動建立一堆PV，組成一個PV池，供PVC來繫結。

一個PV建立完後狀態會變成Available，等待被PVC繫結。一旦被PVC邦定，PV的狀態會變成Bound，就可以被相應的Pod使用。Pod使用完後會釋放PV，PV的狀態變成Released。變成Released的PV會根據定義的回收策略做相應的回收工作。有三種回收策略，Retain、Delete 和Recycle：

 Retain就是保留現場，K8S什麼也不做。Delete 策略，K8S會自動刪除該PV及裡面的資料。Recycle方式，K8S會將PV裡的資料刪除，然後把PV的狀態變成Available，又可以被新的PVC繫結使用。

1.3 StorageClass（跨節點 – 動態方式）

動態方式是通過一個叫 storage class的物件由儲存系統根據PVC的要求自動建立；使用StorageClass除了由儲存系統動態建立，節省了管理員的時間，還有一個好處是可以封裝不同型別的儲存供PVC選用。

二、Kubernetes平臺上的分散式儲存系統VeSpace

VeSpace分散式儲存系統提供3種介面型別，①塊介面（SCSI塊裝置/iSCSI）。②檔案介面（NFS/SMB）。③RestFul介面。Kubernetes的儲存框架已經支援iSCSI，NFS，SMB的方式整合外部儲存。VeSpace的模組架構如下：

VeSpace支援副本和糾刪碼兩種資料冗餘方式，資料冗餘方式以卷為單位，可以容器為粒度提供不同級別的儲存服務。從資料分佈角度來看三種不同型別的卷：1.線性分佈；2.條帶分佈；3.EC分佈；

2.1 線性分佈

如下圖，假設建立一個虛擬卷大小為48GB，線性切分成4個component，C1負責線性地址空間0~12GB-1，只要是對該地址範圍內的訪問，將請求交給C1處理。

2.2 條帶分佈

如下圖，將資料切成大小相等的資料塊(chunk)，所有component相同位置的資料塊組成條帶(stripe)，類似於RAID0，跨資料塊的讀寫，並行處理，提升IO速度，減少延遲。

2.3 EC分佈

糾刪碼(erasurecoding，EC)是一種資料保護的方法，將資料切割成大小相同的資料塊(chunk)，把通過計算得到與資料塊(chunk)大小相同的校驗塊(下圖中的P1)。EC通過時間換取空間的方式，通過增加CPU計算量，而減少資料的冗餘。

如下圖，卷sdb(48GB)使用了3+2的糾刪碼，允許兩個component失效，總使用空間為80GB。如果使用副本的形式則需要佔用144GB的儲存空間，達到允許兩個component失效的目標，糾刪碼節省了80%的儲存空間。

三、UFleet儲存融合架構

以下是11臺機器，劃分了3個Kubernetes叢集和1個VeSpace儲存叢集。VeSpace將11臺機器的儲存資源整合，通過名稱空間隔離再將儲存資源暴露給不同的Kubernetes叢集。

Q&A

Q1：想請問下，你們的底層分散式儲存，負載均衡能基於哪些？cpu利用率？還有啥？

A：負載均衡我們提供可以配置儲存策略進行控制，CPU、記憶體、網路，磁碟使用率，IOPS，延遲等。

Q2：請問VeSpace相比Ceph或者Glusterfs有什麼優勢？

A：VeSpace是完全自主研發的，可以掌控每一行程式碼，每一個IO。當然設計上都有參考Ceph和Glusterfs，如果有興趣可以看看我們提供的技術白皮書，裡面有詳細的技術描述。

Q3：咱們這個超融合系統的付費方式是怎麼樣？按照cpu個數？

A：我們的license設計成多個維度的，通常是按照容量，節點或者物理磁碟數量收費。

Q4：貴公司的平臺可是實現每個pod的儲存擴容和資料隔離嗎？這個使用者比較關心的。

A：儲存卷和Pod是相互獨立，不同儲存卷的資料自然是隔離的，Pod使用不同的儲存卷即可。單個儲存卷是可以擴容的。

Q5：儲存的訪問許可權是怎樣的?登陸使用者都可以訪問?

A：儲存管理是支援多叢集的，叢集訪問需要授權，叢集內部可以劃分名稱空間，使用者可以基於名稱空間授權訪問

Q6：冗餘數怎麼設計？

A：根據資料的重要性設定。副本方式效能好，糾刪碼節省空間。通常兩副本，三副本，3+1, 4+1

Q7：EC讀寫效率如何？資料丟失恢復過程對叢集有何影響？

A：主要看K+M的取值，假設是3+1，並且系統負載較低，在正常情況寫效率還不錯。損壞一個節點的時候，效能下降15~20%。

Q8：您好，能不能分享下部署檔案yaml唄，講的好，不如操作一遍來的實際。

A：UFleet是Kubernetes和VeSpace深度整合的。並不是跑在k8s上，請持續關注UFleet，可以試用一下。

Q9：VeSpace將11臺機器的儲存資源整合，通過名稱空間隔離再將儲存資源暴露給不同的Kubernetes叢集。我想了解下這裡的名稱空間是不是可以理解storageclass？這裡儲存資源整合有什麼好處，存在單點問題嗎？

A：名稱空間指的是VeSpace的名稱空間，概念與k8s的名稱空間一樣。VeSpace名稱空間實現資源的邏輯隔離，與storageclass不同，storageclass可以指定VeSpace一個名稱空間下的儲存池，存在對應關係。儲存資源整合有幾個好處：1.對於跨k8s叢集部署的容器可輕易實現共享，比如叢集聯邦。2.儲存資源統一管理，便於資料均衡，最大限度的使用資源。VeSpace和k8s都是分散式的，並不存在單點問題。

Q10：您好，請問mysql分散式儲存方案，能不能介紹下呢？用的是pxc還是什？

A：準確的說應該是mysql的叢集方案，沒有線上用過mysql的叢集方案。以前的工作中開發大型的支付系統的時候，採用的是業務層完成分表分庫和讀寫分離。使用多個mysql主備例項。

本文來源：http://www.youruncloud.com/blog/144.html