Kubernetes本身具有包含了具有大量用例且功能強大的儲存子系統。然而，如果我們利用Kubernetes建設關係資料庫平臺，就需要面臨一個挑戰：建立資料儲存。本文用來講述如何擴充套件CSI(容器儲存介面)0.2.0同時整合Kubernetes，並且展示了動態擴容的重要性。

簡介

隨著我們對客戶的關注，尤其是對金融領域的客戶，我們可以發現容器編排技術具有很大的發展空間。開發者們希望能通過開源解決方案來重新設計執行在虛擬化基礎設施和裸金屬上的獨立應用程式。

對於可擴充套件性和技術成熟度兩方面，Kubernetes和Docker處於業內的頂端。關係資料庫對於遷移至關重要，但是將獨立應用程式遷移到像Kubernetes這樣的分散式編配十分具有挑戰性。

對於關係型資料庫來說，我們應該關注其儲存功能。Kubernetes本身具有強大的儲存子系統，其功能強大，包含用例廣泛。如果我們利用kubernetes建設關係資料庫平臺，就需要面臨一個挑戰：建立資料儲存。但是Kubernetes還有一些基本的功能沒有實現，尤其是動態擴容。這聽起來很無聊，但是建立、刪除、掛載和解除安裝等操作非常必要。

目前，擴容只能與儲存提供程式一起使用，例如：

• gcePersistentDisk

• awsElasticBlockStore

• OpenStack Cinder

• glusterfs

• rbd

為了啟用這個特性，我們需要設定feature-gate expandpersistentvolume為True，並開啟PersistentVolumeClaimResize准入外掛。一旦啟用了PersistentVolumeClaimResize，調整儲存大小的功能將被allowVolumeExpansion設定為True的儲存類開啟。

不幸的是，即使底層儲存提供程式具有此功能，通過容器儲存介面(CSI)和Kubernetes動態擴容依然不可用。

本文將給出CSI的簡化檢視，然後介紹如何在現有的CSI和Kubernetes上引入一個新的擴展卷特性。最後，本文將演示如何動態地擴容。

容器儲存介面（CSI）

為了更好地理解我們之後的工作，首先我們需要知道容器儲存介面是什麼。目前來看，Kubernetes現有的儲存子系統依然存在很多問題。儲存驅動程式程式碼維護在Kubernetes core儲存庫中，這一問題使測試十分不便。但除此之外，Kubernetes還需要授權儲存供應商將程式碼簽入Kubernetes核心儲存庫。但是理想情況下，這種需求應該在外部實現。CSI的設計目的是定義一個行業標準，該標準將使支援CSI的容器編排系統可用的儲存提供者能夠使用CSI。

這張圖描繪了一種與CSI結合的高階Kubernetes原型:

• 引入了三個新的外部元件來解耦Kubernetes和儲存提供程式邏輯

• 藍色箭頭表示對API伺服器呼叫的常規方法

• 紅色箭頭表示gRPC呼叫卷驅動程式

  詳見：https://github.com/container-storage-interface/spec/blob/master/spec.md

擴充套件CSI和Kubernetes

為了實現在Kubernetes上擴展卷的功能，我們應該擴充套件多個元件，包括CSI規範、“In-Tree”卷外掛、外部供應器和外部聯結器。

擴充套件CSI規範

最新的CSI 0.2.0中還沒有定義擴充套件量的特性。應該引入新的3個rpc，包括RequiresFSResize，ControllerResizeVolume和NodeResizeVolume。

service Controller {
rpc CreateVolume (CreateVolumeRequest)
  returns (CreateVolumeResponse) {}
……
rpc RequiresFSResize (RequiresFSResizeRequest)
  returns (RequiresFSResizeResponse) {}
rpc ControllerResizeVolume (ControllerResizeVolumeRequest)
  returns (ControllerResizeVolumeResponse) {}
}

service Node {
rpc NodeStageVolume (NodeStageVolumeRequest)
  returns (NodeStageVolumeResponse) {}
……
rpc NodeResizeVolume (NodeResizeVolumeRequest)
  returns (NodeResizeVolumeResponse) {}
}

擴充套件“In-Tree”卷外掛

為了擴充套件CSI規範，csiPlugin介面需要在Kubernetes上實現。csiPlugin介面將會擴充套件PersistentVolumeClaim用來代理ExpanderController。

type ExpandableVolumePlugin interface {
VolumePlugin
ExpandVolumeDevice(spec Spec, newSize resource.Quantity, oldSizeresource.Quantity) (resource.Quantity, error)
RequiresFSResize() bool
}

實現盤卷驅動

最後，為了抽象實現的複雜性，我們應該將單獨的儲存提供程式管理邏輯硬編碼到CSI規範中定義的以下函式中：

• CreateVolume

• DeleteVolume

• ControllerPublishVolume

• ControllerUnpublishVolume

• ValidateVolumeCapabilities

• ListVolumes

• GetCapacity

• ControllerGetCapabilities

• RequiresFSResize

• ControllerResizeVolume

示例：

讓我們用一個具體的使用者案例來演示這個特性。

• 為CSI儲存供應器建立儲存類

• allowVolumeExpansion: true
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: csi-qcfs
  parameters:
   csiProvisionerSecretName: orain-test
   csiProvisionerSecretNamespace: default
  provisioner: csi-qcfsplugin
  reclaimPolicy: Delete
  volumeBindingMode: Immediate

• 跨Kubernetes叢集部署CSI卷驅動程式，包括儲存供應器CSI -qcfsplugin

• 建立將由儲存類csi-qcfs動態提供的PVC qcfs-pvc

• apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
   name: qcfs-pvc
   namespace: default
  ....
  spec:
   accessModes:
   - ReadWriteOnce
   resources:
     requests:
       storage: 300Gi
   storageClassName: csi-qcfs

• 建立MySQL 5.7例項來使用PVC qcfs-pvc

• 為了反映完全相同的生產級場景，這裡分為兩種不同型別的工作負載，包括:

• • 批量插入，使MySQL消耗更多的檔案系統容量

  • 增加查詢請求

• 通過編輯pvc qcfs-pvc配置動態擴充套件容量

Prometheus和Grafana的整合使我們視覺化相應的關鍵指標。

結論：

無論基礎設施應用程式執行在何處，資料庫始終是一個關鍵資源。用高階的儲存子系統來完全支援資料庫需求非常重要。這將有助於推動更廣泛地採用雲本地技術。