CN113342280A - 基于Kubernetes的存储配置方法、系统及电子设备 - Google Patents

Abstract

本发明提供了一种基于Kubernetes的存储配置方法、系统及电子设备，涉及服务器技术领域，该方法首先初始化容器集群以及存储服务器，其中存储服务器用于向容器集群提供至少一个物理存储卷；然后在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射；再将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件；容器集群加载应用程序的资源文件，并在存储服务器中确定与虚拟存储卷映射的物理存储卷后，将物理存储卷挂载到应用程序中。该方法将物理存储映射到虚拟存储卷中，同时应用程序通过虚拟存储卷实现了对物理存储卷的挂载，统一了应用程序的资源文件，进一步提升应用部署的自动化程度。

Description

基于Kubernetes的存储配置方法、系统及电子设备

技术领域

本发明涉及服务器技术领域，尤其是涉及一种基于Kubernetes的存储配置方法、系统及电子设备。

背景技术

在Kubernetes平台上部署应用程序时需要使用满足特定格式的资源文件，这些资源文件定义了应用程序的运行方式和表现形式。应用以容器的形式运行于Kubernetes集群中，Kubernetes负责在不同操作系统和不同硬件资源上编排调度容器，无需担心底层硬件或操作系统故障导致应用无法正常对外提供服务，保证了应用程序的高可靠性。不过，容器短暂的生命周期限制了应用持久化数据，对于需要数据持久化的应用如：MySQL、Redis、etcd、RabbitMQ等，需要在资源文件中声明后端存储的相关信息。

使用Kubernetes容器编排工具可以方便的在不同软件系统上迁移、重建，从而保证了应用业务的持续性、高可靠性。但是，在实际部署过程中用户需要根据后端存储类型频繁调整修改应用程序的资源文件，所以Kubernetes并不能真正满足应用程序部署与存储设施解耦的目标；而且应用程序必须知道全部的存储信息，如存储类型、存储服务器地址、存储卷的LUN序号等。

可见，现有的Kubernetes在部署应用程序过程中需要针对不同存储类型而手动修改应用程序的资源文件，自动化程度较低。

发明内容

有鉴于此，本发明的目的在于提供一种基于Kubernetes的存储配置方法、系统及电子设备，通过将物理存储映射到虚拟存储卷中，同时应用程序通过虚拟存储卷实现了对物理存储卷的挂载，从而在部署应用程序时不再因为存储类型的不同而修改相应的资源文件，减少了人工参与，进一步提升应用部署的自动化程度。

第一方面，本发明实施例提供了一种基于Kubernetes的存储配置方法，包括：

初始化容器集群以及存储服务器；其中，容器集群为Kubernetes集群；存储服务器用于向容器集群提供至少一个物理存储卷；

在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射；

将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件；

容器集群加载应用程序的资源文件，并在存储服务器中确定与虚拟存储卷映射的物理存储卷后，将物理存储卷挂载到应用程序中。

在一些实施方式中，初始化容器集群以及存储服务器的步骤，包括：

在存储服务器中创建至少一个物理存储卷；

在容器集群节点上发现并登录物理存储卷，并获取物理存储卷的名称以及存储路径。

在一些实施方式中，在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射的步骤，包括：

获取物理存储卷在系统目录下的绝对路径；

按照预设命名规则在系统目录下创建虚拟存储卷；

将物理存储卷的绝对路径与虚拟存储卷进行映射。

在一些实施方式中，将物理存储卷的绝对路径与虚拟存储卷进行映射的步骤，包括：

根据虚拟存储卷以及物理存储卷的绝对路径，建立第一映射关系；

根据物理存储卷的文件名以及物理存储卷的相对路径，建立第二映射关系；

根据第一映射关系和第二映射关系，建立物理存储卷与虚拟存储卷之间映射的软连接。

在一些实施方式中，将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件的步骤，包括：

获取虚拟存储卷的存储信息；其中，虚拟存储卷的存储信息至少包括：虚拟存储卷的名称、文件系统类型、逻辑单元序号和全局目标名称；

根据虚拟存储卷的名称、文件系统类型、逻辑单元序号和全局目标名称，确定容器集群的应用程序中对应的声明参数；

将声明参数配置于容器集群中应用程序的资源文件中。

在一些实施方式中，初始化容器集群以及存储服务器的步骤，还包括：

判断容器集群的系统目录是否存在；

