基于Kubernetes的云平臺存儲容器化實踐

今天分享的主題是OPPO云存儲的上云之路。

存儲相比于其他組件，更底層，所以有必要做一個簡單的科普。

主要是對整個文件進行操作，提供了對整個文件進行增刪查改的能力。不支持對對象內(nèi)容進行增量修改，如七牛的對象存儲，AWS S3，阿里OSS，呈現(xiàn)給我們調(diào)用方式是http api。

文件存儲實現(xiàn)了文件的POSIX接口，由于整個文件系統(tǒng)不依賴操作系統(tǒng)，常用于實現(xiàn)共享文件系統(tǒng)，常見的比如說ceph fs，gluster fs呈現(xiàn)給我們的使用方式是文件系統(tǒng)。

提供裸塊的能力交由物理機使用，協(xié)議是SCSI，iSCSI，文件系統(tǒng)層由操作系統(tǒng)提供。呈現(xiàn)給我們的使用方式是裸盤，不帶任何文件系統(tǒng)，需要格式化后使用，或者使用塊API。

目前塊存儲主要是三個組件，gateway、storage、 cluster manager。

• gateway主要是解析iscsi協(xié)議，把塊請求解析發(fā)送到storage進行處理；

• storage則是對塊的讀寫操作進行處理，管理磁盤數(shù)據(jù)

• cluster manager為元數(shù)據(jù)中心，保存節(jié)點的狀態(tài)，對整個集群的健康狀態(tài)做仲裁

現(xiàn)在Kubernetes 的趨勢愈演愈烈，Kubernetes 逐漸成為云原生時代的基礎設施，為了給上云的程序提供服務，云原生也隨之出現(xiàn)，目前世面上已經(jīng)有OpenEBS Portworx 和Rook等產(chǎn)品。

云原生存儲不僅要為上云的服務提供服務，自身也利用云的特性增強自身的功能，依賴Kubernetes的特性，我們可以輕運維，輕部署，利用容器隔離的能力，減少異常進程之前的相互影響，提高整體資源的利用率。

Kubernetes作為未來云上的操作系統(tǒng)，把存儲整個生命周期和管理抽象成三種資源。

抽象了管理存儲相關的配置，主要是provisioner、parameters、reclaimPolicy這三個配置。

• provisioner: 表示某一種存儲資源 

• parameters: 相當于自定義配置，自定義一些存儲屬性 

• reclaimPolicy：設置volume釋放后，pv的動作，Delete or Retain

通過聲明不同stroageclass可以管理多種類型的存儲比如說ceph，glusterfs等等。

表示一段已分配的存儲，可以是文件系統(tǒng)，也可以是裸塊，云存儲的云盤或者文件系統(tǒng)映射到Kubernetes 就是一個PersistentVolume。

用戶存儲的請求，可以請求特定的容量大小和訪問模式（例如，可以以讀/寫一次或指向多次模式掛載）。

抽象出PersistentVolumeClaim把存儲和管理分離，通過PersistentVolumeClaim我們可以控制訪問存儲的權(quán)限，存儲的容量和類型。

下圖是Kubernetes使用存儲的一個方式：

這里衍生下Kubernetes 的一些設計理念，Kubernetes 使用聲明式的API，通過YAML聲明請求，并保存到etcd，這樣做的好處是把整個請求記錄下來，對于問題的回溯也比較方便，不用自己去記錄日志提煉請求。

另外Kubernetes 還提供了對于各種資源的watch Api，各種資源的crud都可以通過watch api實時的拿到對應的YAML，這樣的設計的好處是讓Kubernetes 擁有非常好的擴展性，通過實現(xiàn)controller 去watch各種資源的變化情況，定義該資源的crud行為。

提供一個將任意塊或者文件存儲系統(tǒng)對接到給容器編排系統(tǒng)（COs）上的接口標準，如Kubernetes。

把存儲從創(chuàng)建到銷毀整個生命周期抽象成一組標準接口，Kubernetes通過對接CSI，實現(xiàn)對存儲整個生命周期的管理。

