浅谈Kubernetes 持久化存储管理

云计算
Kubernetes通过PV、PVC、StorageClass、CSI标准构建了一套完善的存储管理机制,G行充分利用Kubernetes资源对象,并针对行内现状,引入多种存储类型和对应的CSI存储插件,实现了多种CSI并行及自动化容器存储管理。

​一、引言

Kubernetes从版本1.0以后,引入了两个新的 API 资源:PersistentVolume 和 PersistentVolumeClaim 实现了对存储供应的独立管理。持久卷(PersistentVolume,PV) 是对存储资源在集群中的抽象;持久卷声明(PersistentVolumeClaim,PVC)则是用户对存储资源的请求。尽管PV和PVC已经实现了对用户存储资源请求的管理,但是管理员仍需手动创建各种类型的PV 实现对用户的存储供应。为了实现存储资源的动态供应,Kubernetes从版本1.4以后就引入了存储类(StorageClass)资源。自1.9版本以后,Kubernetes又引入了容器存储接口(Container Storage Interface CSI),将存储驱动代码从Kubernetes的核心库中剥离了出来,在Kubernetes和外部存储间引入了一套标准的存储管理接口,使得外部存储可以通过实例化该接口动态为容器提供存储资源。本文将从上述资源对象入手,对Kubernetes的存储管理进行简要说明,并简述G行在容器存储管理上的实践。

二、PV和PVC

1、PV

PV(PersistentVolume) 是集群中存储资源,一般由管理员创建或者由StorageClass自动创建。他们不同于普通的volume,其生命周期独立于Pod存在。PV主要包括了存储能力、访问模式、存储类型、回收策略、后端存储类型等关键信息的描述。下文我们来创建一个PV,YAML如下:

图片

针对这个例子,我们来对PV的关键属性进行简要描述:

  • Capacity:描述指定存储设备的存储能力,目前仅支持对存储大小(storage)的设置,未来可能支持IOPS、吞入量等;
  • VolumeMode:Kubernetes支持两种存储卷模式:Filesystem(文件系统)和Block(块设备),默认值为Filesytem。当VolumeMode指定为Filesystem时,Kubernetes会在首次挂载时实现对文件系统的初始化;当VolumeMode指定为Block时,则会以原始块设备的形式挂载给Pod,Pod和Volume之间不会有任何文件系统层;
  • AccessModes:描述用户对存储资源的访问权限,需要注意的是一个PV在同一时刻只能以一种访问模式被挂载,其可选的访问模式包括:a. ReadWriteOnce(RWO):卷可以被一个节点以读写方式挂载,可以被同一节点上的多个Pod访问;b. ReadOnlyMany(ROX):卷可以被多个节点以只读方式挂载;c. ReadWriteMany(RWX):卷可以被多个节点以读写方式挂载;d. ReadWriteOncePod(RWOP):卷可以被单个Pod 以读写方式挂载。此模式必须需要CSI支持以及需要 Kubernetes 1.22 以上版本。
  • StorageClassName:指定的存储类别(StorageClass),只有StorageClassName相同的PV和PVC才能进行绑定。若StorageClassName不进行设置,则会被设置为集群默认的 StorageClass。

2、PVC

PVC 是用户对存储资源的申请,主要包括了存储空间请求、访问模式、选择条件和存储类别等信息的描述。集群根据PVC的描述为其选择匹配的PV进行绑定。下面我们来创建一个PVC,YAML如下:

图片

针对这个例子,我们来对PVC的关键属性进行简要描述:

  • Resources:描述对存储资源的请求,例如存储大小(requests.storage);
  • VolumeMode:存储卷模式,其设置跟PV的设置相同;
  • AccessModes:访问模式,其设置跟PV的设置相同;
  • StorageClassName:存储类别(StorageClass)名称,当系统设置了StorageClass,则系统会自动为PVC创建相应的PV并进行绑定;
  • Selector:选择器,PVC会根据selector的内容对满足条件的PV进行筛选,选择KV匹配的PV进行绑定。

PVC根据上述属性描述选择与之匹配的PV进行绑定,需要注意的是,PVC只会在相同的Namespace内选择PV,同样的,Pod也只能挂载相同的Namespace的PVC。只有当PVC选择到合适的PV时,才可以被Pod进行正常挂载,示例如下:

图片

3、PV和PVC的生命周期