如果否，执行目录创建脚本；其中，目录创建脚本用于创建系统目录。

在一些实施方式中，存储服务器，至少支持iSCSI、FC、nfs、Ceph RBD、Glusterfs、OpenStack Cinder上述一种或多种格式的存储服务器。

第二方面，本发明实施例提供了一种基于Kubernetes的存储配置系统，该系统包括：

初始化模块，用于初始化容器集群以及存储服务器；其中，容器集群为Kubernetes集群；存储服务器用于向容器集群提供至少一个物理存储卷；

虚拟存储卷生成模块，用于在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射；

存储卷配置模块，用于将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件；

存储卷挂载模块，用于容器集群加载应用程序的资源文件，并在存储服务器中确定与虚拟存储卷映射的物理存储卷后，将物理存储卷挂载到应用程序中。

第三方面，本发明实施例还提供一种电子设备，包括存储器、处理器，存储器中存储有可在处理器上运行的计算机程序，其中，处理器执行计算机程序时实现上述第一方面提到的基于Kubernetes的存储配置方法的步骤。

第四方面，本发明实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，其中，程序代码使处理器执行上述第一方面提到的基于Kubernetes的存储配置方法的步骤。

本发明实施例带来了至少以下有益效果：

本发明提供了一种基于Kubernetes的存储配置方法、系统及电子设备，首先初始化容器集群以及存储服务器；其中，容器集群为Kubernetes集群；存储服务器用于向容器集群提供至少一个物理存储卷；然后在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射；再将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件；容器集群加载应用程序的资源文件，并在存储服务器中确定与虚拟存储卷映射的物理存储卷后，将物理存储卷挂载到应用程序中。该方法将物理存储映射到虚拟存储卷中，同时应用程序通过虚拟存储卷实现了对物理存储卷的挂载，从而在部署应用程序时不再因为存储类型的不同而修改相应的资源文件，减少了人工参与，进一步提升应用部署的自动化程度。

本发明的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义的确定，或者通过实施本发明的上述技术即可得知。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施方式，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中基于Kubernetes的存储配置结构示意图；

图2为本发明实施例提供的一种基于Kubernetes的存储配置方法的流程图；

图3为采用基于Kubernetes的存储配置方法下的基于Kubernetes的存储配置结构示意图；

图4为本发明实施例提供的一种基于Kubernetes的存储配置方法下步骤S201的流程图；

图5为本发明实施例提供的一种基于Kubernetes的存储配置方法下步骤S202的流程图；

图6为本发明实施例提供的一种基于Kubernetes的存储配置方法下步骤S503的流程图；

图7为本发明实施例提供的一种基于Kubernetes的存储配置方法下步骤S203的流程图；

图8为本发明实施例提供的另一种基于Kubernetes的存储配置方法下步骤S201的流程图；

图9为本发明实施例提供一种基于Kubernetes的存储配置系统的结构示意图；

图10为本发明实施例提供的一种电子设备的结构示意图。

图标：

910-初始化模块；920-虚拟存储卷生成模块；930-存储卷配置模块；940-存储卷挂载模块；101-处理器；102-存储器；103-总线；104-通信接口。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在Kubernetes平台上部署应用程序时需要使用满足特定格式的资源文件，这些资源文件定义了应用程序的运行方式和表现形式。应用以容器的形式运行于Kubernetes集群中，Kubernetes负责在不同操作系统和不同硬件资源上编排调度容器，无需担心底层硬件或操作系统故障导致应用无法正常对外提供服务，保证了应用程序的高可靠性。不过，容器短暂的生命周期限制了应用持久化数据，对于需要数据持久化的应用如：MySQL、Redis、etcd、RabbitMQ等，需要在资源文件中声明后端存储的相关信息。

使用Kubernetes容器编排工具可以方便的在不同软件系统上迁移、重建，从而保证了应用业务的持续性、高可靠性。但是，在实际部署过程中用户需要根据后端存储类型频繁调整修改应用程序的资源文件，所以Kubernetes并不能真正满足应用程序部署与存储设施解耦的目标；而且应用程序必须知道全部的存储信息，如存储类型、存储服务器地址、存储卷的LUN序号等。

以iSCSI(Internet Small Computer System Interface，Internet小型计算机系统接口)和FC(Fibre Channel，光纤信道)类型的存储为例，分别对在Kubernetes集群中使用不同类型的存储后端创建应用程序的操作方法及原理进行分析：