下圖就是CSI定義的存儲卷的生命周期：

上文說道Kubernetes 對存儲的抽象是StorageClass，PersistentVolume ，PersistentVolumeClaim等資源CSI 則是提供一組標準接口。所以需要引入一層把Kubernetes 中的資源行為轉(zhuǎn)為CSI接口的程序，Kubernetes 提供了多個sidecar屏蔽這個過程。

這里簡單科普下sidecar，一般來說，引入sdk實現(xiàn)某些功能，在編譯的時候把sdk代碼編譯進去，更新sdk要重新發(fā)布，和工程耦合的比較緊密，sidecar則是把sdk實現(xiàn)的功能通過在pod運行一個獨立的容器實現(xiàn)，通過sidecar們提供rpc接口進行交互，可以作為被調(diào)用方，也可以是把服務包裝起來增強服務功能，增加這樣子的好處是解耦，讓更新sidecar容器的版本更簡單。

通過引入以下sidecar，我們可以只專注于實現(xiàn)CSI定義的接口。

從官網(wǎng)給的圖我們就可以直白的看到粉紅色框的sidecar們相當于一層膠水，把Kubernetes和csi鏈接起來。

1）PV與調(diào)度

至此我們已經(jīng)講完了Kubernetes和CSI與K8S怎么交互的，接下來講下PV與調(diào)度的關系。

在調(diào)度階段，PV的affinity 會影響Pod的調(diào)度，所以有調(diào)度需求的可以通過PV的affinity控制。

2）NodeStatgeVolume與NodePublishVolume

之前查閱資料的時候發(fā)現(xiàn)這兩個接口的說明講的比較少。

NodeStatgeVolume的接口是把遠端的云盤掛到物理機上面。NodePublishVolume的接口是把NodeStatgeVolume之后的盤掛進容器里面。Kubernetes 在NodeStatgeVolume階段會給每個PV生成一個全局掛載點，如下圖：

通過判斷這個掛載點是否掛載可以方式PV重復掛載導致出錯。接下來NodePublishVolume把NodeStatgeVolume的的掛載點掛載的自己Pod文件夾下，最終這個Pod的掛載點會被掛載進容器里面。

存儲作為基礎組件，直接和本地盤打交道，所以我們一個要解決的事情就是如果Kubernetes 管理本地盤。

kubernetes管理本地盤

通過官方提供的local-static-provisioner自動生成LocalPersistentVolume管理磁盤。

LocalPersistentVolume是Kubernetes提供的一種管理本地盤的資源。

通過statefulset 管理有狀態(tài)的存儲服務， 為每個pod分配一個單獨的磁盤可以使用volumeClaimTemplates給每個pod生成唯一的pvc，具體規(guī)則${claimNmae}-${podName}，事先準備好PVC 和 PV，通過Statefulset 我們就可以把我們的存儲托管到云上了。另外借助daemonset，可以把我們gateway模塊部署到每一個node上面。處理云存儲的請求。

1）降低運維成本

基于Kubernetes和statfulset獲得了滾動更新，灰度更新，健康檢查，快速擴容等功能，只需要一組yaml文件就可以快速搭建一個集群，相比于傳統(tǒng)寫ansible腳本部署的方式復雜度大大降低。

2）降低開發(fā)運維成本

由于Kubernetes把存儲抽象成StorageClass PersistentVolume PersistentVolumeClaim。我們可以通過他們管理我們的存儲資源，基于Kubernetes lable的過濾功能，可以實現(xiàn)簡單的關系查詢，通過PVC與PV管理存儲資源，減少管理端的開發(fā)。定位問題也能通過POD信息快速定位到問題機器和問題云盤。而且接入Kubernetes生態(tài)上的prometheus后，監(jiān)控告警也能快速開發(fā)。

3）隔離性增強

docker限制cpu memory使用，減少進程之間資源互相干擾，進一步提升資源利用率。

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