CN114253459A - 创建持久数据卷的方法、装置和服务器 - Google Patents

创建持久数据卷的方法、装置和服务器 Download PDF

Info

Publication number
CN114253459A
CN114253459A CN202011002580.XA CN202011002580A CN114253459A CN 114253459 A CN114253459 A CN 114253459A CN 202011002580 A CN202011002580 A CN 202011002580A CN 114253459 A CN114253459 A CN 114253459A
Authority
CN
China
Prior art keywords
data volume
persistent data
pod
node
request
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202011002580.XA
Other languages
English (en)
Inventor
刘月
王海东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Kingsoft Cloud Network Technology Co Ltd
Original Assignee
Beijing Kingsoft Cloud Network Technology Co Ltd
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 Beijing Kingsoft Cloud Network Technology Co Ltd filed Critical Beijing Kingsoft Cloud Network Technology Co Ltd
Priority to CN202011002580.XA priority Critical patent/CN114253459A/zh
Publication of CN114253459A publication Critical patent/CN114253459A/zh
Pending legal-status Critical Current

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
    • 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/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0607—Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
    • 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/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • 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/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Landscapes

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

Abstract

本发明提供了一种创建持久数据卷的方法、装置和服务器，方法应用于第一服务器；第一服务器运行有容器管理应用Kubernetes；当需要启动Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。

Description

