容器化 RDS：借助 CSI 擴展 Kubernetes 存儲能力

容器化RDS系列文章：

• 容器化RDS：計算存儲分離架構下的“Split-Brain”

• 容器化RDS：計算存儲分離還是本地存儲？

• 容器化RDS：你需要了解數據是如何被寫"壞"的

• 容器化RDS：PersistentLocalVolumes和VolumeScheduling

RDS 并不是新生事物，新鮮的是通過容器技術和容器編排技術構建 RDS。對金融客戶而言，他們有強烈擁抱 Docker 和 Kubernetes 的愿望，但可用性是嘗試新技術的前提。存儲是持久化應用的關鍵資源，它并不性感，卻是 Monolithic 應用走向 Cloud-Native 架構的關鍵。Kubernetes 存儲子系統已經非常強大，但是還欠缺一些基礎功能，譬如支持 Expand Volume（部分 Storage Vendor 支持）和 SnapShot。本文嘗試從我們的實現分享如下幾個內容：

• 現有 Kubernetes 存儲插件系統問題

• Container Storage Interface（CSI）

• 基于CSI 和分布式文件系統實現在 MySQL 的 Volume 動態擴展

• 對 CSI 的展望

名詞說明：

原名	簡稱
容器編排系統	CO.
存儲提供者	SP.
存儲插件接口	Volume Plugin Interface
存儲驅動	Volume Driver
容器存儲接口 Container Storage Interface	CSI

如有遺漏，不吝賜教。

現有 Kubernetes 存儲插件系統問題

可供選的容器編排系統（后面簡稱 CO.）不少，除去 Kubernetes 還有 Mesos、Swarm、Cloud Foundry。以 Kubernetes 為例，其通過 PersistentVolume 抽象對以下存儲的支持：

• 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 以插件化的方式支持存儲廠商（后面簡稱 SP.）。SP. 通過實現 Kubernetes 存儲插件接口（后面簡稱 Volume Plugin Interface）的方式提供自己的存儲驅動（后面簡稱 Volume Driver）。

• VolumePlugin

• PersistentVolumePlugin

• DeletableVolumePlugin

• ProvisionableVolumePlugin

• ExpandableVolumePlugin

• Provisioner

• Deleter

以上接口并不需要全部實現，其中 VolumePlugin[1] 是必須實現的接口。
系統架構圖如下：

這種方式為 Kubernetes 提供了豐富的存儲支持列表，但是在具體實現上，SP. Volume Driver 代碼也在 Kubernetes 代碼倉庫（又叫in-tree），它帶來幾個顯著的問題。
從 Kubernetes 的角度看：

• 需要在 Kubernetes 中給各個 SP. 賦權以便他們能夠提交代碼到倉庫；

• Volume Driver 由各個 SP. 提供，Kubernetes 的開發者并不了解每個細節，導致這些代碼難于維護和測試；

• Kubernetes 的發布節奏和各位 SP. Volume Driver 的節奏并不一致，隨著支持的 SP. 增多，溝通、維護、測試成本會越來越高；

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

從 SP. 的角度看：

• 提交一個新特性或者修復 bug，都需要提交代碼到 Kubernetes 倉庫，在本地編譯 Kubernetes 的都知道，這個過程是很痛苦的，這對 SP. 而言是完全不必要的成本。

一個統一的，大家認可的容器存儲接口越來越有必要。

Container Storage Interface（CSI）

基于這些問題和挑戰，CO 廠商提出 Container Storage Interface 用來定義容器存儲標準，它獨立于 Kubernetes Storage SIG，由 Kubernetes、Mesos、Cloud Foundry 三家一起推動。個人理解它有如下2個核心目標：

• 提供統一的 CO. 和 SP. 都遵循的容器存儲接口。

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

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

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

明顯的變化有：

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

• SP. Volume Driver 會由獨立的容器運行；

• 為了實現 external-provisioner、external-attacher 和 SP. Volume Driver 的交互引入 gRPC 協議（標紅箭頭）。

還有一些其他的變化：

• 在 Kubernetes 端 引入新的對象：

  
  

  CSIPersistentVolumeSource：該類型 PV 由 CSI Driver 提供

  VolumeAttachment：同步 Attach 和 Dettach 信息

  
  

• 引入新的名稱：

  
  

  mount/umount：NodePublishVolume/NodeUnpublishVolume

  attach/dettach：ControllerPublishVolume/ControllerUnpublishVolume

Note：Kubernetes 適配 CSI 設計文檔[3]。
可見，為了達到這個目標，相比原來復雜不少，但收益巨大，Kubernetes 和 SP. 的開發者可以專注于自身的業務。
即便如此，在現有的 CSI 上做擴展有時也在所難免。

基于 CSI 和分布式文件系統實現在 MySQL 上的 Dynamically Expand Volume

Kubernetes 存儲子系統已經非常強大，但是還欠缺一些基礎功能，譬如支持 Expand Volume （部分 Storage Vendor 支持）和 SnapShot，尤其是 Expand Volume，這是必須的功能，因為隨著業務的變化，容量的增加在所難免，一旦容量接近閾值，若以遷庫的方式擴展存儲容量，成本太高。
但現狀并不樂觀，Kubernetes 1.10.2 使用 CSI 0.2.0，其并不包含 Expand Volume 接口，這意味著即便底層的存儲支持擴容，Kubernetes 也無法使用該功能，所以我們需要做點 hard code 實現該功能：

• 擴展 CSI Spec

• 擴展 CSI Plugin

• 基于 CSI Spec 實現 Storage Driver

• 演示

• 其他

擴展 CSI Spec
前面提到，在 CSI 中引入了 gRPC，個人理解在 CSI 的場景有如下3個優點：

• 基于 protobuf 定義強類型結構，便于閱讀和理解

• 通過 stub 實現遠程調用，編程邏輯更清晰

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

網絡上介紹 gRPC 和 protobuf 的文章很多，這里不贅述。
通過 gRPC，實現 CSI 各個組件的交互。為支持 expand volume 接口，需要修改 csi.proto，在 CSI 0.2.0 的基礎上添加需要的 rpc，重點如下：