一、使用iSCSI类型的后端存储。

1.在iSCSI存储服务器上创建存储卷。

2.在集群节点上执行命令：“iscsiadm–m discovery–t st–p<存储服务器IP地址:端口>-l”发现并登录共享存储，登录存储后/dev/disk/by-path目录如下：

#ll/dev/disk/by-path

lrwxrwxrwx 1 root root 9 Sep 10 19:14 ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:7567-lun-1->../../sdk。

3.在应用程序的资源文件中声明使用的后端存储为iSCSI，并配置上步发现的存储信息：存储服务器的IP地址、端口号、LUN序号。

volumes:

-name:iscsi

iscsi:

targetPortal:172.23.2.50:3260

portals:[‘172.23.2.50:3260’]

iqn:iqn.2016-02.com.smartx:system:7567

lun:1

fsType:ext4

readOnly:false

4.Kubernetes加载应用程序的资源文件中使用的存储类型、存储服务器IP地址、LUN序号等信息，在宿主机上查找需要的存储卷。

5.Kubernetes将找到的存储卷挂载到应用程序中，至此，应用程序挂载iSCSI类型的共享存储完成。

二、使用FC类型的后端存储。

1.在FC存储服务器上创建存储卷。

2.在集群节点上发现并登录FC共享存储，登录后/dev/disk/by-path目录如下：

#ll/dev/disk/by-path

lrwxrwxrwx 1 root root 9 Sep 10 19:14 pci-0000:01:00-fc-0x5009918394872c-lun-89->../../sdg。

3.在应用程序的资源文件中声明使用的后端存储为FC，并配置存储服务的targetWWNs、LUN序号等参数。

volumes:

-name:fc

fc:

fsType:ext4

lun:89

targetWWNs:[‘5009918394872c’]

readOnly:false

4.Kubernetes加载应用程序的资源文件中使用的存储类型、target、LUN序号等信息，在宿主机上查找需要的存储卷。

5.Kubernetes将找到的存储卷挂载到应用程序中，至此，应用程序挂载FC类型的存储完成。

上述过程可参见图1所示的现有技术中基于Kubernetes的存储配置结构示意图。将应用程序部署到容器中主要是因为容器化部署可以减少应用对硬件系统的依赖，使用kubernetes容器编排工具可以方便的在不同软件系统上迁移、重建从而保证了应用业务的持续性、高可靠性。但是，从上述Kubernetes集群中使用iSCSI和FC类型的存储后端创建应用程序的操作可知，用户需要根据后端存储类型频繁调整修改应用程序的资源文件，所以Kubernetes并不能真正满足应用程序部署与存储设施解耦的目标；而且应用程序必须知道全部的存储信息，如存储类型、存储服务器地址、存储卷的LUN序号等。

可见，现有的Kubernetes在部署应用程序过程中需要针对不同存储类型而手动修改应用程序的资源文件，自动化程度较低。

基于此，本发明实施例提供的一种基于Kubernetes的存储配置方法、系统及电子设备，通过将物理存储映射到虚拟存储卷中，同时应用程序通过虚拟存储卷实现了对物理存储卷的挂载，从而在部署应用程序时不再因为存储类型的不同而修改相应的资源文件，减少了人工参与，进一步提升应用部署的自动化程度。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种基于Kubernetes的存储配置方法进行详细介绍。

参见图2所示的一种基于Kubernetes的存储配置方法流程图，该方法包括：

步骤S201，初始化容器集群以及存储服务器；其中，容器集群为Kubernetes集群；存储服务器用于向容器集群提供至少一个物理存储卷。

初始化的容器集群为Kubernetes集群，该容器集群部署在宿主机中。在宿主机中还包括若干个存储卷，这些存储卷通过不同格式的存储服务器所提供。

步骤S202，在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射。

Kubernetes集群上的应用程序挂载存储时，会根据不同的存储类型和存储路径在宿主机中的系统目录下进行查找，因此可通过在该系统目录下创建虚拟存储卷以实现与物理存储卷相映射的软连接的方式，来实现应用程序与后端存储的解耦过程。

具体可参照图3所示的采用本方法下的基于Kubernetes的存储配置结构示意图，图3中可知，在宿主机物理存储卷与Kubernetes之间建立虚拟存储卷，虚拟存储卷的一端与Kubernetes之间进行关联，同时虚拟存储卷的另一端与宿主机的存储卷相关联。

