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

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

Info

Publication number
WO2022267428A1
WO2022267428A1 PCT/CN2021/143180 CN2021143180W WO2022267428A1 WO 2022267428 A1 WO2022267428 A1 WO 2022267428A1 CN 2021143180 W CN2021143180 W CN 2021143180W WO 2022267428 A1 WO2022267428 A1 WO 2022267428A1
Authority
WO
WIPO (PCT)
Prior art keywords
storage volume
storage
container cluster
kubernetes
virtual
Prior art date
Application number
PCT/CN2021/143180
Other languages
English (en)
French (fr)
Inventor
黄学军
何继文
潘宗辉
金博玉
孟亮
刘蜀东
朱玥
刘辉军
俞坚华
董全
邱桂苹
雷涛
Original Assignee
航天云网科技发展有限责任公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 航天云网科技发展有限责任公司 filed Critical 航天云网科技发展有限责任公司
Publication of WO2022267428A1 publication Critical patent/WO2022267428A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects

Definitions

  • the present application relates to the technical field of servers, in particular to a storage configuration method, system and electronic equipment based on Kubernetes.
  • resource files that meet a specific format need to be used. These resource files define the running mode and appearance of the application.
  • Applications run in the form of containers in the Kubernetes cluster.
  • Kubernetes is responsible for arranging and scheduling containers on different operating systems and different hardware resources. There is no need to worry about the failure of the underlying hardware or operating system to cause the application to fail to provide services to the outside world, ensuring high reliability of the application. .
  • the short life cycle of the container limits the persistent data of the application. For applications that require data persistence, such as MySQL, Redis, etcd, RabbitMQ, etc., it is necessary to declare the relevant information of the back-end storage in the resource file.
  • Using the Kubernetes container orchestration tool can easily migrate and rebuild on different software systems, thus ensuring the continuity and high reliability of the application business.
  • users need to frequently adjust and modify the resource files of the application according to the back-end storage type, so Kubernetes cannot really meet the goal of decoupling application deployment and storage facilities; and the application must know all storage information, Such as storage type, storage server address, storage volume LUN serial number, etc.
  • the purpose of this application is to provide a Kubernetes-based storage configuration method, system and electronic equipment, by mapping physical storage to virtual storage volumes, and at the same time, the application program realizes the attachment of physical storage volumes through virtual storage volumes. Loading, so that when deploying applications, it is no longer necessary to modify the corresponding resource files due to different storage types, reducing manual participation and further improving the automation of application deployment.
  • the embodiment of the present application provides a storage configuration method based on Kubernetes, including:
  • the container cluster is a Kubernetes cluster
  • the storage server is used to provide at least one physical storage volume to the container cluster
  • the container cluster loads the resource files of the application, and after determining the physical storage volume mapped to the virtual storage volume in the storage server, mounts the physical storage volume to the application.
  • the steps of initializing the container cluster and the storage server include:
  • the step of creating a virtual storage volume under the system directory of the container cluster and mapping the virtual storage volume with the physical storage volume includes:
  • the step of mapping the absolute path of the physical storage volume with the virtual storage volume includes:
  • a soft connection for mapping between the physical storage volume and the virtual storage volume is established.
  • the step of configuring the storage information of the mapped virtual storage volume in the resource file of the application program in the container cluster includes:
  • the storage information of the virtual storage volume at least includes: the name of the virtual storage volume, the file system type, the logical unit serial number and the global target name;
  • the steps of initializing the container cluster and the storage server further include:
  • the storage server at least supports storage servers in one or more formats of iSCSI, FC, nfs, Ceph RBD, Glusterfs, and OpenStack Cinder.
  • the embodiment of the present application provides a storage configuration system based on Kubernetes, the system includes:
  • the initialization module is used to initialize the container cluster and the storage server; wherein, the container cluster is a Kubernetes cluster; the storage server is used to provide at least one physical storage volume to the container cluster;
  • the virtual storage volume generation module is used to create a virtual storage volume under the system directory of the container cluster, and map the virtual storage volume with the physical storage volume;
  • the storage volume configuration module is used to configure the storage information of the mapped virtual storage volume in the resource file of the application program in the container cluster;
  • the storage volume mounting module is used for the container cluster to load the resource files of the application, and after determining the physical storage volume mapped to the virtual storage volume in the storage server, mount the physical storage volume to the application.
  • the embodiment of the present application also provides an electronic device, including a memory and a processor, and a computer program that can run on the processor is stored in the memory, wherein when the processor executes the computer program, the computer program mentioned in the first aspect mentioned above is realized. Steps of the Kubernetes-based storage provisioning method.
  • the embodiment of the present application also provides a computer-readable medium having a non-volatile program code executable by a processor, wherein the program code causes the processor to execute the Kubernetes-based storage configuration mentioned in the first aspect above method steps.
  • the application provides a Kubernetes-based storage configuration method, system, and electronic device, firstly initializing a container cluster and a storage server; wherein, the container cluster is a Kubernetes cluster; the storage server is used to provide at least one physical storage volume to the container cluster; and then Create a virtual storage volume in the system directory of the container cluster, and map the virtual storage volume with the physical storage volume; then configure the storage information of the mapped virtual storage volume in the resource file of the application in the container cluster; the container cluster loads the application After the resource file of the program is determined in the storage server and the physical storage volume mapped to the virtual storage volume is determined, the physical storage volume is mounted to the application program.
  • This method maps the physical storage to the virtual storage volume, and at the same time, the application program realizes the mounting of the physical storage volume through the virtual storage volume, so that the corresponding resource files are no longer modified due to the different storage types when deploying the application program, reducing Human participation is eliminated, and the automation of application deployment is further improved.
  • FIG. 1 is a schematic diagram of a storage configuration structure based on Kubernetes in the prior art
  • Fig. 2 is a flow chart of a Kubernetes-based storage configuration method provided by an embodiment of the present application
  • Fig. 3 is a schematic diagram of a storage configuration structure based on Kubernetes under a storage configuration method based on Kubernetes;
  • FIG. 4 is a flow chart of step S201 of a Kubernetes-based storage configuration method provided by an embodiment of the present application
  • FIG. 5 is a flow chart of step S202 of a Kubernetes-based storage configuration method provided by an embodiment of the present application
  • FIG. 6 is a flow chart of step S503 of a Kubernetes-based storage configuration method provided by an embodiment of the present application.
  • FIG. 7 is a flow chart of step S203 of a Kubernetes-based storage configuration method provided in an embodiment of the present application.
  • FIG. 8 is a flow chart of step S201 in another Kubernetes-based storage configuration method provided by the embodiment of the present application.
  • FIG. 9 is a schematic structural diagram of a Kubernetes-based storage configuration system provided by an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of an electronic device provided by an embodiment of the present application.
  • 910-initialization module 920-virtual storage volume generation module; 930-storage volume configuration module; 940-storage volume mounting module; 101-processor; 102-memory; 103-bus; 104-communication interface.
  • resource files that meet a specific format need to be used. These resource files define the running mode and appearance of the application.
  • Applications run in the form of containers in the Kubernetes cluster.
  • Kubernetes is responsible for arranging and scheduling containers on different operating systems and different hardware resources. There is no need to worry about the failure of the underlying hardware or operating system to cause the application to fail to provide services to the outside world, ensuring high reliability of the application. .
  • the short life cycle of the container limits the persistent data of the application. For applications that require data persistence, such as MySQL, Redis, etcd, RabbitMQ, etc., it is necessary to declare the relevant information of the back-end storage in the resource file.
  • Using the Kubernetes container orchestration tool can easily migrate and rebuild on different software systems, thus ensuring the continuity and high reliability of the application business.
  • users need to frequently adjust and modify the resource files of the application according to the back-end storage type, so Kubernetes cannot really meet the goal of decoupling application deployment and storage facilities; and the application must know all storage information, Such as storage type, storage server address, storage volume LUN serial number, etc.
  • Kubernetes loads information such as the storage type used in the resource file of the application, the IP address of the storage server, and the LUN serial number, and searches for the required storage volume on the host.
  • FIG. 1 For the above process, please refer to the schematic diagram of storage configuration structure based on Kubernetes in the prior art shown in FIG. 1 .
  • Deploying applications to containers is mainly because containerized deployment can reduce the application's dependence on hardware systems.
  • Using kubernetes container orchestration tools can facilitate migration and reconstruction on different software systems, thereby ensuring the continuity and high reliability of application services .
  • users need to frequently adjust and modify application resource files according to the backend storage type, so Kubernetes cannot really satisfy application deployment and storage requirements.
  • the goal of facility decoupling; and the application must know all storage information, such as storage type, storage server address, LUN serial number of storage volume, etc.
  • a Kubernetes-based storage configuration method, system, and electronic device provided by the embodiments of the present application map physical storage to virtual storage volumes, and at the same time, the application program realizes the mounting of physical storage volumes through virtual storage volumes , so that when deploying applications, it is no longer necessary to modify the corresponding resource files due to different storage types, reducing manual participation, and further improving the automation of application deployment.
  • the method includes:
  • Step S201 initialize a container cluster and a storage server; wherein, the container cluster is a Kubernetes cluster; and the storage server is used to provide at least one physical storage volume to the container cluster.
  • the initialized container cluster is a Kubernetes cluster, which is deployed on the host machine.
  • the host computer also includes several storage volumes, which are provided by storage servers of different formats.
  • Step S202 creating a virtual storage volume under the system directory of the container cluster, and mapping the virtual storage volume with the physical storage volume.
  • FIG. 3 refers to the schematic diagram of the storage configuration structure based on Kubernetes under this method shown in Figure 3.
  • a virtual storage volume is established between the physical storage volume of the host machine and Kubernetes, and between one end of the virtual storage volume and Kubernetes Associate, and at the same time the other end of the virtual storage volume is associated with the storage volume of the host machine.
  • Step S203 configuring the storage information of the mapped virtual storage volume in the resource file of the application program in the container cluster.
  • this step acts on the application side, declaring the virtual storage volume in the resource file of the application; since the mapping relationship between the virtual storage volume and the physical storage volume has been established, it can be subsequently loaded by Kubernetes through the virtual storage volume. Volumes point directly to physical storage volumes.
  • Step S204 the container cluster loads the resource file of the application program, and after determining the physical storage volume mapped to the virtual storage volume in the storage server, mounts the physical storage volume to the application program.
  • the method maps physical storage to virtual storage volumes, and at the same time, the application program mounts the physical storage volumes through the virtual storage volumes, so that when deploying applications It is no longer necessary to modify the corresponding resource files due to different storage types, which reduces manual participation and further improves the automation of application deployment.
  • the step S201 of initializing the container cluster and the storage server, as shown in FIG. 4 includes:
  • Step S401 creating at least one physical storage volume in a storage server.
  • Step S402 discover and log in the physical storage volume on the container cluster node, and obtain the name and storage path of the physical storage volume.
  • step S401 implements the creation of physical storage volumes on the iSCSI storage server and FC storage server; then execute the command on the cluster nodes in step S402: iscsiadm-m discovery-t st-p ⁇ storage Server IP address>-l, discover and log in to the shared storage volume. And the registered storage volume is displayed under the system directory /dev/disk/by-path. details as follows:
  • step S401 implements the creation of physical storage volumes on the FC storage server, and then discovers and logs in to the FC shared storage on the cluster nodes in step S402, and stores the volume in the /dev/disk/by-path directory
  • FC storage volume is displayed below. details as follows:
  • the step S202 of creating a virtual storage volume under the system directory of the container cluster and mapping the virtual storage volume with the physical storage volume, as shown in FIG. 5 includes:
  • Step S501 obtaining the absolute path of the physical storage volume under the system directory.
  • the absolute path of the physical storage volume is the system directory + file name, namely: /dev/disk/by-path/ip-172.23.2.50:3260-iscsi-iqn.2016-
  • the absolute path of the physical storage volume in the system directory is: /dev/disk/by-path/pci-0000:01:00-fc-0x5009918394872c-lun-89.
  • Step S502 creating a virtual storage volume under the system directory according to a preset naming rule.
  • the default naming rules may include relevant attribute values of the virtual storage volume, and may also include combinations of numbers and letters with specific meanings; different attribute values and letters may be connected using relevant connectors. In general, specific symbols such as spaces, quotation marks, hyphens, etc. cannot be included in this naming rule.
  • the name of the virtual storage volume is icenter-fc-0xetcd-lun-0.
  • Step S503 mapping the absolute path of the physical storage volume with the virtual storage volume.
  • the step S503 of mapping the absolute path of the physical storage volume to the virtual storage volume includes:
  • step S601 a first mapping relationship is established according to the absolute paths of the virtual storage volume and the physical storage volume.
  • the first mapping relationship represents the mapping between the absolute path of the virtual storage volume and the physical storage volume, that is, the absolute path of the physical storage volume is the complete path including the system directory, for example:
  • the first mapping relationship is icenter-fc-0xetcd-lun-0 and /dev/disk/by-path/ip-172.23.2.50:3260-iscsi-iqn.2016-02.com .smartx:system
  • the first mapping relationship is between icenter-fc-0xetcd-lun-0 and /dev/disk/by-path/pci-0000:01:00-fc-0x5009918394872c-lun-89 mapping.
  • Step S602 establishing a second mapping relationship according to the file name of the physical storage volume and the relative path of the physical storage volume.
  • the first mapping relationship represents the mapping between the physical storage volume and the relative storage path of the physical storage volume, which can be understood as a preset mapping, specifically:
  • the second mapping relationship is ip-172.23.2.50:3260
  • the second mapping relationship is pci-0000:01:00-fc-0x500
  • Step S603 according to the first mapping relationship and the second mapping relationship, establish a soft connection mapped between the physical storage volume and the virtual storage volume.
  • the step S203 of configuring the storage information of the mapped virtual storage volume in the resource file of the application program in the container cluster includes:
  • step S701 the storage information of the virtual storage volume is obtained; wherein, the storage information of the virtual storage volume includes at least: a name of the virtual storage volume, a file system type, a logical unit serial number and a global target name.
  • the relevant storage information of the storage service in the resource file of the application such as the name of the virtual storage volume (name), the file system type (file system type), the logical unit serial number (lun) and the global target name (targetWWNs).
  • Step S702 according to the name of the virtual storage volume, the type of the file system, the serial number of the logical unit and the name of the global target, determine the corresponding declaration parameters in the application program of the container cluster.
  • a resource file has the following format:
  • Step S703 configuring the declaration parameters in the resource files of the application programs in the container cluster.
  • Kubernetes loads the virtual backend storage declared in the resource file of the application, finds the physical storage volume pointed to by the virtual storage volume on the host, and then Kubernetes mounts the found storage volume to the application.
  • the step S201 of initializing the container cluster and the storage server further includes:
  • Step S801 judging whether the system directory of the container cluster exists.
  • the state of the system directory can be monitored in real time through relevant directory monitoring functions.
  • These directory monitoring functions can realize real-time acquisition of the modification, deletion, and increase or decrease of files in the system directory.
  • Step S802 if not, execute a directory creation script; wherein, the directory creation script is used to create a system directory.
  • the directory creation script can also be started after the host computer is powered on, so as to ensure that the creation of the system directory is completed after each startup of the host computer.
  • the storage server at least supports iSCSI, FC, nfs (Network File System, network file system), Ceph RBD (Ceph RADOS Block Devices, block device form of Ceph distributed file system), Glusterfs (Glusterfs distributed file system), OpenStack Cinder (Cinder storage of the OpenStac cloud computing management platform) a storage server in one or more of the above formats.
  • the method maps physical storage to virtual storage volumes, and at the same time, the application implements the mounting of the physical storage volumes through the virtual storage volumes. That is, real storage is mapped to virtual disk volumes, and applications use fixed virtual disk volumes. Therefore, when deploying an application program, it is no longer necessary to modify the corresponding resource file due to different storage types, further improving the automation of application deployment; Applications and infrastructure are decoupled, so that Kubernetes can support multiple storage backends through a set of deployment scripts, reducing the configuration complexity of application resource files and reducing operation and maintenance costs.
  • the embodiment of the present application provides a Kubernetes-based storage configuration system, as shown in FIG. 9 , the system includes:
  • An initialization module 910 configured to initialize a container cluster and a storage server; wherein, the container cluster is a Kubernetes cluster; the storage server is configured to provide at least one physical storage volume to the container cluster;
  • a virtual storage volume generation module 920 configured to create a virtual storage volume under the system directory of the container cluster, and map the virtual storage volume with the physical storage volume;
  • a storage volume configuration module 930 configured to configure the storage information of the mapped virtual storage volume in the resource file of the application program in the container cluster;
  • the storage volume mounting module 940 is used for the container cluster to load the resource file of the application program, and after the physical storage volume mapped to the virtual storage volume is determined in the storage server, the physical storage volume The volume is mounted into said application.
  • the Kubernetes-based storage configuration system provided in the embodiment of the present application has the same technical features as the Kubernetes-based storage configuration method provided in the above embodiments, so it can also solve the same technical problem and achieve the same technical effect.
  • This embodiment also provides an electronic device, as shown in FIG. A computer instruction is executed by the processor to implement the above Kubernetes-based storage configuration method.
  • the electronic device shown in FIG. 10 further includes a bus 103 and a communication interface 104 , and the processor 101 , the communication interface 104 and the memory 102 are connected through the bus 103 .
  • the memory 102 may include a high-speed random access memory (RAM, Random Access Memory), and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
  • the bus 103 may be an ISA bus, a PCI bus, or an EISA bus, etc.
  • the bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one double-headed arrow is used in FIG. 10 , but it does not mean that there is only one bus or one type of bus.
  • the communication interface 104 is used to connect with at least one user terminal and other network elements through the network interface, and send the encapsulated IPv4 message or the IPv4 message to the user terminal through the network interface.
  • the processor 101 may be an integrated circuit chip with signal processing capability.
  • each step of the above method can be completed by an integrated logic circuit of hardware in the processor 101 or instructions in the form of software.
  • processor 101 can be general-purpose processor, comprises central processing unit (Central Processing Unit, be called for short CPU), network processor (Network Processor, be called for short NP) etc.; Can also be Digital Signal Processor (Digital Signal Processor, be called for short DSP) ), Application Specific Integrated Circuit (ASIC for short), Field Programmable Gate Array (Field-Programmable Gate Array, FPGA for short) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.
  • CPU central processing unit
  • Network Processor Network Processor
  • NP Network Processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • a general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.
  • the steps of the methods disclosed in the embodiments of the present disclosure may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register.
  • the storage medium is located in the memory 102, and the processor 101 reads the information in the memory 102, and completes the steps of the methods of the foregoing embodiments in combination with its hardware.
  • the embodiment of the present application also provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the methods in the foregoing embodiments are executed.
  • the disclosed systems, devices and methods may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division.
  • multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.
  • the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium executable by a processor.
  • the essence of the technical solution of this application or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc., which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

