容器化RDS系列文章：

• 容器化RDS：計(jì)算存儲(chǔ)分離架構(gòu)下的“Split-Brain”

  

  成都創(chuàng)新互聯(lián)公司專(zhuān)注于長(zhǎng)春企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè),商城網(wǎng)站制作。長(zhǎng)春網(wǎng)站建設(shè)公司,為長(zhǎng)春等地區(qū)提供建站服務(wù)。全流程按需定制網(wǎng)站，專(zhuān)業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)公司專(zhuān)業(yè)和態(tài)度為您提供的服務(wù)

• 容器化RDS：計(jì)算存儲(chǔ)分離還是本地存儲(chǔ)？

• 容器化RDS：你需要了解數(shù)據(jù)是如何被寫(xiě)"壞"的

• 容器化RDS：PersistentLocalVolumes和VolumeScheduling

RDS 并不是新生事物，新鮮的是通過(guò)容器技術(shù)和容器編排技術(shù)構(gòu)建 RDS。對(duì)金融客戶(hù)而言，他們有強(qiáng)烈擁抱 Docker 和 Kubernetes 的愿望，但可用性是嘗試新技術(shù)的前提。存儲(chǔ)是持久化應(yīng)用的關(guān)鍵資源，它并不性感，卻是 Monolithic 應(yīng)用走向 Cloud-Native 架構(gòu)的關(guān)鍵。Kubernetes 存儲(chǔ)子系統(tǒng)已經(jīng)非常強(qiáng)大，但是還欠缺一些基礎(chǔ)功能，譬如支持 Expand Volume（部分 Storage Vendor 支持）和 SnapShot。本文嘗試從我們的實(shí)現(xiàn)分享如下幾個(gè)內(nèi)容：

• 現(xiàn)有 Kubernetes 存儲(chǔ)插件系統(tǒng)問(wèn)題

• Container Storage Interface（CSI）

• 基于CSI 和分布式文件系統(tǒng)實(shí)現(xiàn)在 MySQL 的 Volume 動(dòng)態(tài)擴(kuò)展

• 對(duì) CSI 的展望

名詞說(shuō)明：

原名	簡(jiǎn)稱(chēng)
容器編排系統(tǒng)	CO.
存儲(chǔ)提供者	SP.
存儲(chǔ)插件接口	Volume Plugin Interface
存儲(chǔ)驅(qū)動(dòng)	Volume Driver
容器存儲(chǔ)接口 Container Storage Interface	CSI

如有遺漏，不吝賜教。

現(xiàn)有 Kubernetes 存儲(chǔ)插件系統(tǒng)問(wèn)題

可供選的容器編排系統(tǒng)（后面簡(jiǎn)稱(chēng) CO.）不少，除去 Kubernetes 還有 Mesos、Swarm、Cloud Foundry。以 Kubernetes 為例，其通過(guò) PersistentVolume 抽象對(duì)以下存儲(chǔ)的支持：

• 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

• VMware Photon

• Portworx Volumes

• ScaleIO Volumes

• StorageOS

不可謂不豐富。Kubernetes 以插件化的方式支持存儲(chǔ)廠商（后面簡(jiǎn)稱(chēng) SP.）。SP. 通過(guò)實(shí)現(xiàn) Kubernetes 存儲(chǔ)插件接口（后面簡(jiǎn)稱(chēng) Volume Plugin Interface）的方式提供自己的存儲(chǔ)驅(qū)動(dòng)（后面簡(jiǎn)稱(chēng) Volume Driver）。

• VolumePlugin

• PersistentVolumePlugin

• DeletableVolumePlugin

• ProvisionableVolumePlugin

• ExpandableVolumePlugin

• Provisioner

• Deleter

以上接口并不需要全部實(shí)現(xiàn)，其中 VolumePlugin[1] 是必須實(shí)現(xiàn)的接口。
系統(tǒng)架構(gòu)圖如下：

這種方式為 Kubernetes 提供了豐富的存儲(chǔ)支持列表，但是在具體實(shí)現(xiàn)上，SP. Volume Driver 代碼也在 Kubernetes 代碼倉(cāng)庫(kù)（又叫in-tree），它帶來(lái)幾個(gè)顯著的問(wèn)題。
從 Kubernetes 的角度看：

• 需要在 Kubernetes 中給各個(gè) SP. 賦權(quán)以便他們能夠提交代碼到倉(cāng)庫(kù)；

• Volume Driver 由各個(gè) SP. 提供，Kubernetes 的開(kāi)發(fā)者并不了解每個(gè)細(xì)節(jié)，導(dǎo)致這些代碼難于維護(hù)和測(cè)試；

• Kubernetes 的發(fā)布節(jié)奏和各位 SP. Volume Driver 的節(jié)奏并不一致，隨著支持的 SP. 增多，溝通、維護(hù)、測(cè)試成本會(huì)越來(lái)越高；

• 這些 SP. Volume Driver 并不是 Kubernetes 本身需要的。

從 SP. 的角度看：