PV生命周期的各个阶段:

  • Available(可用):尚未与任何PVC进行绑定;
  • Bound(已绑定):已经绑定到某个PVC;
  • Released(已释放):所绑定的PVC已被删除,但是资源尚未被集群回收;
  • Failed(失败):卷自动回收操作失败。

PV和PVC的相互关系如下图1所示的生命周期:

图片

图1

Kubernetes提供了两种存储资源的供应模式:

静态模式:集群管理员必须联系存储管理员手动来创建新的存储卷, 然后在 Kubernetes 集群创建 PersistentVolume 对象来表示这些卷,最后用户创建PVC进行绑定。

动态模式:集群管理员无需手动创建PV卷,通过配置StorageClass来实现对存储类的管理和资源的动态供应。用户申请PVC时,指定StorageClassName,对应的StorageClass将会自动完成对应存储类的存储卷创建以及Kubernetes集群中PV的创建。若StorageClassName声明为"", 则说明该PVC禁止使用动态模式。

三、StorageClass和CSI

1、StorageClass

动态供应模式主要基于StorageClass对象实现,集群管理员可以针对不同的存储类型创建不同的StorageClass,对用户屏蔽了底层存储的细节。基于StorageClass的动态存储供应逐步成为了云平台的标准存储配置模式。StorageClass主要包括了存储提供者以及相关存储参数的配置。StorageClass一旦创建,则不能被修改,只能删除重建。示例如下:

图片

示例声明一个名为standard,由Kubernetes.io/aws-ebs提供的存储类。

2、CSI

StorageClass提供了存储动态供应的功能,但是各种后端存储插件的代码都必须被放入Kubernetes的主干代码中以供调用,这种紧耦合的开发模式,导致了巨大的维护成本和诸多问题。因此Kubernetes基于上述考虑,推出了容器存储接口标准(CSI)。各存储提供方自行维护自己的存储插件代码,只要满足CSI 标准,即可让Kubernetes进行调用,无需再耦合在Kubernetes的主干代码中。CSI 存储插件的标准实现主要包含两种组件:

Controller Plugin:Controller主要实现存储资源和存储类的管理,一般为单实例部署,可以部署在任意节点上。

Node Plugin:主要实现对Node上存储卷的管理和操作,包括卷的挂载、卸载等,一般部署为Daemonset,每个Node上运行一个Pod。

四、G行的容器存储管理实践

1、背景

G行在云平台3.0之前已经引入了集中式NAS存储,在用户需要申请PV卷时,需要先向存储管理员提出申请,然后由存储管理员在存储端按用户需求创建一块存储卷,再由系统管理员在集群中手动创建PV卷完成资源交付,最后用户在系统中创建PVC完成资源申请,流程如下图2所示:

图片

图2

从上述流程描述可以看出,整个过程中需要大量人为介入,缺乏自动化。Kubernetes本身提供了StorageClass 用于支持资源的动态创建,因此G行考虑在现有基础上引入CSI存储插件,实现了自动化存储交付。并在原有的基础上,引入了高性能本地存储和分布式SAN存储,扩充了存储资源类型。

2、CSI的部署与实践

图片

图3

CSI的部署过程如上图3所示,过程相对比较复杂,每次Kubernetes集群创建后,若都需要手动部署CSI插件,无疑会增加系统运维的成本。G行在此基础上引入APP标准化交付框架,将Kubernetes的集群创建操作,以及CSI插件的部署进行了集成,实现了Kubernetes集群的一键化创建,标准化交付。当集群创建完成后,相应的CSI插件及StorageClass就已经自动完成了部署,用户即可直接使用。

集群中已经部署好用户所需的StorageClass,存储资源申请只需直接创建PVC即可,示例如下:

图片

刚创建完的PVC的状态为Pending。

图片

CSI的Controller会Watch kube-apiserver,检测StorageClass的provisioner为自身的PVC的变化,当感知到PVC的创建后,会自动去存储端进行存储卷的创建,存储卷创建完以后,Controller会自动在集群中创建PV。

图片

图4

整个过程结束后,可以在集群中看到PV已经被成功创建,PVC的状态已经变为了Bound。

图片

从图4上述过程可以看出,用户申请存储资源的整个流程中,无需存储管理员和集群管理员手动干预,即可自动存储资源交付。

3、使用CSI支持动态扩容

在云平台3.0中,G行在云平台3.0中的引入了高性能本地存储和分布式SAN存储,这两类存储在存储层基于KVM动态扩容技术可实现对后端存储卷的动态扩容。在容器平台中,G行对相应的CSI Controller进行了升级优化,实现了EXPAND_VOLUME的功能,响应用户的扩容需求。当CSI Controller在Watch到相应的修改后,会调用存储后端接口对相应的存储卷和PV卷进行扩容,并对文件系统根据相应设置进行调整。

首先在存储插件部署时,需要将StorageClass的allowVolumeExpansion字段设置为True,开启动态扩容,StorageClaas配置示例如下:

图片

对于正在运行中的业务,若用户有扩容需求,无需卸载其使用的PV卷,直接修改PVC的requests大小,CSI Controller则立即尝试调用存储后端接口对相应的存储卷和PV卷进行扩容,后端存储在接收到扩容需求后,调用virsh blockresize命令调整存储卷大小,并将处理结果返回给CSI Controller。CSI Controller确认存储卷已经扩容后,找到当前存储卷所挂载的node节点,请求相应的node节点上的CSI Daemonset对扩容卷进行resize,将扩容的容量扩充进文件系统中。至此,用户的动态扩容需求就完成了。整个扩容流程,用户无需暂停业务,业务连续性和稳定性得到了保障。

4、多种CSI并行

G行在云平台3.0中支持了集中式NAS存储、高性能本地存储和分布式SAN存储,并针对这三类存储类进行了性能测试,针对测试结果梳理了相应的用户使用场景,部分测试数据如下(测试数据仅供参考):

图片

集中式NAS存储:作为文件存储,读写性能弱于块存储,原生支持文件系统的多节点读写,适用于有文件共享需求的用户使用。

分布式SAN存储:分布式块存储,读写性能好。在存储模式为Filesystem时不支持多节点读写,适用于对存储性能要求较高,无共享存储需求的用户使用。

高性能本地存储:本地块存储,读写性能好。同样不支持Filesystem存储模式下的多节点读写,适用于单存储卷容量300G以下,无共享存储需求,对存储性能要求高的用户使用。

图片

五、总结

Kubernetes通过PV、PVC、StorageClass、CSI标准构建了一套完善的存储管理机制,G行充分利用Kubernetes资源对象,并针对行内现状,引入多种存储类型和对应的CSI存储插件,实现了多种CSI并行及自动化容器存储管理。存储管理员和系统管理员无需再手动创建存储卷和PV卷,只需在项目创建之初,针对不同的存储类(StorageClass)给项目分配存储配额。用户需要时,可直接创建PVC,CSI 控制器会根据用户的PVC参数,调用存储端接口,自动创建存储卷以及PV卷,实现了用户的即时申请,即时可用,当用户有扩容需求时,现有CSI控制器也可支持PV卷的动态扩容,无需管理员手动调整。相比静态交付管理的模式,集群管理员无需预先配置存储,既降低了人力成本,又提升了交付效率和业务的连续性。同时,多种存储类的引入也满足了不同使用场景下的用户需求。


责任编辑:武晓燕 来源: 匠心独运维妙维效
相关推荐

2022-08-30 10:15:27

Kubernetes数据持久化管理

2019-01-24 09:04:50

Kubernetes存储容器

2021-04-29 18:18:51

Kubernetes容器工具

2017-09-21 08:16:33

数据存储环境

2022-08-22 07:58:14

容器云存储开发

2011-07-20 17:23:29

C++持久对象

2010-05-25 11:40:55

存储虚拟化服务器虚拟化

2021-12-15 12:00:17

Pythonpickle存储

2013-09-12 14:56:02

iOS持久化

2021-06-17 09:13:50

戴尔

2021-08-03 17:08:34

CASSDS

2021-08-20 11:00:04

Redis携程数据库

2020-07-20 07:00:00

KubernetesHostPath

2022-07-11 15:35:42

云计算银行本文主要从银行实际应

2018-11-21 10:36:29

Kubernetes存储Docker

2021-03-18 08:18:15

ZooKeeper数据持久化

2019-12-27 13:50:04

JavaAPI代码

2009-09-15 11:08:01

LinQ调用存储过程

2021-05-25 10:20:31

Python持久性编程语言

2009-06-01 13:26:37

持久化规范JPAJava
点赞
收藏

51CTO技术栈公众号