基于Kubernetes的存储配置方法、系统及电子设备
相关申请的交叉引用
本申请要求于2021年06月25日提交中国国家知识产权局的申请号为202110715790.1、名称为“基于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 1root root 9 Sep 10 19:14 ip-172.23.2.50:3260-iscsi-iqn.201
6-02.com.smartx:system:7567-lun-1->../../sdk。
3.在应用程序的资源文件中声明使用的后端存储为iSCSI，并配置上步发现的存储信息：存储服务器的IP地址、端口号、LUN序号。
Figure PCTCN2021143180-appb-000001
4.Kubernetes加载应用程序的资源文件中使用的存储类型、存储服务器IP地址、LUN序号等信息，在宿主机上查找需要的存储卷。
5.Kubernetes将找到的存储卷挂载到应用程序中，至此，应用程序挂载iSCSI类型的共享存储完成。
二、使用FC类型的后端存储。
1.在FC存储服务器上创建存储卷。
2.在集群节点上发现并登录FC共享存储，登录后/dev/disk/by-path目录如下：
#ll/dev/disk/by-path
lrwxrwxrwx 1root root 9 Sep 10 19:14 pci-0000:01:00-fc-0x500991839
4872c-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-t st-p<存储服务器IP地址>-l，发现并登录共享存储卷。并在系统目录/dev/disk/by-path下显示已登录的存储卷。具体如下：
#ll/dev/disk/by-path
lrwxrwxrwx 1root root 9 Sep 10 19:14 ip-172.23.2.50:3260-iscsi-iqn.201
6-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 1root root 9 Sep 10 19:14 pci-0000:01:00-fc-0x500991839
4872c-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-0x500
9918394872c-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-0x5009918394
872c-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)等；还可以是数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称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的存储配置方法的步骤。
PCT/CN2021/143180 2021-06-25 2021-12-30 基于Kubernetes的存储配置方法、系统及电子设备 WO2022267428A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110715790.1 2021-06-25
CN202110715790.1A CN113342280A (zh) 2021-06-25 2021-06-25 基于Kubernetes的存储配置方法、系统及电子设备