步骤S203，将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件。

配置过程中，将应用程序的资源文件中配置固定的存储类型和存储路径；并在其宿主机的系统目录下，创建与上固定的存储类型和存储路径实际挂载的存储设备对应的符号标志建立映射的软连接。

具体的说，该步骤是作用与应用程序一端，在应用程序的资源文件中声明虚拟存储卷；由于虚拟存储卷中与物理存储卷已建立映射关系，因此后续在被Kubernetes加载后可通过虚拟存储卷直接指向物理存储卷。

步骤S204，容器集群加载应用程序的资源文件，并在存储服务器中确定与虚拟存储卷映射的物理存储卷后，将物理存储卷挂载到应用程序中。

Kubernetes为应用程序挂载虚拟存储卷时，只需要在系统目录下查找虚拟存储卷即可，并不用关心该虚拟存储卷指向的物理存储卷或者是其它存储卷。上述过程只需要在宿主机节点创建指向所需的物理存储卷的软连接即可，对于运行在容器中的应用程序资源文件配置的存储资源都是固定的软连接，屏蔽了实际物理存储的硬件类的各种数据。

图1中的现有技术中基于Kubernetes的存储配置过程中，应用程序资源文件包含多个，实际在部署多个应用程序时需要根据其对应的存储类型而修改各自的资源文件；图3采用本方法下的基于Kubernetes的存储配置过程可直接将多个应用程序的资源文件中声明固定的虚拟磁盘卷，从而可使用相同的应用程序资源文件，解决了现有的Kubernetes在部署应用程序过程中需要针对不同存储类型而手动修改应用程序的资源文件导致的自动化程度较低的问题。

通过上述实施例中提供的基于Kubernetes的存储配置方法可知，该方法通过将物理存储映射到虚拟存储卷中，同时应用程序通过虚拟存储卷实现了对物理存储卷的挂载，从而在部署应用程序时不再因为存储类型的不同而修改相应的资源文件，减少了人工参与，进一步提升应用部署的自动化程度。

在一些实施方式中，初始化容器集群以及存储服务器的步骤S201，如图4所示，包括：

步骤S401，在存储服务器中创建至少一个物理存储卷。

步骤S402，在容器集群节点上发现并登录物理存储卷，并获取物理存储卷的名称以及存储路径。

以iSCSI类型的后端存储为例，步骤S401实现了在iSCSI存储服务器和FC存储服务器上创建物理存储卷；然后步骤S402中在集群节点上执行命令：iscsiadm-m discovery-tst-p<存储服务器IP地址>-l，发现并登录共享存储卷。并在系统目录/dev/disk/by-path下显示已登录的存储卷。具体如下：

#ll/dev/disk/by-path

lrwxrwxrwx 1 root root 9 Sep 10 19:14 ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1->../../sdk

通过执行ll/dev/disk/by-path指令后，可直接获得该物理存储卷的名称：ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1以及存储路径：../../sdk。

以FC类型的后端存储为例，步骤S401实现了在FC存储服务器上创建物理存储卷，然后步骤S402中在集群节点上发现并登录FC共享存储，并在/dev/disk/by-path目录下显示FC存储卷。具体如下：

#ll/dev/disk/by-path

lrwxrwxrwx 1 root root 9 Sep 10 19:14 pci-0000:01:00-fc-0x5009918394872c-lun-89->../../sdg

通过执行ll/dev/disk/by-path指令后，可直接获得该物理存储卷的名称：pci-0000:01:00-fc-0x5009918394872c-lun-89以及存储路径：../../sdg。

在一些实施方式中，在容器集群的系统目录下创建虚拟存储卷，并将虚拟存储卷与物理存储卷进行映射的步骤S202，如图5所示，包括：

步骤S501，获取物理存储卷在系统目录下的绝对路径。

以上述使用iSCSI类型的后端存储时，该物理存储卷的绝对路径为系统目录+文件名称，即：/dev/disk/by-path/ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1；

使用FC类型的后端存储时，该物理存储卷在系统目录下的绝对路径为：/dev/disk/by-path/pci-0000:01:00-fc-0x5009918394872c-lun-89。

步骤S502，按照预设命名规则在系统目录下创建虚拟存储卷。

预设命名规则中，可包含该虚拟存储卷的相关属性值，也可包含特定含义的数字及字母组合；不同属性值及字母之间可使用相关连接符进行连接。一般情况下，在该命名规则中不能包含如空格、引号、连接号等特定符号。例如，该虚拟存储卷的名称为icenter-fc-0xetcd-lun-0。

步骤S503，将物理存储卷的绝对路径与虚拟存储卷进行映射。

再获得虚拟存储卷的名称后，将其与物理存储卷的绝对路径进行关联，建立映射关系，可通过使用软连接的方式实现虚拟存储卷与物理存储卷的关联。

在一些实施方式中，将物理存储卷的绝对路径与虚拟存储卷进行映射的步骤S503，如图6所示，包括：

步骤S601，根据虚拟存储卷以及物理存储卷的绝对路径，建立第一映射关系。

第一映射关系表征了虚拟存储卷与物理存储卷的绝对路径之间的映射，即物理存储卷的绝对路径为包含系统目录的完整路径，例如：

使用iSCSI类型的后端存储时，第一映射关系为icenter-fc-0xetcd-lun-0与/dev/disk/by-path/ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1之间的映射；

使用FC类型的后端存储时，第一映射关系为icenter-fc-0xetcd-lun-0与/dev/disk/by-path/pci-0000:01:00-fc-0x5009918394872c-lun-89之间的映射。

步骤S602，根据物理存储卷的文件名以及物理存储卷的相对路径，建立第二映射关系。

第一映射关系表征了物理存储卷与物理存储卷的相对存储路径之间的映射，可理解为预设的映射，具体的说：

使用iSCSI类型的后端存储时，第二映射关系为ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1与../../sdk之间的映射；

使用FC类型的后端存储时，第二映射关系为pci-0000:01:00-fc-0x5009918394872c-lun-89与../../sdg之间的映射。

步骤S603，根据第一映射关系和第二映射关系，建立物理存储卷与虚拟存储卷之间映射的软连接。

具体的说，在系统目录下创建固定名字为icenter-fc-0xetcd-lun-0的软连接作为虚拟存储卷，软连接指向的真实地址为已经登录的物理存储卷。建立映射后，执行#ll/dev/disk/by-path指令，得到的结果如下：

使用iSCSI类型的后端存储时，得到的结果为：

lrwxrwxrwx 1 root root 86 Sep 10 19:12 icenter-fc-0xetcd-lun-0->/dev/disk/by-path/ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1

lrwxrwxrwx 1 root root 9 Sep 10 19:14 ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1->../../sdk

使用FC类型的后端存储时，得到的结果为：

lrwxrwxrwx 1 root root 86 Sep 10 19:12 icenter-fc-0xetcd-lun-0->/dev/disk/by-path/pci-0000:01:00-fc-0x5009918394872c-lun-89

lrwxrwxrwx 1 root root 9 Sep 10 19:14 pci-0000:01:00-fc-0x5009918394872c-lun-89->../../sdg

可见，无论是使用iSCSI类型的后端存储还是使用FC类型的后端存储，均可使用名为icenter-fc-0xetcd-lun-0的虚拟存储卷，通过而不用关系该虚拟存储卷具体指向的物理存储卷。具体的说，Kubernetes为应用程序挂载共享存储时在/dev/disk/by-path目录下查找名为“icenter-fc-0xetcd-lun-0”的虚拟磁盘，而不关心该虚拟磁盘指向的真实后端存储是“/dev/disk/by-path/ip-172.23.2.50:3260-iscsi-iqn.2016-02.com.smartx:system:919293-lun-1”还是“/dev/disk/by-path/pci-0000:01:00-fc-0x5009918394872c-lun-89”亦或是服务器上某个目录如/opt。

在一些实施方式中，将已完成映射的虚拟存储卷的存储信息配置于容器集群中应用程序的资源文件的步骤S203，如图7所示，包括：

步骤S701，获取虚拟存储卷的存储信息；其中，虚拟存储卷的存储信息至少包括：虚拟存储卷的名称、文件系统类型、逻辑单元序号和全局目标名称。

具体的说，在应用程序的资源文件中声明并配置存储服务的相关存储信息，例如虚拟存储卷的名称(name)、文件系统类型(file system type)、逻辑单元序号(lun)和全局目标名称(targetWWNs)。

步骤S702，根据虚拟存储卷的名称、文件系统类型、逻辑单元序号和全局目标名称，确定容器集群的应用程序中对应的声明参数。