• 提交一個(gè)新特性或者修復(fù) bug，都需要提交代碼到 Kubernetes 倉(cāng)庫(kù)，在本地編譯 Kubernetes 的都知道，這個(gè)過(guò)程是很痛苦的，這對(duì) SP. 而言是完全不必要的成本。

一個(gè)統(tǒng)一的，大家認(rèn)可的容器存儲(chǔ)接口越來(lái)越有必要。

Container Storage Interface（CSI）

基于這些問(wèn)題和挑戰(zhàn)，CO 廠商提出 Container Storage Interface 用來(lái)定義容器存儲(chǔ)標(biāo)準(zhǔn)，它獨(dú)立于 Kubernetes Storage SIG，由 Kubernetes、Mesos、Cloud Foundry 三家一起推動(dòng)。個(gè)人理解它有如下2個(gè)核心目標(biāo)：

• 提供統(tǒng)一的 CO. 和 SP. 都遵循的容器存儲(chǔ)接口。

• 一旦 SP. 基于 CSI 實(shí)現(xiàn)了自身的 Volume Driver，即可在所有支持 CSI 的 CO 中平滑遷移。

Note：Container Storage Interface 定義[2]。
還有一個(gè)附帶的好處是，一旦 CO. 和 SP. 都遵循 CSI，就便于將 Volume Driver 解耦到 Kubernetes 的外部（又叫 out-of-tree）。Kubernetes 只用維護(hù) CSI 接口，不用再維護(hù) SP. 的具體實(shí)現(xiàn)，維護(hù)成本大大降低。
CSI 優(yōu)化下的架構(gòu)圖：

可以看到，Kubernetes 和 SP. 從此涇渭分明，但事情并沒(méi)有那么簡(jiǎn)單，借用一位大神說(shuō)的：The performance improvement does not materialize from the air, it comes with code complexity increase.和性能一樣，擴(kuò)展性和解耦也不是憑空出現(xiàn)。上圖可進(jìn)一步細(xì)化成下圖：

明顯的變化有：

• Controller Plane、Kubelet 不再直接與 Volume Driver 交互，引入 external-provisioner 和 external-attacher 完成該工作；

• SP. Volume Driver 會(huì)由獨(dú)立的容器運(yùn)行；

• 為了實(shí)現(xiàn) external-provisioner、external-attacher 和 SP. Volume Driver 的交互引入 gRPC 協(xié)議（標(biāo)紅箭頭）。

還有一些其他的變化：

• 在 Kubernetes 端 引入新的對(duì)象：

  
  

  CSIPersistentVolumeSource：該類(lèi)型 PV 由 CSI Driver 提供

  VolumeAttachment：同步 Attach 和 Dettach 信息

  
  

• 引入新的名稱(chēng)：

  
  

  mount/umount：NodePublishVolume/NodeUnpublishVolume

  attach/dettach：ControllerPublishVolume/ControllerUnpublishVolume

Note：Kubernetes 適配 CSI 設(shè)計(jì)文檔[3]。
可見(jiàn)，為了達(dá)到這個(gè)目標(biāo)，相比原來(lái)復(fù)雜不少，但收益巨大，Kubernetes 和 SP. 的開(kāi)發(fā)者可以專(zhuān)注于自身的業(yè)務(wù)。
即便如此，在現(xiàn)有的 CSI 上做擴(kuò)展有時(shí)也在所難免。

基于 CSI 和分布式文件系統(tǒng)實(shí)現(xiàn)在 MySQL 上的 Dynamically Expand Volume

Kubernetes 存儲(chǔ)子系統(tǒng)已經(jīng)非常強(qiáng)大，但是還欠缺一些基礎(chǔ)功能，譬如支持 Expand Volume （部分 Storage Vendor 支持）和 SnapShot，尤其是 Expand Volume，這是必須的功能，因?yàn)殡S著業(yè)務(wù)的變化，容量的增加在所難免，一旦容量接近閾值，若以遷庫(kù)的方式擴(kuò)展存儲(chǔ)容量，成本太高。
但現(xiàn)狀并不樂(lè)觀，Kubernetes 1.10.2 使用 CSI 0.2.0，其并不包含 Expand Volume 接口，這意味著即便底層的存儲(chǔ)支持?jǐn)U容，Kubernetes 也無(wú)法使用該功能，所以我們需要做點(diǎn) hard code 實(shí)現(xiàn)該功能：

• 擴(kuò)展 CSI Spec

• 擴(kuò)展 CSI Plugin

• 基于 CSI Spec 實(shí)現(xiàn) Storage Driver

• 演示

• 其他

擴(kuò)展 CSI Spec
前面提到，在 CSI 中引入了 gRPC，個(gè)人理解在 CSI 的場(chǎng)景有如下3個(gè)優(yōu)點(diǎn)：

• 基于 protobuf 定義強(qiáng)類(lèi)型結(jié)構(gòu)，便于閱讀和理解

• 通過(guò) stub 實(shí)現(xiàn)遠(yuǎn)程調(diào)用，編程邏輯更清晰