Publications (1)

Publication Number Publication Date
WO2022267428A1 true WO2022267428A1 (zh) 2022-12-29

Family

ID=77478931

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/143180 WO2022267428A1 (zh) 2021-06-25 2021-12-30 基于Kubernetes的存储配置方法、系统及电子设备

Country Status (2)

Country Link
CN (1) CN113342280A (zh)
WO (1) WO2022267428A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116094897A (zh) * 2023-01-10 2023-05-09 北京蚂蜂窝网络科技有限公司 一种网页配置方法、装置及存储介质
CN116107515A (zh) * 2023-04-03 2023-05-12 阿里巴巴（中国）有限公司 存储卷挂载与访问方法、设备及存储介质
CN117056029A (zh) * 2023-10-09 2023-11-14 苏州元脑智能科技有限公司 资源处理方法、系统、装置、存储介质及电子设备
CN118276792A (zh) * 2024-06-04 2024-07-02 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) 一种Kubernetes卷资源自动清理方法及系统

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113342280A (zh) * 2021-06-25 2021-09-03 航天云网科技发展有限责任公司 基于Kubernetes的存储配置方法、系统及电子设备
CN114064594B (zh) * 2021-11-22 2023-09-22 马上消费金融股份有限公司 数据处理方法和装置
CN114302085B (zh) * 2021-12-23 2024-02-20 云从科技集团股份有限公司 数据存储方法、装置、电子设备及存储介质
CN114547661B (zh) * 2022-03-21 2024-09-20 京东科技信息技术有限公司 应用配置数据的加解密方法、装置、设备和存储介质
CN115858101B (zh) * 2023-01-31 2023-06-23 天翼云科技有限公司 容器资源视图隔离的方法、装置以及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10216455B1 (en) * 2017-02-14 2019-02-26 Veritas Technologies Llc Systems and methods for performing storage location virtualization
CN109951525A (zh) * 2019-02-18 2019-06-28 山东浪潮云信息技术有限公司 一种基于容器的云盘挂载系统及方法
CN111475469A (zh) * 2020-03-19 2020-07-31 中山大学 Kubernetes用户态应用中基于虚拟文件系统的小文件存储优化系统
CN111966305A (zh) * 2020-10-22 2020-11-20 腾讯科技（深圳）有限公司 持久卷分配方法、装置、计算机设备和存储介质
CN113342280A (zh) * 2021-06-25 2021-09-03 航天云网科技发展有限责任公司 基于Kubernetes的存储配置方法、系统及电子设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10216455B1 (en) * 2017-02-14 2019-02-26 Veritas Technologies Llc Systems and methods for performing storage location virtualization
CN109951525A (zh) * 2019-02-18 2019-06-28 山东浪潮云信息技术有限公司 一种基于容器的云盘挂载系统及方法
CN111475469A (zh) * 2020-03-19 2020-07-31 中山大学 Kubernetes用户态应用中基于虚拟文件系统的小文件存储优化系统
CN111966305A (zh) * 2020-10-22 2020-11-20 腾讯科技（深圳）有限公司 持久卷分配方法、装置、计算机设备和存储介质
CN113342280A (zh) * 2021-06-25 2021-09-03 航天云网科技发展有限责任公司 基于Kubernetes的存储配置方法、系统及电子设备

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116094897A (zh) * 2023-01-10 2023-05-09 北京蚂蜂窝网络科技有限公司 一种网页配置方法、装置及存储介质
CN116107515A (zh) * 2023-04-03 2023-05-12 阿里巴巴（中国）有限公司 存储卷挂载与访问方法、设备及存储介质
CN116107515B (zh) * 2023-04-03 2023-08-18 阿里巴巴（中国）有限公司 存储卷挂载与访问方法、设备及存储介质
CN117056029A (zh) * 2023-10-09 2023-11-14 苏州元脑智能科技有限公司 资源处理方法、系统、装置、存储介质及电子设备
CN117056029B (zh) * 2023-10-09 2024-02-09 苏州元脑智能科技有限公司 资源处理方法、系统、装置、存储介质及电子设备
CN118276792A (zh) * 2024-06-04 2024-07-02 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) 一种Kubernetes卷资源自动清理方法及系统