无论是iSCSI类型的后端存储还是FC类型的后端存储，应用程序的资源文件中配置参数均相同。例如，资源文件的格式如下：

volumes:

-name:etcd

fc:

fsType:ext4(file system type)

lun:0

targetWWNs:[‘etcd’]

步骤S703，将声明参数配置于容器集群中应用程序的资源文件中。

声明参数配置完成后，Kubernetes加载应用程序的资源文件中声明的虚拟后端存储，在宿主机上查找虚拟存储卷所指向的物理存储卷，然后Kubernetes将找到的存储卷挂载到应用程序中。

由于虽然系统目录如/dev/disk/by-path比较稳定，不容易出现目录缺失的情况，但在Kubernetes宿主机重启或者出现崩溃的情况时并不能保证系统目录一定存在，因此需要判断系统目录的完整性。因此在一些实施方式中，初始化容器集群以及存储服务器的步骤S201，如图8所示，还包括：

步骤S801，判断容器集群的系统目录是否存在。

该步骤可通过相关目录监控函数来对系统目录的状态进行实时监控，这些目录监控函数可实现对系统目录的修改、删除、目录下的文件增减情况进行实时获取。

步骤S802，如果否，执行目录创建脚本；其中，目录创建脚本用于创建系统目录。

该目录创建脚本也可在宿主机开机后启动，保证宿主机每次启动后完成系统目录的创建。

在一些实施方式中，存储服务器，至少支持iSCSI、FC、nfs(Network File System，网络文件系统)、Ceph RBD(Ceph RADOS Block Devices，Ceph分布式文件系统的块设备形态)、Glusterfs(Glusterfs分布式文件系统)、OpenStack Cinder(OpenStac云计算管理平台的Cinder存储)上述一种或多种格式的存储服务器。

通过上述实施例中提供的基于Kubernetes的存储配置方法可知，该方法通过将物理存储映射到虚拟存储卷中，同时应用程序通过虚拟存储卷实现了对物理存储卷的挂载。即，将真实存储映射到虚拟磁盘卷，应用程序使用固定的虚拟磁盘卷。从而在部署应用程序时不再因为存储类型的不同而修改相应的资源文件，进一步提升应用部署的自动化程度；而且对于给定的应用资源文件，该方法通过使用Linux的软链接模拟虚拟磁盘卷将应用程序和基础设施解耦，从而可以通过一套部署脚本满足Kubernetes对多种存储后端的支持，减少了应用资源文件的配置复杂度，降低运维成本。

对应于上述方法实施例，本发明实施例提供了一种基于Kubernetes的存储配置系统，如图9所示，该系统包括：

初始化模块910，用于初始化容器集群以及存储服务器；其中，所述容器集群为Kubernetes集群；所述存储服务器用于向所述容器集群提供至少一个物理存储卷；

虚拟存储卷生成模块920，用于在所述容器集群的系统目录下创建虚拟存储卷，并将所述虚拟存储卷与所述物理存储卷进行映射；

存储卷配置模块930，用于将已完成映射的所述虚拟存储卷的存储信息配置于所述容器集群中应用程序的资源文件；

存储卷挂载模块940，用于所述容器集群加载所述应用程序的资源文件，并在所述存储服务器中确定与所述虚拟存储卷映射的所述物理存储卷后，将所述物理存储卷挂载到所述应用程序中。

本发明实施例提供的基于Kubernetes的存储配置系统，与上述实施例提供的基于Kubernetes的存储配置方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。为简要描述，实施例部分未提及之处，可参考前述基于Kubernetes的存储配置方法实施例中相应内容。

本实施例还提供一种电子设备，为该电子设备的结构示意图如图10所示，该设备包括处理器101和存储器102；其中，存储器102用于存储一条或多条计算机指令，一条或多条计算机指令被处理器执行，以实现上述基于Kubernetes的存储配置方法。

图10所示的电子设备还包括总线103和通信接口104，处理器101、通信接口104和存储器102通过总线103连接。

其中，存储器102可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。总线103可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

通信接口104用于通过网络接口与至少一个用户终端及其它网络单元连接，将封装好的IPv4报文或IPv4报文通过网络接口发送至用户终端。

处理器101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器101中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器101可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processor，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本公开实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本公开实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器102，处理器101读取存储器102中的信息，结合其硬件完成前述实施例的方法的步骤。