• 支持雙工和流式，提供雙向交互和實(shí)時(shí)交互

網(wǎng)絡(luò)上介紹 gRPC 和 protobuf 的文章很多，這里不贅述。
通過(guò) gRPC，實(shí)現(xiàn) CSI 各個(gè)組件的交互。為支持 expand volume 接口，需要修改 csi.proto，在 CSI 0.2.0 的基礎(chǔ)上添加需要的 rpc，重點(diǎn)如下：

CSI Driver 實(shí)現(xiàn)如下所有接口：

CreateVolume

DeleteVolume

ControllerPublishVolume

ControllerUnpublishVolume

ValidateVolumeCapabilities

ListVolumes

GetCapacity

ControllerGetCapabilities

RequiresFSResize

ControllerResizeVolume

這里涉及到比較復(fù)雜的調(diào)試和適配工作，還有一些其他的工作：

• 定義 CSI 對(duì)應(yīng)的 StorageClass，并設(shè)置 allowVolumeExpansion 為 true

• 啟用 Feature Gates：ExpandPersistentVolumes

• 新增 Admission Control：PersistentVolumeClaimResize

• ……

演示

通過(guò)擴(kuò)展 Container Storage Interface 0.2.0，我們?cè)贙ubernetes 1.10.2 上實(shí)現(xiàn)了在線擴(kuò)容文件系統(tǒng)擴(kuò)容。對(duì) MySQL 實(shí)例制造兩種類(lèi)型工作負(fù)載：

• 通過(guò)鍵值更新和查詢(xún)

• 批量數(shù)據(jù)加載數(shù)據(jù)

通過(guò)上圖可以觀察到：

• 讀數(shù)一：MySQL QPS 在正常波動(dòng)范圍內(nèi)；

• 讀數(shù)二：持續(xù)批量加載數(shù)據(jù)，MySQL 文件系統(tǒng)容量不斷變大；

• 讀數(shù)三：在20分鐘內(nèi)，在線動(dòng)態(tài)擴(kuò)容 Volume 和 Filesystem 2 次, 過(guò)程高效平滑。

其他
工作到這里基本結(jié)束，要改動(dòng)的地方不少，客觀上并不簡(jiǎn)單。如果沒(méi)有 Kubernetes 和 CSI，難度會(huì)更大。
通過(guò)此方法可以完成對(duì)其他 Storage Vendor 的擴(kuò)展，譬如 FCSan、iSCSI。

對(duì) CSI 的展望

目前 CSI 已發(fā)展到 0.2.0，0.3.0 也發(fā)布在即。

0.3.0 中呼聲最高的特性是 Snapshot。借助該功能，可以實(shí)現(xiàn)備份和異地容災(zāi)。但是為了實(shí)現(xiàn)該功能，在 Kubernetes 現(xiàn)有的 Control-Plane 上還要添加新的 Controller，客觀上，復(fù)雜度會(huì)進(jìn)一步提高。
同時(shí)，部分 in-tree Volume Driver 已通過(guò) CSI 遷移到外部，考慮到 Kubernetes 整體的發(fā)布節(jié)奏和 API 的穩(wěn)定性，個(gè)人覺(jué)得節(jié)奏不會(huì)太快。
除此之外，CSI 可能還有更多工作要做。以一個(gè)高可用的場(chǎng)景為例，當(dāng)一個(gè) Node 發(fā)生故障時(shí)，CO 觸發(fā) Unmount->Dettach->Attach->Mount 的流程，配合 Pod 的漂移，借助 CSI 定義的接口，Unmount、Dettach、Attach、Mount 由SP. 自身現(xiàn)實(shí)，但是 Unmount->Dettach->Attach->Mount 的流程還是有 CO 控制，這個(gè)流程并不標(biāo)準(zhǔn)，但是對(duì) workload 又至關(guān)重要。

又想起<人月神話>中的那句 “No Silver Bullet”。
相關(guān)鏈接：

1. https://github.com/kubernetes/kubernetes/blob/afa68cc28749c09f8655941b111e46d85689daf8/pkg/volume/plugins.go#L95

2. https://github.com/container-storage-interface/spec/blob/master/spec.md

3. https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md

4. https://github.com/container-storage-interface/spec/blob/master/csi.proto

5. https://docs.google.com/document/d/1kVrNwA2f4ite8_9QvCy-JQA_00hxGGMdER3I84dUDqQ/edit?usp=sharing

| 作者簡(jiǎn)介

熊中哲，沃趣科技產(chǎn)品及研發(fā)負(fù)責(zé)人

曾就職于阿里巴巴和百度，超過(guò)10年關(guān)系型數(shù)據(jù)庫(kù)工作經(jīng)驗(yàn)，目前致力于將云原生技術(shù)引入到關(guān)系型數(shù)據(jù)庫(kù)服務(wù)中。

當(dāng)前文章：容器化RDS：借助CSI擴(kuò)展Kubernetes存儲(chǔ)能力-創(chuàng)新互聯(lián)
標(biāo)題URL：http://weahome.cn/article/jihsi.html