本文发表已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

使用 CSI 和 Kubernetes 动态扩展卷

作者：Orain Xiong (WoquTech) | 2018 年 8 月 2 日，星期四

Kubernetes 本身就有一个非常强大的存储子系统，涵盖了相当广泛的用例。然而，当计划使用 Kubernetes 构建生产级关系数据库平台时，我们面临一个巨大的挑战：如何提供存储。本文介绍了如何扩展最新的容器存储接口 0.2.0 并与 Kubernetes 集成，并演示了动态扩展卷容量的基本方面。

引言

随着我们专注于客户，特别是在金融领域，容器编排技术的采用正在大幅增加。

他们期待通过开源解决方案来重新设计已经在虚拟化基础设施或裸机上运行了多年的现有单体应用程序。

考虑到可扩展性和技术成熟程度，Kubernetes 和 Docker 处于列表的最顶端。但是，将单体应用程序迁移到像 Kubernetes 这样的分布式编排系统是一项挑战，关系数据库对于迁移至关重要。

关于关系数据库，我们应该注意存储。Kubernetes 本身就有一个非常强大的存储子系统。它非常有用，涵盖了相当广泛的用例。当计划在生产中使用 Kubernetes 运行关系数据库时，我们面临一个巨大的挑战：如何提供存储。仍然有一些基本功能未实现。特别是动态扩展卷。这听起来很无聊，但除了创建、删除、挂载和卸载等操作之外，它是非常需要的。

目前，仅以下存储配置器支持扩展卷：

gcePersistentDisk
awsElasticBlockStore
OpenStack Cinder
glusterfs
rbd

为了启用此功能，我们应该将功能门ExpandPersistentVolumes设置为 true，并启用PersistentVolumeClaimResize准入插件。一旦启用了PersistentVolumeClaimResize，如果存储类的allowVolumeExpansion字段设置为 true，则允许调整大小。

不幸的是，即使底层存储提供商具有此功能，也无法通过容器存储接口（CSI）和 Kubernetes 动态扩展卷。

本文将简要介绍 CSI，然后逐步说明如何在现有 CSI 和 Kubernetes 上引入新的扩展卷功能。最后，本文将演示如何动态扩展卷容量。

容器存储接口（CSI）

为了更好地理解我们要做什么，我们需要了解的第一件事是什么是容器存储接口。目前，Kubernetes 中现有的存储子系统仍然存在一些问题。存储驱动程序代码在 Kubernetes 核心存储库中维护，难以进行测试。除此之外，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”卷插件、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，该 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。

结论

无论应用程序运行在什么基础设施上，数据库始终是关键资源。拥有更高级的存储子系统来完全支持数据库需求至关重要。这将有助于推动更广泛地采用云原生技术。

←上一个

下一个→