本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行前述实施例的方法的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、设备和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，设备或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以用软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种基于Kubernetes的存储配置方法，其特征在于，所述方法包括：

初始化容器集群以及存储服务器；其中，所述容器集群为Kubernetes集群；所述存储服务器用于向所述容器集群提供至少一个物理存储卷；

在所述容器集群的系统目录下创建虚拟存储卷，并将所述虚拟存储卷与所述物理存储卷进行映射；

将已完成映射的所述虚拟存储卷的存储信息配置于所述容器集群中应用程序的资源文件；

所述容器集群加载所述应用程序的资源文件，并在所述存储服务器中确定与所述虚拟存储卷映射的所述物理存储卷后，将所述物理存储卷挂载到所述应用程序中。

2.根据权利要求1所述的基于Kubernetes的存储配置方法，其特征在于，初始化容器集群以及存储服务器的步骤，包括：

在所述存储服务器中创建至少一个物理存储卷；

在所述容器集群节点上发现并登录所述物理存储卷，并获取所述物理存储卷的名称以及存储路径。

3.根据权利要求1所述的基于Kubernetes的存储配置方法，其特征在于，在所述容器集群的系统目录下创建虚拟存储卷，并将所述虚拟存储卷与所述物理存储卷进行映射的步骤，包括：

获取所述物理存储卷在所述系统目录下的绝对路径；

按照预设命名规则在所述系统目录下创建所述虚拟存储卷；

将所述物理存储卷的绝对路径与所述虚拟存储卷进行映射。

4.根据权利要求3所述的基于Kubernetes的存储配置方法，其特征在于，将所述物理存储卷的绝对路径与所述虚拟存储卷进行映射的步骤，包括：

根据所述虚拟存储卷以及所述物理存储卷的绝对路径，建立第一映射关系；

根据所述物理存储卷的文件名以及所述物理存储卷的相对路径，建立第二映射关系；

根据所述第一映射关系和所述第二映射关系，建立所述物理存储卷与所述虚拟存储卷之间映射的软连接。

5.根据权利要求1所述的基于Kubernetes的存储配置方法，其特征在于，将已完成映射的所述虚拟存储卷的存储信息配置于所述容器集群中应用程序的资源文件的步骤，包括：

获取所述虚拟存储卷的存储信息；其中，所述虚拟存储卷的存储信息至少包括：所述虚拟存储卷的名称、文件系统类型、逻辑单元序号和全局目标名称；

根据所述虚拟存储卷的名称、所述文件系统类型、所述逻辑单元序号和所述全局目标名称，确定所述容器集群的应用程序中对应的声明参数；

将所述声明参数配置于所述容器集群中应用程序的资源文件中。

6.根据权利要求1所述的基于Kubernetes的存储配置方法，其特征在于，初始化容器集群以及存储服务器的步骤，还包括：

判断所述容器集群的系统目录是否存在；

如果否，执行目录创建脚本；其中，所述目录创建脚本用于创建所述系统目录。

7.根据权利要求1所述的基于Kubernetes的存储配置方法，其特征在于，所述存储服务器，至少支持iSCSI、FC、nfs、Ceph RBD、Glusterfs、OpenStack Cinder上述一种或多种格式的存储服务器。

8.一种基于Kubernetes的存储配置系统，其特征在于，所述系统包括：

初始化模块，用于初始化容器集群以及存储服务器；其中，所述容器集群为Kubernetes集群；所述存储服务器用于向所述容器集群提供至少一个物理存储卷；

虚拟存储卷生成模块，用于在所述容器集群的系统目录下创建虚拟存储卷，并将所述虚拟存储卷与所述物理存储卷进行映射；

存储卷配置模块，用于将已完成映射的所述虚拟存储卷的存储信息配置于所述容器集群中应用程序的资源文件；

存储卷挂载模块，用于所述容器集群加载所述应用程序的资源文件，并在所述存储服务器中确定与所述虚拟存储卷映射的所述物理存储卷后，将所述物理存储卷挂载到所述应用程序中。

9.一种电子设备，其特征在于，包括：处理器和存储装置；所述存储装置上存储有计算机程序，所述计算机程序在被所述处理器运行时实现如权利要求1至7任一项所述的基于Kubernetes的存储配置方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器运行时实现上述权利要求1至7任一项所述的基于Kubernetes的存储配置方法的步骤。

Images