使用 CSI 和 Kubernetes 动态扩容卷

Kubernetes 本身包含一个功能强大的存储子系统，涵盖了相当广泛的使用场景。然而，在规划使用 Kubernetes 构建生产级关系型数据库平台时，我们面临一个巨大挑战：存储方案。本文描述了如何扩展最新的 Container Storage Interface 0.2.0 并与 Kubernetes 集成，并演示了动态扩容卷容量的关键方面。

引言

随着我们聚焦客户，尤其是在金融领域，容器编排技术的采用呈巨大增长。

他们期待使用开源解决方案来重新设计那些已在虚拟化基础设施或裸金属上运行多年的现有单体应用。

考虑到可扩展性和技术成熟度，Kubernetes 和 Docker 名列前茅。但将单体应用迁移到像 Kubernetes 这样的分布式编排系统是具有挑战性的，关系型数据库对于迁移至关重要。

关于关系型数据库，我们应该关注存储。Kubernetes 本身包含一个功能强大的存储子系统。它非常有用，涵盖了相当广泛的使用场景。在规划在生产环境中使用 Kubernetes 运行关系型数据库时，我们面临一个巨大挑战：存储方案。仍有一些基本功能尚未实现。具体来说，就是动态扩容卷。这听起来枯燥，但却是高度必需的，除了创建、删除、挂载和卸载等操作之外。

目前，扩容卷仅适用于以下存储供应器

• gcePersistentDisk
• awsElasticBlockStore
• OpenStack Cinder
• glusterfs
• rbd

为了启用此功能，我们应该将 feature gate ExpandPersistentVolumes 设置为 true，并启用 PersistentVolumeClaimResize admission plugin。一旦 PersistentVolumeClaimResize 被启用，存储类中 allowVolumeExpansion 字段设置为 true 的将允许扩容。

不幸的是，尽管底层存储提供商支持此功能，但通过容器存储接口 (CSI) 和 Kubernetes 进行动态扩容卷是不可用的。

本文将对 CSI 进行简化视图，随后将逐步介绍如何在现有 CSI 和 Kubernetes 上引入新的扩容卷功能。最后，本文将演示如何动态扩容卷容量。

容器存储接口 (CSI)

为了更好地理解我们将要做什么，我们首先需要知道容器存储接口是什么。目前，Kubernetes 内部现有的存储子系统仍存在一些问题。存储驱动代码维护在 Kubernetes 核心仓库中，这使得测试变得困难。但除此之外，Kubernetes 需要授予存储供应商权限将代码提交到 Kubernetes 核心仓库。理想情况下，这应该在外部实现。

CSI 旨在定义一个行业标准，使支持 CSI 的存储提供商能够在支持 CSI 的容器编排系统之间可用。

此图描绘了一种与 CSI 集成的高级 Kubernetes 原型

• 引入了三个新的外部组件以解耦 Kubernetes 和存储提供商逻辑
• 蓝色箭头表示调用 API Server 的传统方式
• 红色箭头表示调用卷驱动的 gRPC

更多详情请访问：https://github.com/container-storage-interface/spec/blob/master/spec.md

扩展 CSI 和 Kubernetes

为了在 Kubernetes 之上启用扩容卷功能，我们应该扩展几个组件，包括 CSI 规范、“in-tree” 卷插件、external-provisioner 和 external-attacher。

扩展 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 规范之外，Kubernetes 中的 csiPlugin 接口也应该实现 expandablePlugin。csiPlugin 接口将代表 ExpanderController 扩展 PersistentVolumeClaim。

type ExpandableVolumePlugin interface {
VolumePlugin
ExpandVolumeDevice(spec Spec, newSize resource.Quantity, oldSize resource.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

• 创建 PVC qcfs-pvc，它将由存储类 csi-qcfs 动态供给

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

• 创建使用 PVC qcfs-pvc 的 MySQL 5.7 实例
• 为了模拟完全相同的生产级场景，实际上有两种不同的工作负载类型，包括
  • 批量插入以使 MySQL 消耗更多文件系统容量
  • 突发查询请求
• 通过编辑 pvc qcfs-pvc 配置动态扩容卷容量

Prometheus 和 Grafana 集成使我们能够可视化相应的关键指标。

我们注意到中间的读数显示 MySQL 数据文件大小在批量插入期间缓慢增加。同时，底部的读数显示文件系统在大约 20 分钟内扩展了两次，从 300 GiB 到 400 GiB，然后到 500 GiB。同时，上部的读数显示整个卷扩容过程立即完成，几乎不影响 MySQL QPS。

结论

无论应用运行在何种基础设施上，数据库始终是关键资源。拥有一个更先进的存储子系统以充分支持数据库需求至关重要。这将有助于推动云原生技术的更广泛采用。

• ←上一篇
• 下一篇→