Also Published As

Publication number Publication date
CN113342280A (zh) 2021-09-03

Similar Documents

Publication Publication Date Title
WO2022267428A1 (zh) 基于Kubernetes的存储配置方法、系统及电子设备
US9588807B2 (en) Live logical partition migration with stateful offload connections using context extraction and insertion
US8830870B2 (en) Network adapter hardware state migration discovery in a stateful environment
US8495255B2 (en) Discovery and configuration of device configurations
US8706850B2 (en) Computer system and configuration management method therefor
US7970852B2 (en) Method for moving operating systems between computer electronic complexes without loss of service
US8937940B2 (en) Optimized virtual function translation entry memory caching
US20120297384A1 (en) Virtual Managed Network
US20120290703A1 (en) Distributed Policy Service
US20130346591A1 (en) Clientless Cloud Computing
US11546228B2 (en) Zero-touch configuration of network devices using hardware metadata
KR20140107173A (ko) 이더넷 스위치들용 룩-업 테이블없이 레이어 2 패킷을 스위치하기
CN106648838B (zh) 一种资源池管理的配置方法及装置
US10291709B2 (en) Protocol independent storage discovery and enablement
US11500678B2 (en) Virtual fibre channel port migration
WO2023029485A1 (zh) 数据处理方法、装置、计算机设备及计算机可读存储介质
CN114070889B (zh) 配置方法、流量转发方法、设备、存储介质及程序产品
US11907173B1 (en) Composable network-storage-based file systems
WO2021050111A1 (en) Replication configuration for multiple heterogeneous data stores
CN113703676B (zh) 一种双活卷的调用方法、装置、设备和介质
US20230388369A1 (en) Techniques for overriding libraries for workloads in a cloud-computing environment
WO2023198128A1 (zh) 一种分布式资源共享方法及相关装置
CN115460292A (zh) 音视频流转发方法、系统、装置、设备及介质
CN117914754A (zh) 一种混合云环境流量采集方法、装置、服务器及存储介质
CN117614822A (zh) Rdma网络配置方法及服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21946901

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21946901

Country of ref document: EP

Kind code of ref document: A1