创建持久数据卷的方法、装置和服务器
技术领域
本发明涉及数据处理技术领域，尤其是涉及一种创建持久数据卷的方法、装置和服务器。
背景技术
数据卷Volume是存在于一个或多个容器中的特定文件或文件夹，该特定文件或文件夹的目录以独立于联合文件系统的形式存在于宿主机中。在Kubernetes(也可称为K8S)中，需要给每个Pod挂载一个Volume，然后在该Pod里运行的进程或容器才能通过VolumeMounts的方式使用挂载的Volume。
持久数据卷PersistentVolume(简称PV)是外部存储系统中的一块存储空间，可由管理员创建和维护。跟Volume一样，PV具有持久性，生命周期独立于Pod。在创建PV的过程中，需要根据本地路径创建PV，即，在本地的某个节点设备上已有相关目录，在创建PV时需要指定该目录，创建的PV的路径相对固定，导致PV的使用便捷性较差。
发明内容
有鉴于此，本发明的目的在于提供一种创建持久数据卷的方法、装置和服务器，以提高PV的使用便捷性。
第一方面，本发明实施例提供了一种创建持久数据卷的方法，所述方法应用于第一服务器；所述第一服务器运行有容器管理应用Kubernetes；所述方法包括：当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
进一步的，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点的步骤，包括：判断所述Pod是否需要手动调度运行所述Pod的目标节点；如果不需要手动调度运行所述Pod的目标节点，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点。
进一步的，所述方法还包括：如果需要手动调度运行所述Pod的目标节点，从所述Pod中获取所述目标节点的节点名称；通过所述目标节点，将所述目标节点的节点名称保存至所述Pod对应的持久数据卷请求的注解中。
进一步的，所述容器管理应用中运行有默认调度器组件；所述默认调度器组件与预设的扩展调度器组件通信连接；所述根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点的步骤，包括：通过所述默认调度器组件，基于所述Pod的配置需求从预设的容器节点集群中筛选节点，得到第一筛选结果；通过所述扩展调度器组件，基于所述第一筛选结果中各个节点的本地存储状态，从所述第一筛选结果中筛选节点，得到第二筛选结果；基于所述第二筛选结果确定运行所述Pod的目标节点。
进一步的，将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存的步骤，包括：将所述目标节点的节点名称保存至所述Pod对应的持久数据卷请求的注解中。
进一步的，所述容器管理应用与所述容器管理应用的容器应用管理平台的后端服务连接；所述后端服务中预先存储有已创建完成的持久数据卷请求和所述持久数据卷请求的模板；所述Pod对应的持久数据卷请求，通过下述方式创建：通过所述后端服务接收来自所述容器应用管理平台的前端服务的模板发布指令；通过所述后端服务，基于所述模板发布指令在所述第一服务器上创建所述持久数据卷请求。
进一步的，所述持久数据卷请求的模板保存有所述持久数据卷请求指定的存储类型；当所述存储类型为本地持久化存储时，所述存储类型用于指示：在所述目标节点的本地设备上创建逻辑卷和持久数据卷。
进一步的，所述持久数据卷请求的模板保存有所述持久数据卷请求与持久数据卷的绑定条件；当所述绑定条件为延迟绑定时，所述绑定条件用于指示：当存在需要启动的Pod时，且确定了运行所述Pod的目标节点之后，绑定所述持久数据卷请求和所述持久数据卷。
第二方面，本发明实施例提供了一种创建持久数据卷的方法，所述方法应用于物理机服务器，所述物理机服务器运行有容器；所述方法包括：监听是否存在更新的或新增的目标持久数据卷请求；如果监听到更新的或新增的目标持久数据卷请求，判断所述目标持久数据卷请求关联的节点名称，是否与所述物理机服务器的节点名称相同；其中，所述目标持久数据卷请求与待启动的Pod对应；所述目标持久数据卷请求关联的节点名称，为运行所述Pod的目标节点的节点名称；如果与所述物理机服务器的节点名称相同，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
进一步的，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷的步骤，包括：从所述目标持久数据卷请求中获取供应者标识；如果所述供应者标识为本地存储供应者，在所述物理机服务器上创建逻辑卷和持久数据卷。
进一步的，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷的步骤，包括：从所述目标持久数据卷请求中获取存储空间需求；根据所述物理机服务器的路径和所述存储空间需求，在所述物理机服务器上创建本地卷目录；如果所述本地卷目录创建成功，创建所述持久数据卷。
进一步的，所述方法还包括：如果所述本地卷目录创建失败，将本地卷目录创建失败的事件更新至所述目标持久数据卷请求，继续执行从所述目标持久数据卷请求获取存储空间需求的步骤，直至所述本地卷目录创建成功。
进一步的，监听是否存在更新的或新增的目标持久数据卷请求的步骤之前，所述方法还包括：监听所述Pod中是否存储有节点名称；如果所述Pod中存储有节点名称，且所述Pod对应的持久数据卷请求中的存储类型为本地持久化存储，将所述节点名称和所述存储类型对应的供应者标识更新至所述持久数据卷请求的注解中；其中，所述供应者标识为：本地存储供应者。
第三方面，本发明实施例提供了一种创建持久数据卷的方法，所述方法应用于第二服务器，所述第二服务器运行有容器管理应用的容器应用管理平台的后端服务；所述后端服务分别与所述容器应用管理平台的前端服务和所述容器管理应用通信连接；所述后端服务中预先存储有已创建完成的持久数据卷请求和所述持久数据卷请求的模板；所述方法包括：接收来自所述前端服务的模板发布指令；基于所述模板发布指令，在运行所述容器管理应用Kubernetes的第一服务器上创建所述持久数据卷请求，以通过所述第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
进一步的，所述持久数据卷请求的模板保存有所述持久数据卷请求指定的存储类型；当所述存储类型为本地持久化存储时，所述存储类型用于指示：在所述目标节点的本地设备上创建逻辑卷和持久数据卷。
进一步的，所述持久数据卷请求的模板保存有所述持久数据卷请求与持久数据卷的绑定条件；当所述绑定条件为延迟绑定时，所述绑定条件用于指示：当存在需要启动的Pod时，且确定了运行所述Pod的目标节点之后，绑定所述持久数据卷请求和所述持久数据卷。
进一步的，接收来自所述前端服务的模板发布指令的步骤之前，所述方法还包括：接收来自所述前端服务的持久数据卷请求创建指令，在当前设备上创建并存储所述持久数据卷请求；接收来自所述前端服务的持久数据卷请求的模板创建指令，在当前设备上创建并存储所述持久数据卷请求的模板。
第四方面，本发明实施例提供了一种创建持久数据卷的装置，所述装置设置于第一服务器；所述第一服务器运行有容器管理应用Kubernetes；所述装置包括：确定模块，用于当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；保存模块，用于将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定模块，用于绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
第五方面，本发明实施例提供了一种创建持久数据卷的装置，所述装置设置于物理机服务器，所述物理机服务器运行有容器；所述装置包括：监听模块，用于监听是否存在更新的或新增的目标持久数据卷请求；判断模块，用于如果监听到更新的或新增的目标持久数据卷请求，判断所述目标持久数据卷请求关联的节点名称，是否与所述物理机服务器的节点名称相同；其中，所述目标持久数据卷请求与待启动的Pod对应；所述目标持久数据卷请求关联的节点名称，为运行所述Pod的目标节点的节点名称；第一创建模块，用于如果与所述物理机服务器的节点名称相同，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
第六方面，本发明实施例提供了一种创建持久数据卷的装置，所述装置设置于第二服务器，所述第二服务器运行有容器管理应用的容器应用管理平台的后端服务；所述后端服务分别与所述容器应用管理平台的前端服务和所述容器管理应用通信连接；所述后端服务中预先存储有已创建完成的持久数据卷请求和所述持久数据卷请求的模板；所述方法包括：接收模块，用于接收来自所述前端服务的模板发布指令；第二创建模块，用于基于所述模板发布指令，在运行所述容器管理应用Kubernetes的第一服务器上创建所述持久数据卷请求，以通过所述第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
第七方面，本发明实施例提供了一种服务器，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现第一方面、第二方面和第三方面任一项所述的创建持久数据卷的方法。
第八方面，本发明实施例提供了一种机器可读存储介质，所述机器可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使处理器实现第一方面、第二方面和第三方面任一项所述的创建持久数据卷的方法。
本发明提供的一种创建持久数据卷的方法、装置和服务器，方法应用于第一服务器；该第一服务器运行有容器管理应用Kubernetes；当需要启动容器部署单元Pod时，首先根据该Pod的配置需求，从预设的容器节点集群中确定运行该Pod的目标节点；然后将该目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使该目标节点根据该持久数据卷请求创建逻辑卷和持久数据卷；最后，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种创建持久数据卷的方法的流程图；
图2为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图3为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图4为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图5为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图6为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图7为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图8为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图9为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图10为本发明实施例提供的另一种创建持久数据卷的方法的流程图；
图11为本发明实施例提供的一种创建持久数据卷的示意图；
图12为本发明实施例提供的一种创建持久数据卷的装置的结构示意图；
图13为本发明实施例提供的另一种创建持久数据卷的装置的结构示意图；
图14为本发明实施例提供的另一种创建持久数据卷的装置的结构示意图；
图15为本发明实施例提供的一种服务器的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
随着数字化进程和5G(5th generation mobile networks，第五代移动通信技术，简称5G)业务的不断发展，容器、Pod(Pod是Kubernetes的最小单元)、Docker(一种开源的应用容器引擎)、Kubernetes(一种开源的容器集群管理系统)等进入大家视野，且随着Pod的广泛应用，如何满足当前Pod对本地存储的应用需求，成为大家关注的重点。
对于存储管理，Docker存储管理设计中，包含两种容器存放数据的方法，一种是通过Docker镜像元数据管理实现容器数据的存储，或通过存储驱动，提供针对特定文件系统的初始化、镜像层的增删改查和差异比较等操作。当启动一个容器时，Docker加载镜像的所有只读层，并在最上层加入一个读写层，使得容器可以提高镜像构建、存储和分发的效率，节省了时间和存储空间，但是也存在删除容器时数据也随之被删除、多个容器之间的数据无法共享等问题。
Docker又引入数据卷(Volume)机制，Volume是存在于一个或多个容器中的特定文件或文件夹，该特定文件或文件夹的目录以独立于联合文件系统的形式存在于宿主机中，并为数据的共享和持久化提供很多便利。
在K8S中，Volume的使用方式类似于虚拟机的磁盘，需要给Pod(可以比拟为一个逻辑上的虚拟机)挂载一个磁盘，然后该Pod里的进程(容器)才能通过VolumeMounts的方式使用挂载的磁盘；而持久数据卷PV是外部存储系统中的一块存储空间，可由管理员创建和维护。跟Volume一样，PV具有持久性，生命周期独立于Pod。但是在实际使用过程中，当前K8S的PV尚未支持动态创建，需要手动创建成功后，Pod才会对其成功调用，使得PV的使用过程并不便捷。K8S官方给出了静态Local Volume(本地数据卷)的使用案例，使用场景是根据本地路径去创建PV，即，在本地的某个节点设备上已有相关目录，在创建PV时需要指定该目录，创建的PV的路径相对固定，无法满足当前Pod对本地存储的应用需求。其他社区虽然也有对Local Volume使用步骤的一些解读，但未形成系统的动态管理流程，且功能并不完善，广大用户对本地存储的使用并不便捷。
基于此，本发明实施例提供的一种创建持久数据卷的方法、装置和服务器，该技术可以应用于需要创建持久数据卷的应用中。为便于对本实施例进行理解，首先对本发明实施例所公开的一种创建持久数据卷的方法进行详细介绍，方法应用于第一服务器；该第一服务器运行有容器管理应用Kubernetes；其中，Kubernetes可以理解为一种开源的，用于管理云平台中多个主机上的容器化的应用，其目标是让部署容器化的应用简单并且高效。如图1所示，该方法包括如下步骤：
步骤S102，当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点。
上述容器部署单元Pod可以理解为是Kubernetes的最小单元，在Kubernetes集群中，Pod是所有业务类型的基础，Pod是一个或多个容器的组合，容器包含在Pod中；上述配置需求可以包括Pod所需要的CPU(Central Processing Unit，中央处理器)、memory(内存)资源或亲和性等；其中，亲和性可以理解为当满足了指定条件，则将Pod调度到对应的目标节点上；上述容器节点集群中通常包括多个工作节点，该工作节点可以理解为Kubernetes中的参与计算的机器，该机器可以是虚拟机或物理计算机等；上述目标节点可以理解为，从上述容器节点集群中所选取的，可以满足上述Pod的配置需求的工作节点；在实际实现时，当需要启动容器部署单元Pod时，通常需要根据该Pod的CPU或memory等配置需求，从容器节点集群中选取出满足该配置需求的工作节点，将该工作节点确定为运行该Pod的目标节点。
步骤S104，将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷。
上述目标节点的节点名称可以理解为该目标节点所对应的主机的主机名；上述持久数据卷请求可以理解为一种用户对存储资源的需求申请，该持久数据卷请求通常会消耗PV资源，该持久数据卷请求中通常包括存储空间大小、存储类别或请求访问模式等，如，可以以读/写一次模式挂载，或只读多次模式挂载等；上述逻辑卷可以理解为由逻辑磁盘形成的虚拟盘，也可称为磁盘分区；上述持久数据卷可以理解为是由集群管理员配置提供的存储系统上的一段存储空间，是对底层共享存储的抽象，将共享存储作为一种可由用户申请使用的资源，可以独立于Pod生命周期之外，实现数据的持久化存储；在实际实现时，当需要目标创建逻辑卷和持久数据卷时，通常需要先创建上述Pod对应的持久数据卷请求，可以在该持久数据卷请求中指定所需要的最低容量要求和访问模式等，然后将目标节点的节点名称保存至该Pod对应的持久数据卷请求中，目标节点再根据该持久数据卷请求创建相应的逻辑卷和持久数据卷。
步骤S106，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
在实际实现时，持久数据卷请求和持久数据卷通常为一一对应关系，当目标节点根据持久数据卷请求创建持久数据卷后，需要先将上述所创建的持久数据卷和对应的持久数据卷请求进行绑定，然后将上述Pod调度到目标节点，实现Pod与目标节点的绑定，从而使该Pod可以运行在该目标节点上，完成Pod调度到目标节点。
本发明实施例提供的一种创建持久数据卷的方法，当需要启动容器部署单元Pod时，首先根据该Pod的配置需求，从预设的容器节点集群中确定运行该Pod的目标节点；然后将该目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使该目标节点根据该持久数据卷请求创建逻辑卷和持久数据卷；最后，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；该方法重点描述根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点的具体过程，具体对应下述步骤S202至步骤S204；如图2所示，该方法包括如下步骤：
步骤S202，当需要启动容器部署单元Pod时，判断Pod是否需要手动调度运行Pod的目标节点；如果否，执行步骤S204；如果是，执行步骤S210。
在确定运行上述Pod的目标节点时，通常包括以下两种方式：一种是需要手动调度运行该Pod的目标节点，另一种是不需要手动调度运行该Pod的目标节点；因此，当需要启动容器部署单元Pod时，通常需要先判断该Pod是否需要手动调度运行该Pod的目标节点。
步骤S204，如果不需要手动调度运行Pod的目标节点，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点。
如果判断该Pod不需要手动调度运行该Pod的目标节点，则可以根据该Pod的CPU或memory等配置需求，从容器节点集群中选取出满足该配置需求的工作节点，将该工作节点确定为运行该Pod的目标节点。
步骤S206，将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷。
步骤S208，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点；结束。
步骤S210，如果需要手动调度运行Pod的目标节点，从Pod中获取目标节点的节点名称。
如果需要手动调度运行上述Pod的目标节点，相当于在创建Pod时，直接指定了运行该Pod的目标节点，不需要再根据Pod的配置需求，从预设的容器节点集群中选取满足该配置需求的运行该Pod的目标节点；如果指定了运行该Pod的目标节点，可以从该Pod中获取所指定的目标节点的节点名称；在实际实现时，若Pod采用手动调度指定目标节点，则会跳过调度器的调度逻辑，此时可以通过dynamic provisioner监听Pod，若Pod有目标节点的节点名称，如nodeName，则从该Pod中获取目标节点的节点名称。
步骤S212，通过目标节点，将目标节点的节点名称保存至Pod对应的持久数据卷请求的注解中。
如果指定了运行上述Pod的目标节点，可以通过该目标节点，将该目标节点的节点名称更新至该Pod对应的持久数据卷请求的注解中；比如，持久数据卷请求可以以PVC(Persistent Volume Claim)表示，则持久数据卷请求的注解相当于PVC的annotations，在PVC的annotations通常包括volume.kubernetes.io/selected-node:${Pod的nodeName}；当指定了运行上述Pod的目标节点后，且挂载的PVC的StorageClass为local-storage即本地持久化存储，可以将该目标节点的节点名称更新至该注解中。
本发明实施例提供的另一种创建持久数据卷的方法，当需要启动容器部署单元Pod时，首先，判断所述Pod是否需要手动调度运行所述Pod的目标节点；如果不需要手动调度运行所述Pod的目标节点，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点。然后，将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；最后，绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；该方法重点描述根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点的具体过程，具体对应下述步骤S302至步骤S306。该方法中，容器管理应用中运行有默认调度器组件；默认调度器组件与预设的扩展调度器组件通信连接；如图3所示，该方法包括如下步骤：
步骤S302，当需要启动容器部署单元Pod时，通过默认调度器组件，基于Pod的配置需求从预设的容器节点集群中筛选节点，得到第一筛选结果。
在容器管理应用K8S中通常运行有默认调度器组件，该默认调度器组件可以根据特定的调度算法和策略，基于上述Pod的配置需求，从预设的容器节点集群中筛选出满足该Pod的配置需求的，可以运行该Pod的工作节点；在实际实现时，当需要启动容器部署单元Pod时，该默认调度器组件通常会先检查Pod挂载的存储、配置等是否存在，如果存在，则根据该Pod的配置需求中的CPU、memory资源或亲和性等，对K8S的容器节点集群中的所有工作节点(也可以称为Node节点)进行筛选，筛选出满足配置需求的工作节点，即为上述第一筛选结果；通常上述默认调度器组件可以以default-scheduler表示。
步骤S304，通过扩展调度器组件，基于第一筛选结果中各个节点的本地存储状态，从第一筛选结果中筛选节点，得到第二筛选结果。
上述扩展调度器组件可以用于对第一筛选结果作进一步优选，以达到筛选出满足实际需求的工作节点的目的；在实际实现时，在一些特殊场景下，仅通过默认调度器组件并不能满足复杂的调度需求；当默认调度器组件为Pod筛选出满足配置需求的工作节点后，扩展调度器组件需要根据这些筛选出的工作节点的本地存储状态，再进行二次筛选，从中筛选出满足本地存储需求的工作节点，即为上述第二筛选结果，过滤掉了不满足本地存储需求的工作节点；也可以理解为，扩展调度器组件根据容量条件，对第一筛选结果进行二次过滤；通常上述扩展调度器组件可以以Scheduler Extender来表示。
步骤S306，基于第二筛选结果确定运行Pod的目标节点。
在实际实现时，可以从第二筛选结果的工作节点中，动态获取满足本地存储需求的工作节点的容量，根据所获取到的工作节点的容量大小，从第二筛选结果中可以选取出最优的拓扑域，以及最优的工作节点，可以将该最优的工作节点确定为上述Pod的目标节点；比如，当Pod重启时，如果扩展调度器组件发现Pod挂载的是Local PV，若Pod关联的local PV不存在，则重新调度；若Pod关联的Local PV存在且Local PV所在的工作节点满足资源、亲和性等预选条件，则将该Pod调度到Local PV所在的此节点上，防止二次调度引起的Pod与PV的冲突问题。因此，kubelet与apiserver进行交互启动容器时，能将本地数据卷挂载到容器指定的路径下；其中，kubelet和apiserver是K8S的组件；启动容器是在调度器调度后且PVC与PV绑定之后才开始的。
另外，还可以支持对独占块设备的使用需求，当申请使用独占块设备时，可以根据申请块的大小及类型，为Pod分配一个刚好满足请求且不造成资源浪费的块大小的节点。
步骤S308，将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷。
步骤S310，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的方法，当需要启动容器部署单元Pod时，首先，通过默认调度器组件，基于Pod的配置需求从预设的容器节点集群中筛选节点，得到第一筛选结果；通过扩展调度器组件，基于第一筛选结果中各个节点的本地存储状态，从第一筛选结果中筛选节点，得到第二筛选结果；基于第二筛选结果确定运行Pod的目标节点。然后，将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；最后，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；该方法重点描述将目标节点的节点名称与Pod对应的持久数据卷请求关联保存的具体过程，具体对应下述步骤S404；该方法中，容器管理应用与容器管理应用的容器应用管理平台的后端服务连接；其中，容器应用管理平台可以理解为一种通用的、基于Web的Kubernetes多集群容器应用管理平台。该后端服务中预先存储有已创建完成的持久数据卷请求和持久数据卷请求的模板；该持久数据卷请求的模板通常保存有持久数据卷请求指定的存储类型；当存储类型为本地持久化存储时，该存储类型用于指示：在目标节点的本地设备上创建逻辑卷和持久数据卷。
在实际实现时，上述存储类型可以以存储类StorageClass表示，在动态创建PV的过程中，通常需要创建StorageClass，该SrorageClass可以运行在容器应用管理平台的后端服务中；在Dynamic Provisioner(动态供应者)与K8S交互时，通常需要使用该StorageClass，不同的StorageClass可以指定不同的Provisioner，不同的DynamicProvisioner可以各自处理自己指定的Provisioner。比如，StorageClass中可以包括本地存储local-storage、供应者Provisioner、并配置延迟绑定等，其中，local-storage#名称，用于表示K8S支持的某种类型资源的唯一标识。local-storage-provisioner#供应者，用于指定供应者名称，当PVC的yaml(一种用于表达数据序列化的格式)中指定StorageClassName为local-storage时，在确定目标节点并更新到Pod后，DynamicProvisioner可以在PVC的yaml中添加供应者标识。
该持久数据卷请求的模板中除了保存有指定的存储类型外，通常还包括访问模式，如ReadWriteOnce(表示该持久存储卷智能被单个工作节点以读写的方式映射)，或者存储大小，如1G，且与持久数据卷绑定等；另外，该持久数据卷请求的模板还可以用于在Pod中声明挂载持久数据卷请求时要指定持久数据卷请求的名称等。
持久数据卷请求的模板通常还保存有持久数据卷请求与持久数据卷的绑定条件；当该绑定条件为延迟绑定时，该绑定条件用于指示：当存在需要启动的Pod时，且确定了运行Pod的目标节点之后，绑定持久数据卷请求和持久数据卷；在实际实现时，持久数据卷请求与持久数据卷之间通常有两种绑定条件，一种绑定条件是延迟绑定，如采用延迟绑定机制Wait For First Consumer，该延迟绑定方式表示需要有一个使用了该持久数据卷请求的Pod被创建出来，并且，该Pod被调度完毕，也可以理解为，存在需要启动的Pod，并且，确定了可以运行该Pod的目标节点，这时才会将持久数据卷请求与持久数据卷进行绑定，在这种绑定条件下，默认调度器组件和扩展调度器组件在调度时，可以综合考虑选择合适的目标节点，这样就不会导致跟Pod资源设置、selectors(用于将Pod分配到指定的目标节点)、affinity and anti-affinity(亲和性和反亲和性)策略等产生冲突；另一种绑定条件是立即绑定，如采用延迟绑定机制Immediate；该立即绑定方式表示先绑定持久数据卷请求和持久数据卷，考虑到持久数据卷是和工作节点绑定的，这样会导致Pod中的selectors，affinity and anti-affinity等策略会失效，所以，更优选的方式是采用延迟绑定的绑定条件，先根据调度策略从容器节点集群中确定运行Pod的目标节点，然后再绑定持久数据卷请求和持久数据卷。
如图4所示，该方法包括如下步骤：
步骤S402，当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点。
步骤S404，将目标节点的节点名称保存至Pod对应的持久数据卷请求的注解中，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷。
在实际实现时，可以将目标节点的节点名称保存至PVC的annotations中，如可以保存至volume.kubernetes.io/selected-node:${Pod的nodeName}的值中，目标节点再根据该PVC创建逻辑卷和持久数据卷。
上述Pod对应的持久数据卷请求，通过下述方式创建：通过后端服务接收来自容器应用管理平台的前端服务的模板发布指令；通过后端服务，基于模板发布指令在第一服务器上创建持久数据卷请求。
上述容器应用管理平台的前端服务可以理解为客户端等；上述模板发布指令可以理解为用于指示对持久数据卷请求的模块进行发布的指令；在实际实现时，容器应用管理平台的前端服务会向容器应用管理平台的后端服务发送模板发布指令，以将持久数据卷请求的模板在容器应用管理平台的后端服务上发布，同时，通过该后端服务，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求。在创建PVC后，可以通过边缘节点计算平台创建使用该PVC的Pod。
步骤S406，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的方法，当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将所述目标节点的节点名称保存至所述Pod对应的持久数据卷请求的注解中；以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，方法应用于物理机服务器，该物理机服务器运行有容器；在实际实现时，该物理机服务器可以是Dynamic Provisioner(动态供应者)，Dynamic Provisioner一般会通过守护进程集的方式部署在容器节点集群中的每个工作节点上，可以动态创建、删除LVM(Logical Volume Manager，逻辑卷管理)，并根据申请的文件系统类型对LVM进行格式化及挂载，汇报节点磁盘的容量、使用量、可分配量，并根据PV的策略是保留还是删除，对PV执行保留或动态删除；还可以动态创建、删除Local Persistent Volume，且暴露该机器存储的使用量指标到prometheus(一种开源的监控软件)中，供信息采集及告警。如图5所示，该方法包括如下步骤：
步骤S502，监听是否存在更新的或新增的目标持久数据卷请求。
上述目标持久数据卷请求通常包括有参数更新的持久数据卷请求；或者，如果有新增Pod，与该新增Pod对应的新增持久数据卷请求；在实际实现时，Dynamic Provisioner通常会监听是否有更新的目标持久数据卷请求，或者，监听是否有新增的目标持久数据卷请求；比如，当需要启动Pod时，运行有容器管理应用Kubernetes的第一服务器根据Pod的配置需求，为该Pod筛选出了新的更优的目标节点，并通过该目标节点，将该目标节点的节点名称更新到了该Pod对应的持久数据卷请求的注解中，这时，持久数据卷请求有更新。
步骤S504，如果监听到更新的或新增的目标持久数据卷请求，判断目标持久数据卷请求关联的节点名称，是否与物理机服务器的节点名称相同；其中，目标持久数据卷请求与待启动的Pod对应；目标持久数据卷请求关联的节点名称，为运行Pod的目标节点的节点名称。
在实际实现时，如果监听到更新的或新增的目标持久数据卷请求，以物理机服务器是Dynamic Provisioner为例，则Dynamic Provisioner通常会先判断所在物理机服务器的节点名称是否与更新的或新增的目标持久数据卷请求所关联的节点名称一致，如，是否与更新或新增的PVC的annotations中volume.kubernetes.io/selected-node的值一致。通常目标持久数据卷请求与待启动的Pod相对应；目标持久数据卷请求中所关联的工作节点的节点名称，通常为运行该Pod的目标节点的节点名称。
步骤S506，如果与物理机服务器的节点名称相同，根据目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
为方便说明，仍以物理机服务器是Dynamic Provisioner为例，如果目标持久数据卷请求关联的节点名称，与运行有容器的物理机服务器的节点名称相同，则DynamicProvisioner可以根据目标持久数据卷请求，在部署有该Dynamic Provisioner的工作节点上，创建一个LVM的逻辑卷(Logical Volume，简称LV)和对应的持久数据卷；其中，LVM可以理解为是在Linux环境下对磁盘分区进行管理的一种机制，LVM可以是建立在硬盘和分区之上的一个逻辑层，可以用来提高磁盘分区管理的灵活性。LVM可以通过将底层的物理硬盘抽象的封装起来，然后以逻辑卷的方式呈现给上层应用；底层采用LVM实现，增加了对数据卷管理的灵活性。
本发明实施例提供的另一种创建持久数据卷的方法，当监听到更新的或新增的目标持久数据卷请求后，首先判断目标持久数据卷请求关联的节点名称，是否与运行有容器的物理机服务器的节点名称相同，如果相同，根据目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；该方法重点描述根据目标持久数据卷请求创建逻辑卷和持久数据卷的具体过程，具体对应下述步骤S606至步骤S608，如图6所示，该方法包括如下步骤：
步骤S602，监听是否存在更新的或新增的目标持久数据卷请求。
步骤S604，如果监听到更新的或新增的目标持久数据卷请求，判断目标持久数据卷请求关联的节点名称，是否与物理机服务器的节点名称相同；其中，目标持久数据卷请求与待启动的Pod对应；目标持久数据卷请求关联的节点名称，为运行Pod的目标节点的节点名称。
步骤S606，如果与物理机服务器的节点名称相同，从目标持久数据卷请求中获取供应者标识。
上述供应者标识可以用于区分是否为本地存储供应者；在监听到更新的或新增的目标持久数据卷请求后，如果目标持久数据卷请求关联的节点名称，与运行有容器的物理机服务器的节点名称相同，以物理机服务器是Dynamic Provisioner为例，则DynamicProvisioner通常会从该目标数据卷请求中获取供应者标识的信息；比如，可以从PVC的annotations中，获取volume.beta.kubernetes.io/storage-provisioner的值。
步骤S608，如果供应者标识为本地存储供应者，在物理机服务器上创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
如果从目标持久数据卷请求中获取的供应者标识为本地存储供应者，则可以在运行有容器的物理机服务器上创建逻辑卷和对应的持久数据卷；比如，如果PVC的annotations中包含以下信息：volume.beta.kubernetes.io/storage-provisioner:local-storage-provisioner；则Dynamic Provisioner从PVC的annotations中，获取到的volume.beta.kubernetes.io/storage-provisioner的值为local-storage-provisioner，即，从目标持久数据卷请求中获取到的供应者标识为本地存储供应者，则DynamicProvisioner可以根据该目标持久数据卷请求，在部署有该Dynamic Provisioner的工作节点上，创建对应的逻辑卷和持久数据卷。
本发明实施例提供的另一种创建持久数据卷的方法，如果监听到更新的或新增的目标持久数据卷请求，并且判断目标持久数据卷请求关联的节点名称，与物理机服务器的节点名称相同，则从目标持久数据卷请求中获取供应者标识；如果供应者标识为本地存储供应者，在物理机服务器上创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
通过StorageClass模块、Scheduler Extender模块和Dynamic Provisoner模块，这三个功能模块调动，实现Local PV的动态配置，并与Pod映射，将容器的数据持久化存储到本地的磁盘、目录中，提升了PV的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；该方法重点描述根据目标持久数据卷请求创建逻辑卷和持久数据卷的具体过程，具体对应下述步骤S706至步骤S710；如图7所示，该方法包括如下步骤：
步骤S702，监听是否存在更新的或新增的目标持久数据卷请求。
步骤S704，如果监听到更新的或新增的目标持久数据卷请求，判断目标持久数据卷请求关联的节点名称，是否与物理机服务器的节点名称相同；其中，目标持久数据卷请求与待启动的Pod对应；目标持久数据卷请求关联的节点名称，为运行Pod的目标节点的节点名称。
步骤S706，如果与物理机服务器的节点名称相同，从目标持久数据卷请求中获取存储空间需求。
上述存储空间需求可以理解为待启动的Pod需要使用的持久数据卷的存储空间大小；在实际实现时，以物理机服务器是Dynamic Provisioner为例，如果目标持久数据卷请求关联的节点名称，与运行有容器的物理机服务器的节点名称相同，则DynamicProvisioner通常会从目标持久数据卷请求中获取存储空间需求，比如，可以从PVC中获取storage的值。
步骤S708，根据物理机服务器的路径和存储空间需求，在物理机服务器上创建本地卷目录。
上述物理机服务器的路径可以用于指示该物理机服务器的具体的位置；上述本地卷目录通常包含了所配置的本地磁盘的路径；在实际实现时，运行有容器的物理机服务器可以根据PVC中storage大小和Provisioner的path(路径)，创建本地卷目录。
步骤S710，判断本地卷目录是否创建成功。
步骤S712，如果本地卷目录创建成功，创建持久数据卷。以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点；结束。
本地卷目录创建成功，可以理解为已成功配置了相应的本地磁盘空间；在实际实现时，如果本地卷目录创建成功，则运行有容器的物理机服务器，如Dynamic Provisoner，可以创建待启动Pod所对应的持久数据卷，然后通过容器管理应用Kubernetes绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
步骤S714，如果本地卷目录创建失败，将本地卷目录创建失败的事件更新至目标持久数据卷请求，继续执行从目标持久数据卷请求获取存储空间需求的步骤，直至本地卷目录创建成功。
本地卷目录创建失败，可以理解为未成功配置相应的本地磁盘空间；如果本地卷目录创建失败，运行有容器的物理机服务器，如Dynamic Provisoner，通常会将该本地卷目录创建失败的事件反馈至目标持久数据卷请求，以更新该目标持久数据卷请求，并继续执行从目标持久数据卷请求获取存储空间需求的步骤，直至本地卷目录创建成功。
本发明实施例提供的另一种创建持久数据卷的方法，如果监听到更新的或新增的目标持久数据卷请求，并且判断目标持久数据卷请求关联的节点名称，与物理机服务器的节点名称相同，从目标持久数据卷请求中获取存储空间需求，根据物理机服务器的路径和该存储空间需求，在物理机服务器上创建本地卷目录，如果本地卷目录创建成功，创建持久数据卷。以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；如图8所示，该方法包括如下步骤：
步骤S802，监听Pod中是否存储有节点名称。
在实际实现时，运行有容器的物理机服务器，如Dynamic Provisoner，通常会监听Pod中是否存储有节点名称，如监听该Pod中是否存储有nodename。
步骤S804，如果Pod中存储有节点名称，且Pod对应的持久数据卷请求中的存储类型为本地持久化存储，将节点名称和存储类型对应的供应者标识更新至持久数据卷请求的注解中；其中，供应者标识为：本地存储供应者。
在实际实现时，如果监听到Pod中存储有节点名称，并且该Pod所对应的PVC中的StorageClass(存储类型)为local-storage，即本地持久化存储，则将该节点名称更新至PVC的注解中，如，更新至PVC中的volume.kubernetes.io/selected-node的值中，并且，将存储类型对应的供应者标识，即本地存储供应者，也更新至持久数据卷请求的注解中，如，更新至PVC中的volume.beta.kubernetes.io/storage-provisioner的值中，或者，也可以理解为，Dynamic Provisioner会在PVC的yaml中添加供应者名称。
步骤S806，监听是否存在更新的或新增的目标持久数据卷请求。
步骤S808，如果监听到更新的或新增的目标持久数据卷请求，判断目标持久数据卷请求关联的节点名称，是否与物理机服务器的节点名称相同；其中，目标持久数据卷请求与待启动的Pod对应；目标持久数据卷请求关联的节点名称，为运行Pod的目标节点的节点名称。
步骤S810，如果与物理机服务器的节点名称相同，根据目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的方法，如果监听到Pod中存储有节点名称，且Pod对应的持久数据卷请求中的存储类型为本地持久化存储，将节点名称和存储类型对应的供应者标识更新至持久数据卷请求的注解中，当监听到更新的或新增的目标持久数据卷请求后，首先判断目标持久数据卷请求关联的节点名称，是否与运行有容器的物理机服务器的节点名称相同，如果相同，根据目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，方法应用于第二服务器，该第二服务器运行有容器管理应用的容器应用管理平台的后端服务；后端服务分别与容器应用管理平台的前端服务和容器管理应用通信连接；即，该后端服务分别与容器应用管理平台的前端服务和Kubernetes通信连接；后端服务中预先存储有已创建完成的持久数据卷请求和持久数据卷请求的模板；如图9所示，该方法包括如下步骤：
步骤S902，接收来自前端服务的模板发布指令。
步骤S904，基于模板发布指令，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求，以通过该第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的方法，当接收到来自前端服务的模板发布指令后，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求，以通过该第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
本发明实施例还提供另一种创建持久数据卷的方法，该方法在上述实施例方法的基础上实现；如图10所示，该方法包括如下步骤：
步骤S1002，接收来自前端服务的持久数据卷请求创建指令，在当前设备上创建并存储持久数据卷请求。
上述持久数据卷请求创建指令可以理解为用于指示创建持久数据卷请求的指令；上述当前设备可以是一种数据库服务器等；在实际实现时，容器应用管理平台的前端服务会向后端服务发送持久数据卷请求创建指令，后端服务接收到该持久数据卷请求创建指令后，会在当前设备上创建并存储持久数据卷请求，并且，通常会将所创建的存储持久数据卷请求保存到该当前设备的数据库中。
步骤S1004，接收来自前端服务的持久数据卷请求的模板创建指令，在当前设备上创建并存储持久数据卷请求的模板。
上述持久数据卷请求的模板创建指令可以理解为用于指示创建持久数据卷请求的模板的指令；在实际实现时，容器应用管理平台的前端服务会向后端服务发送持久数据卷请求的模板创建指令，后端服务接收到该持久数据卷请求的模板创建指令后，会在当前设备上创建并存储持久数据卷请求的模板，通常会将所创建的存储持久数据卷请求的模板保存到该当前设备的数据库中。
上述持久数据卷请求的模板保存有持久数据卷请求指定的存储类型；当存储类型为本地持久化存储时，存储类型用于指示：在目标节点的本地设备上创建逻辑卷和持久数据卷。
上述持久数据卷请求的模板保存有持久数据卷请求与持久数据卷的绑定条件；当绑定条件为延迟绑定时，绑定条件用于指示：当存在需要启动的Pod时，且确定了运行Pod的目标节点之后，绑定持久数据卷请求和持久数据卷。
步骤S1006，接收来自前端服务的模板发布指令。
步骤S1008，基于模板发布指令，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求，以通过该第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的方法，接收来自前端服务的持久数据卷请求创建指令和持久数据卷请求的模板创建指令，在当前设备上创建并存储持久数据卷请求和持久数据卷请求的模板；当接收到来自前端服务的模板发布指令后，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求，以通过该第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该方法在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
为进一步理解上述实施例，下面提供如图11所示的一种创建持久数据卷的示意图，图11中包括前端(相当于上述容器应用管理平台的前端服务)、容器应用管理平台后端(相当于上述容器应用管理平台的后端服务)、local-pv-scheduler(本地持久数据卷调度器)、local-pv-provisioner(本地持久数据卷供应者，相当于上述运行有容器的物理机服务器)和K8S(相当于上述容器管理应用Kubernetes)；其中，容器应用管理平台后端分别与前端和K8S通信连接；local-pv-scheduler和local-pv-provisioner均与K8S通信连接；K8S中运行有default-scheduler(相当于上述默认调度器组件)；该default-scheduler与预先注册的scheduler extender(相当于上述扩展调度器组件)通信连接。
下面根据该图11，对整个动态配置流程进行介绍：
1.容器应用管理平台后端接收前端发送的创建PVC指令(相当于上述持久数据卷请求创建指令)，在容器应用管理平台后端的当前设备上创建该PVC，并存储到当前设备的数据库中，在创建成功后，向前端反馈PVC创建成功的信息。
2.容器应用管理平台后端接收前端发送的创建PVC模板指令(相当于上述持久数据卷请求的模板创建指令)，在容器应用管理平台后端的当前设备上创建该PVC模板，并存储到当前设备的数据库中，在创建成功后，向前端反馈PVC模板创建成功的信息。
创建的PVC和PVC模板通常只是存到数据库中，发布时选择边缘集群名称才会真正去K8S上创建PVC，边缘计算的特点是多模板，多集群。PVC包含的是PVC的名称、创建者、元数据等信息，PVC模板实际就是K8S支持的一个PVC的yaml，可以将不同的模板发布到不同的边缘节点，所以PVC模板还可以实现对不同边缘集群的不同发布。
3.容器应用管理平台后端接收前端发送的发布PVC模板的指令，通过该容器应用管理平台后端，基于该发布PVC模板的指令，在运行K8S的设备(相当于上述第一服务器)上创建PVC，并存储到数据库中，在创建成功后，通过该容器应用管理平台后端，向前端反馈在运行K8S的设备上创建PVC成功的信息。
4.前端向容器应用管理平台后端发送发布deployment模板，并指定PVC的指令；根据该指令，从在容器应用管理平台后端中预先存储的PVC中选取指定的PVC，通过该容器应用管理平台后端，基于该指令，在运行K8S的设备上创建deployment，在创建成功后，通过该容器应用管理平台后端，向前端反馈在运行K8S的设备上创建deployment成功的信息；其中，该deployment是K8S中最常用的一个对象，它为ReplicaSet和Pod的创建提供了一种声明式的定义方法，从而无需手动创建ReplicaSet和Pod对象，这里ReplicaSet可以用于确保Pod以指定的副本数运行，即如果有Pod异常退出，会自动创建新的Pod来替代；而异常多出来的Pod也会自动回收。
5.前端向容器应用管理平台后端发送发布statefulset，并声明PVC的指令，通过该容器应用管理平台后端，基于该指令，在运行K8S的设备上创建statefulset，并自动为statefulset创建PVC，在创建成功后，通过该容器应用管理平台后端，向前端反馈在运行K8S的设备上创建statefulset成功的信息；其中，statefulset是一种状态副本集，用于解决有状态服务的问题，其主要特点是有序部署，比如，其所生成的Pod名称是有序的，如从0、1到N-1，在启动Pod时，也要按照定义的顺序依次进行，即名称为0的Pod启动之后才能启动名称为1的Pod，即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态。
Statefulset可以支持两种挂载PVC的方式，一种是在Volumes中配置PVC的名称，这种方式要求先独立创建PVC；另一种是在yaml中配置volumeclaimtemplate，该volumeclaimtemplate相当于是一个PVC的yaml，只是写在了statefulset的yaml中，这种方式中，K8S会自动为statefulset创建这个PVC，就不需要像第一种方式那样独立创建一个pvc了。
6.当需要启动Pod时，运行有K8S的设备通过K8S中的default-scheduler，基于该Pod的配置需求从预设的容器节点集群中筛选节点，得到第一筛选结果；通过schedulerextender，基于第一筛选结果中各个节点的本地存储状态，对第一筛选结果进行二次过滤，得到第二筛选结果；该步骤通过预选阶段和优选阶段，并在算法中添加local-pv(本地持久数据卷)因素后，为该PVC筛选出最优的node(相当于上述目标节点)，将该node的节点名称更新到对应的PVC的annotations中，如更新到PVC的volume.kubernetes.io/selected-node＝$node的值中。
7.在实际实现时，local-pv-provisioner会同步K8S资源，并启动对K8S资源的监听，如监听PVC、PV等；当local-pv-provisioner监听到PVC Add和Update，且PVC的annotations中指定的节点名称为当前节点(相当于上述如果监听到更新的或新增的目标持久数据卷请求，且目标持久数据卷请求关联的节点名称，与物理机服务器的节点名称相同)；根据PVC中storage大小，和provisioner的path，创建本地卷目录(相当于上述根据物理机服务器的路径和存储空间需求，在物理机服务器上创建本地卷目录)；如果本地卷目录创建成功，创建PV；否则，清空annotations中指定的node。在PVC的annotations中指定的node清空后，运行有K8S的设备通过default-scheduler和extender scheduler重新调度，确定该Pod的目标节点。
8.在创建PV后，运行有K8S的设备绑定PVC和PV；Pod MountVolume后，Running运行，相当于通过VolumeMounts的方式，将Pod挂载到Volume，运行Pod。
9.运行有K8S的设备将Pod状态返回至容器应用管理平台后端，通过容器应用管理平台后端，将Pod状态呈现给前端；同时，通过容器应用管理平台后端存储statefulset生成的PVC。
上述创建持久数据卷的方法，为提升PV的使用便捷性，边缘节点计算平台提供动态创建本地数据卷(Local Persistent Volume，Local PV，也可以称为本地存储卷)的功能，即动态本地数据卷(Dynamic Local Persistent Volume)，实现Local PV的动态管理，并与Pod映射，将容器的数据持久化存储到本地的磁盘、目录中。该功能基于K8S的Local存储实现，此时数据依然独立于Pod的生命周期，即使业务Pod被删除或重启，数据也不会丢失；同时，与远端存储相比，本地数据卷可以避免网络IO开销，拥有更高的读写性能，所以分布式文件系统和分布式数据库这一类对IO要求高的应用非常适合本地存储。随着5G业务的发展，业务需求量高速增长，该类型容器适用于边缘计算场景，对快速部署、大带宽大算力的要求较高。
本发明实施例提供了一种创建持久数据卷的装置的结构示意图，该装置设置于第一服务器；该第一服务器运行有容器管理应用Kubernetes；如图12所示，该装置包括：确定模块120，用于当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；保存模块121，用于将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定模块122，用于绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的一种创建持久数据卷的装置，当需要启动容器部署单元Pod时，首先根据该Pod的配置需求，从预设的容器节点集群中确定运行该Pod的目标节点；然后将该目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使该目标节点根据该持久数据卷请求创建逻辑卷和持久数据卷；最后，绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该装置在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
进一步的，确定模块120还用于：判断Pod是否需要手动调度运行Pod的目标节点；如果不需要手动调度运行Pod的目标节点，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点。
进一步的，该装置还用于：如果需要手动调度运行Pod的目标节点，从Pod中获取目标节点的节点名称；通过目标节点，将目标节点的节点名称保存至Pod对应的持久数据卷请求的注解中。
进一步的，容器管理应用中运行有默认调度器组件；默认调度器组件与预设的扩展调度器组件通信连接；确定模块120还用于：通过默认调度器组件，基于Pod的配置需求从预设的容器节点集群中筛选节点，得到第一筛选结果；通过扩展调度器组件，基于第一筛选结果中各个节点的本地存储状态，从第一筛选结果中筛选节点，得到第二筛选结果；基于第二筛选结果确定运行Pod的目标节点。
进一步的，保存模块121还用于：将目标节点的节点名称保存至Pod对应的持久数据卷请求的注解中。
进一步的，容器管理应用与容器管理应用的容器应用管理平台的后端服务连接；后端服务中预先存储有已创建完成的持久数据卷请求和持久数据卷请求的模板；Pod对应的持久数据卷请求，通过下述方式创建：通过后端服务接收来自容器应用管理平台的前端服务的模板发布指令；通过后端服务，基于模板发布指令在第一服务器上创建持久数据卷请求。
进一步的，持久数据卷请求的模板保存有持久数据卷请求指定的存储类型；当存储类型为本地持久化存储时，存储类型用于指示：在目标节点的本地设备上创建逻辑卷和持久数据卷。
进一步的，持久数据卷请求的模板保存有持久数据卷请求与持久数据卷的绑定条件；当绑定条件为延迟绑定时，绑定条件用于指示：当存在需要启动的Pod时，且确定了运行Pod的目标节点之后，绑定持久数据卷请求和持久数据卷。
本发明实施例所提供的创建持久数据卷的装置，其实现原理及产生的技术效果和前述创建持久数据卷的方法实施例相同，为简要描述，创建持久数据卷的装置实施例部分未提及之处，可参考前述创建持久数据卷的方法实施例中相应内容。
本发明实施例提供了另一种创建持久数据卷的装置的结构示意图，该装置设置于物理机服务器，该物理机服务器运行有容器；如图13所示，该装置包括：监听模块130，用于监听是否存在更新的或新增的目标持久数据卷请求；判断模块131，用于如果监听到更新的或新增的目标持久数据卷请求，判断目标持久数据卷请求关联的节点名称，是否与物理机服务器的节点名称相同；其中，目标持久数据卷请求与待启动的Pod对应；目标持久数据卷请求关联的节点名称，为运行Pod的目标节点的节点名称；第一创建模块132，用于如果与物理机服务器的节点名称相同，根据目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的装置，当监听到更新的或新增的目标持久数据卷请求后，首先判断目标持久数据卷请求关联的节点名称，是否与运行有容器的物理机服务器的节点名称相同，如果相同，根据目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该装置在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
进一步的，第一创建模块132还用于：从目标持久数据卷请求中获取供应者标识；如果供应者标识为本地存储供应者，在物理机服务器上创建逻辑卷和持久数据卷。
进一步的，第一创建模块132还用于：从目标持久数据卷请求中获取存储空间需求；根据物理机服务器的路径和存储空间需求，在物理机服务器上创建本地卷目录；如果本地卷目录创建成功，创建持久数据卷。
进一步的，该装置还用于：如果本地卷目录创建失败，将本地卷目录创建失败的事件更新至目标持久数据卷请求，继续执行从目标持久数据卷请求获取存储空间需求的步骤，直至本地卷目录创建成功。
进一步的，该装置还用于：监听Pod中是否存储有节点名称；如果Pod中存储有节点名称，且Pod对应的持久数据卷请求中的存储类型为本地持久化存储，将节点名称和存储类型对应的供应者标识更新至持久数据卷请求的注解中；其中，供应者标识为：本地存储供应者。
本发明实施例所提供的创建持久数据卷的装置，其实现原理及产生的技术效果和前述创建持久数据卷的方法实施例相同，为简要描述，创建持久数据卷的装置实施例部分未提及之处，可参考前述创建持久数据卷的方法实施例中相应内容。
本发明实施例提供了另一种创建持久数据卷的装置的结构示意图，该装置设置于第二服务器，该第二服务器运行有容器管理应用的容器应用管理平台的后端服务；后端服务分别与容器应用管理平台的前端服务和容器管理应用通信连接；后端服务中预先存储有已创建完成的持久数据卷请求和持久数据卷请求的模板；如图14所示，该装置包括：接收模块140，用于接收来自前端服务的模板发布指令；第二创建模块141，用于基于模板发布指令，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求，以通过第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。
本发明实施例提供的另一种创建持久数据卷的装置，当接收到来自前端服务的模板发布指令后，在运行容器管理应用Kubernetes的第一服务器上创建持久数据卷请求，以通过该第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据Pod的配置需求，从预设的容器节点集群中确定运行Pod的目标节点；将目标节点的节点名称与Pod对应的持久数据卷请求关联保存，以使目标节点根据持久数据卷请求创建逻辑卷和持久数据卷；绑定持久数据卷请求和持久数据卷，绑定Pod和目标节点。该装置在创建持久数据卷时，可以根据Pod的配置需求选择适合的目标节点，该目标节点再根据持久数据卷请求创建持久数据卷，与预先指定创建持久数据卷的路径的方向不同，从而实现了动态创建持久数据卷，提高了持久数据卷的使用便捷性。
进一步的，持久数据卷请求的模板保存有持久数据卷请求指定的存储类型；当存储类型为本地持久化存储时，存储类型用于指示：在目标节点的本地设备上创建逻辑卷和持久数据卷。
进一步的，持久数据卷请求的模板保存有持久数据卷请求与持久数据卷的绑定条件；当绑定条件为延迟绑定时，绑定条件用于指示：当存在需要启动的Pod时，且确定了运行Pod的目标节点之后，绑定持久数据卷请求和持久数据卷。
进一步的，该装置还用于：接收来自前端服务的持久数据卷请求创建指令，在当前设备上创建并存储持久数据卷请求；接收来自前端服务的持久数据卷请求的模板创建指令，在当前设备上创建并存储持久数据卷请求的模板。
本发明实施例所提供的创建持久数据卷的装置，其实现原理及产生的技术效果和前述创建持久数据卷的方法实施例相同，为简要描述，创建持久数据卷的装置实施例部分未提及之处，可参考前述创建持久数据卷的方法实施例中相应内容。
本发明实施例还提供了一种服务器，参见图15所示，该服务器包括处理器150和存储器151，该存储器151存储有能够被处理器150执行的机器可执行指令，该处理器150执行机器可执行指令以实现上述创建持久数据卷的方法。
进一步地，图15所示的服务器还包括总线152和通信接口153，处理器150、通信接口153和存储器151通过总线152连接。
其中，存储器151可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口153(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线152可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
处理器150可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器150中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器150可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processor，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器151，处理器150读取存储器151中的信息，结合其硬件完成前述实施例的方法的步骤。
本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述创建持久数据卷的方法，具体实现可参见方法实施例，在此不再赘述。
本发明实施例所提供的创建持久数据卷的方法、装置和服务器的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (22)

1.一种创建持久数据卷的方法，其特征在于，所述方法应用于第一服务器；所述第一服务器运行有容器管理应用Kubernetes；所述方法包括：
当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；
将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；
绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
2.根据权利要求1所述的方法，其特征在于，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点的步骤，包括：
判断所述Pod是否需要手动调度运行所述Pod的目标节点；
如果不需要手动调度运行所述Pod的目标节点，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点。
3.根据权利要求2所述的方法，其特征在于，所述方法还包括：
如果需要手动调度运行所述Pod的目标节点，从所述Pod中获取所述目标节点的节点名称；
通过所述目标节点，将所述目标节点的节点名称保存至所述Pod对应的持久数据卷请求的注解中。
4.根据权利要求1所述的方法，其特征在于，所述容器管理应用中运行有默认调度器组件；所述默认调度器组件与预设的扩展调度器组件通信连接；
所述根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点的步骤，包括：
通过所述默认调度器组件，基于所述Pod的配置需求从预设的容器节点集群中筛选节点，得到第一筛选结果；
通过所述扩展调度器组件，基于所述第一筛选结果中各个节点的本地存储状态，从所述第一筛选结果中筛选节点，得到第二筛选结果；
基于所述第二筛选结果确定运行所述Pod的目标节点。
5.根据权利要求1所述的方法，其特征在于，将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存的步骤，包括：将所述目标节点的节点名称保存至所述Pod对应的持久数据卷请求的注解中。
6.根据权利要求1所述的方法，其特征在于，所述容器管理应用与所述容器管理应用的容器应用管理平台的后端服务连接；所述后端服务中预先存储有已创建完成的持久数据卷请求和所述持久数据卷请求的模板；
所述Pod对应的持久数据卷请求，通过下述方式创建：
通过所述后端服务接收来自所述容器应用管理平台的前端服务的模板发布指令；通过所述后端服务，基于所述模板发布指令在所述第一服务器上创建所述持久数据卷请求。
7.根据权利要求6所述的方法，其特征在于，所述持久数据卷请求的模板保存有所述持久数据卷请求指定的存储类型；
当所述存储类型为本地持久化存储时，所述存储类型用于指示：在所述目标节点的本地设备上创建逻辑卷和持久数据卷。
8.根据权利要求6所述的方法，其特征在于，所述持久数据卷请求的模板保存有所述持久数据卷请求与持久数据卷的绑定条件；
当所述绑定条件为延迟绑定时，所述绑定条件用于指示：当存在需要启动的Pod时，且确定了运行所述Pod的目标节点之后，绑定所述持久数据卷请求和所述持久数据卷。
9.一种创建持久数据卷的方法，其特征在于，所述方法应用于物理机服务器，所述物理机服务器运行有容器；所述方法包括：
监听是否存在更新的或新增的目标持久数据卷请求；
如果监听到更新的或新增的目标持久数据卷请求，判断所述目标持久数据卷请求关联的节点名称，是否与所述物理机服务器的节点名称相同；其中，所述目标持久数据卷请求与待启动的Pod对应；所述目标持久数据卷请求关联的节点名称，为运行所述Pod的目标节点的节点名称；
如果与所述物理机服务器的节点名称相同，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
10.根据权利要求9所述的方法，其特征在于，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷的步骤，包括：
从所述目标持久数据卷请求中获取供应者标识；
如果所述供应者标识为本地存储供应者，在所述物理机服务器上创建逻辑卷和持久数据卷。
11.根据权利要求9所述的方法，其特征在于，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷的步骤，包括：
从所述目标持久数据卷请求中获取存储空间需求；
根据所述物理机服务器的路径和所述存储空间需求，在所述物理机服务器上创建本地卷目录；
如果所述本地卷目录创建成功，创建所述持久数据卷。
12.根据权利要求11所述的方法，其特征在于，所述方法还包括：
如果所述本地卷目录创建失败，将本地卷目录创建失败的事件更新至所述目标持久数据卷请求，继续执行从所述目标持久数据卷请求获取存储空间需求的步骤，直至所述本地卷目录创建成功。
13.根据权利要求9所述的方法，其特征在于，监听是否存在更新的或新增的目标持久数据卷请求的步骤之前，所述方法还包括：
监听所述Pod中是否存储有节点名称；
如果所述Pod中存储有节点名称，且所述Pod对应的持久数据卷请求中的存储类型为本地持久化存储，将所述节点名称和所述存储类型对应的供应者标识更新至所述持久数据卷请求的注解中；其中，所述供应者标识为：本地存储供应者。
14.一种创建持久数据卷的方法，其特征在于，所述方法应用于第二服务器，所述第二服务器运行有容器管理应用的容器应用管理平台的后端服务；所述后端服务分别与所述容器应用管理平台的前端服务和所述容器管理应用通信连接；所述后端服务中预先存储有已创建完成的持久数据卷请求和所述持久数据卷请求的模板；所述方法包括：
接收来自所述前端服务的模板发布指令；
基于所述模板发布指令，在运行所述容器管理应用Kubernetes的第一服务器上创建所述持久数据卷请求，以通过所述第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
15.根据权利要求14所述的方法，其特征在于，所述持久数据卷请求的模板保存有所述持久数据卷请求指定的存储类型；
当所述存储类型为本地持久化存储时，所述存储类型用于指示：在所述目标节点的本地设备上创建逻辑卷和持久数据卷。
16.根据权利要求14所述的方法，其特征在于，所述持久数据卷请求的模板保存有所述持久数据卷请求与持久数据卷的绑定条件；
当所述绑定条件为延迟绑定时，所述绑定条件用于指示：当存在需要启动的Pod时，且确定了运行所述Pod的目标节点之后，绑定所述持久数据卷请求和所述持久数据卷。
17.根据权利要求14所述的方法，其特征在于，接收来自所述前端服务的模板发布指令的步骤之前，所述方法还包括：
接收来自所述前端服务的持久数据卷请求创建指令，在当前设备上创建并存储所述持久数据卷请求；
接收来自所述前端服务的持久数据卷请求的模板创建指令，在当前设备上创建并存储所述持久数据卷请求的模板。
18.一种创建持久数据卷的装置，其特征在于，所述装置设置于第一服务器；所述第一服务器运行有容器管理应用Kubernetes；所述装置包括：
确定模块，用于当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；
保存模块，用于将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；
绑定模块，用于绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
19.一种创建持久数据卷的装置，其特征在于，所述装置设置于物理机服务器，所述物理机服务器运行有容器；所述装置包括：
监听模块，用于监听是否存在更新的或新增的目标持久数据卷请求；
判断模块，用于如果监听到更新的或新增的目标持久数据卷请求，判断所述目标持久数据卷请求关联的节点名称，是否与所述物理机服务器的节点名称相同；其中，所述目标持久数据卷请求与待启动的Pod对应；所述目标持久数据卷请求关联的节点名称，为运行所述Pod的目标节点的节点名称；
第一创建模块，用于如果与所述物理机服务器的节点名称相同，根据所述目标持久数据卷请求创建逻辑卷和持久数据卷，以通过容器管理应用绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
20.一种创建持久数据卷的装置，其特征在于，所述装置设置于第二服务器，所述第二服务器运行有容器管理应用的容器应用管理平台的后端服务；所述后端服务分别与所述容器应用管理平台的前端服务和所述容器管理应用通信连接；所述后端服务中预先存储有已创建完成的持久数据卷请求和所述持久数据卷请求的模板；所述方法包括：
接收模块，用于接收来自所述前端服务的模板发布指令；
第二创建模块，用于基于所述模板发布指令，在运行所述容器管理应用Kubernetes的第一服务器上创建所述持久数据卷请求，以通过所述第一服务器执行下述操作：当需要启动容器部署单元Pod时，根据所述Pod的配置需求，从预设的容器节点集群中确定运行所述Pod的目标节点；将所述目标节点的节点名称与所述Pod对应的持久数据卷请求关联保存，以使所述目标节点根据所述持久数据卷请求创建逻辑卷和持久数据卷；绑定所述持久数据卷请求和所述持久数据卷，绑定所述Pod和所述目标节点。
21.一种服务器，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现权利要求1至17任一项所述的创建持久数据卷的方法。
22.一种机器可读存储介质，其特征在于，所述机器可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使处理器实现权利要求1至17任一项所述的创建持久数据卷的方法。
CN202011002580.XA 2020-09-22 2020-09-22 创建持久数据卷的方法、装置和服务器 Pending CN114253459A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011002580.XA CN114253459A (zh) 2020-09-22 2020-09-22 创建持久数据卷的方法、装置和服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011002580.XA CN114253459A (zh) 2020-09-22 2020-09-22 创建持久数据卷的方法、装置和服务器

Publications (1)

Publication Number Publication Date
CN114253459A true CN114253459A (zh) 2022-03-29

Family

ID=80789640

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011002580.XA Pending CN114253459A (zh) 2020-09-22 2020-09-22 创建持久数据卷的方法、装置和服务器

Country Status (1)

Country Link
CN (1) CN114253459A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114816272A (zh) * 2022-06-23 2022-07-29 江苏博云科技股份有限公司 Kubernetes环境下的磁盘管理系统
CN115484231A (zh) * 2022-09-14 2022-12-16 浙江大华技术股份有限公司 一种Pod IP分配方法及相关装置
CN116088768A (zh) * 2023-02-24 2023-05-09 苏州浪潮智能科技有限公司 动态存储分配方法、装置、电子设备和存储介质

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114816272A (zh) * 2022-06-23 2022-07-29 江苏博云科技股份有限公司 Kubernetes环境下的磁盘管理系统
CN114816272B (zh) * 2022-06-23 2022-09-06 江苏博云科技股份有限公司 Kubernetes环境下的磁盘管理系统
CN115484231A (zh) * 2022-09-14 2022-12-16 浙江大华技术股份有限公司 一种Pod IP分配方法及相关装置
CN115484231B (zh) * 2022-09-14 2023-07-18 浙江大华技术股份有限公司 一种Pod IP分配方法及相关装置
CN116088768A (zh) * 2023-02-24 2023-05-09 苏州浪潮智能科技有限公司 动态存储分配方法、装置、电子设备和存储介质

Similar Documents

Publication Publication Date Title
US11226847B2 (en) Implementing an application manifest in a node-specific manner using an intent-based orchestrator
US10540159B2 (en) Model-based virtual system provisioning
CN111488241B (zh) 在容器编排平台实现无代理备份与恢复操作的方法和系统
CN108683516B (zh) 一种应用实例的升级方法、装置和系统
US9971823B2 (en) Dynamic replica failure detection and healing
CN114253459A (zh) 创建持久数据卷的方法、装置和服务器
US9477503B2 (en) Resource management server, resource management method and storage medium for identifying virtual machines satisfying resource requirements
US7890951B2 (en) Model-based provisioning of test environments
US8104038B1 (en) Matching descriptions of resources with workload requirements
US8612553B2 (en) Method and system for dynamically purposing a computing device
WO2011014830A1 (en) Cloud computing: unified management console for services and resources in a data center
CN111343219B (zh) 计算服务云平台
CN114090176A (zh) 一种基于Kubernetes的容器调度方法
CN109992373B (zh) 资源调度方法、信息管理方法和装置及任务部署系统
US10845997B2 (en) Job manager for deploying a bundled application
CN114840223A (zh) 资源处理方法及装置
CN114816272B (zh) Kubernetes环境下的磁盘管理系统
CN114461149B (zh) 一种基于K8s的分布式数据存储方法及装置
CN113687935A (zh) 一种基于超融合设计的云原生存储调度方式
CN113821157A (zh) 一种本地磁盘挂载方法、装置、设备及存储介质
US11768704B2 (en) Increase assignment effectiveness of kubernetes pods by reducing repetitive pod mis-scheduling
CN113934564A (zh) 一种集群日志的存储方法及装置
CN114268629A (zh) 基于私有云的emr系统
CN117369981A (zh) 基于监控器的容器调整方法、设备及存储介质
CN113760446A (zh) 资源调度方法、装置、设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination