基于Kubernetes集快速恢复数据的方法及系统

本发明涉及容器与虚拟化技术领域，具体涉及一种基于Kubernetes集快速恢复数据的方法及系统。

容器技术与虚拟化技术已经成为一种被大家广泛认可的容器技术服务器资源共享方式，容器技术可以在按需构建容器技术操作系统实例的过程中为系统提供极大的灵活性。

Docker为一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux和Windows机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。Docker实际上为容器技术的一种实现方式，即容器引擎。Docker的基本功能为创建，删除，配置，启动容器。这里每个容器都依赖一个镜像，即docker使用镜像创建容器。且docker只能对应单个主机。

Kubernetes（简称k8s）为Google开源的一个容器编排引擎，它支持自动化部署，大规模可伸展、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在k8s中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员进行复杂的手工配置和处理。K8s中最小资源单位是pod，Pod，是Kubernetes中的原子调度单位；一个pod中可以有一个或多个容器。K8s可以在一个集上管理容器，包括创建，删除，维护容器等，同时维护这些容器的网络等等。

容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建。其次，当在一个Pod中同时运行多个容器时，常常需要在这些容器之间共享文件。Kubernetes抽象出Volume对象来解决这两个问题。Volume是Pod中能够被多个容器共享的磁盘目录。

Docker 也有Volume的概念，但对它只有少量且松散的管理。在Docker中，Volume是磁盘上或者另外一个容器内的一个目录。直到最近，Docker 才支持对基于本地磁盘的Volume的生存期进行管理。虽然Docker现在也能提供Volume驱动程序，但是目前功能还非常有限；例如，截至Docker1.7，每个容器只允许有一个Volume驱动程序，并且无法将参数传递给卷。

另一方面，Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。

卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。使用卷时, Pod 声明中需要提供卷的类型和卷挂载的位置。

容器中的进程能看到由它们的 Docker镜像和卷组成的文件系统视图。Docker 镜像位于文件系统层次结构的根部，并且任何Volume 都挂载在镜像内的指定路径上。卷不能挂载到其他卷，也不能与其他卷有硬链接。Pod中的每个容器必须独立地指定每个卷的挂载位置。

在现有云数据管理系统和Kubernetes中，云数据管理系统无法直接在Kubernetes中使用备份数据；而且用户直接通过云数据管理系统在备份数据的服务器上恢复需要的数据的过程又非常的复杂。

针对现有技术中存在的不足，本发明提供了一种简单的基于Kubernetes集快速恢复数据的方法。

技术方案：为实现上述目的，本发明提供了一种基于Kubernetes集快速恢复数据的方法，将待恢复数据对应的唯一编号增加到Kubernetes中的同步存储类的配置文件中并在同步存储类的配置文件中自定义存储类名称，然后进行存储类同步；在持久化存储申请的配置文件绑定自定义存储类名称；根据修改后的持久化存储申请的配置文件创建持久化存储申请；Kubernetes根据持久化存储申请调用云数据管理系统接口，将待恢复数据对应的唯一编号、自定义存储类名称和Kubernetes的IP地址发送给云数据管理系统，云数据管理系统根据接收到的信息在存储服务器上创建待恢复数据卷，并在待恢复数据卷上存储待恢复数据、自定义存储类名称和Kubernetes的IP地址；存储服务器将待恢复数据卷共享给Kubernetes。

进一步，存储服务器通过对待恢复数据创建快照的方式创建待恢复数据卷。

进一步，存储服务器通过iSCSI的传输方式共享待恢复数据卷给Kubernetes。

本发明还提供了一种基于Kubernetes集快速恢复数据的系统，包括：

云数据管理模块：用于数据操作管理，将数据备份，并保存备份数据对应的唯一编码；

存储服务器：用于数据的存储，云数据管理模块将备份的数据存储于存储服务器；

服务器组：服务器组中包括多个服务器，服务器组用于安装Kubernetes集，服务器组中的每个服务器上安装Kubernetes集中的一个节点；

其中，将待恢复数据对应的唯一编号增加到服务器组上的Kubernetes中的同步存储类的配置文件中并在同步存储类的配置文件中自定义存储类名称，然后进行存储类同步；在持久化存储申请的配置文件绑定自定义存储类名称；根据修改后的持久化存储申请的配置文件创建持久化存储申请；Kubernetes根据持久化存储申请调用云数据管理模块的接口，将待恢复数据对应的唯一编号、自定义存储类名称和Kubernetes的IP地址发送给云数据管理模块，云数据管理模块根据接收到的信息在第一服务器上创建待恢复数据卷，并在待恢复数据卷上存储待恢复数据、自定义存储类名称和Kubernetes的IP地址；存储服务器将待恢复数据卷共享给服务器组上的Kubernetes。

进一步，服务器组上的Kubernetes中还包括云数据管理系统容器存储接口驱动，所述云数据管理系统容器存储接口驱动对接收到持久化存储申请进行默认存储类的判断，是默认存储类则云数据管理系统容器存储接口驱动将存储类的名称、待恢复数据的对应的唯一编码和Kubernetes的IP地址发送到云数据管理模块，并请求云数据管理模块创建恢复数据卷。

工作原理：在创建Pod之前，利用kubernetes中容器接口服务和动态持久化存储技术基于备份数据进行创建待恢复数据的数据卷，并用存储类调用待恢复数据的数据卷。使用该存储类创建Pod。则可以在Pod启动完毕就能使用备份数据，迅速恢复数据。实现不影响备份数据，又能使用备份数据副本进行恢复。

有益效果：与现有技术相比，本发明能够直接在Kubernetes中使用备份数据，增加了备份数据的使用范围；有效减少了数据的操作，提高了数据使用的灵活性。

图1为本发明流程示意图。

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

本实施例提供一种基于Kubernetes集快速恢复数据的系统，包括安装有云数据管理系统的上位机，上位机主要用于数据操作管理；存储服务器，存储服务器用于存储云数据管理系统中的相关数据；用于安装Kubernetes集的服务器组，Kubernetes集中包括一个Kubernetes-Master（主控节点）和多个Kubernetes-Node（普通节点），服务器组中的每个服务器上分别安装一个Kubernetes集中的节点，即Kubernetes集中的一个Kubernetes-Master和多个Kubernetes-Node分别安装在一个服务器上。其中上位机包括个人电脑、笔记本、平板电脑、手机、智能终端等。

如图1所示，本发明提供一种基于Kubernetes集快速恢复数据的方法，包括如下步骤：

步骤1：云数据管理系统对数据进行备份，每个备份的数据有对应的唯一编号；云数据管理系统将备份的数据存储在存储服务器上；

步骤2：将用户待恢复数据对应的唯一编号增加到配置文件中，Kubernetes-Master根据修改后的配置文件进行同步存储类的操作。即Kubernetes-Master根据以下配置项执行kubectlapply-fstorageClass.yaml命令：

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

annotations:

storageclass.kubernetes.io/is-default-class: "true"

name: ecloudtech-iscsi-storage

provisioner: csi.ecloudtech

parameters:

cci: '486db83a-366b-4bcc-a528-b113d89a4ae3'

reclaimPolicy: Delete

其中，apiVersion：该配置项为默认配置，是Kubernetes的一个必须标识。

kind：配置文件类型，StorageClass为存储类，该配置项使Kubernetes确定该配置文件是创建存储类的配置文件。

metadata.annotations：描述，该配置是云数据管理驱动的自定义配置，设置为false，该存储类当做默认存储类。即如果配置文件中增加了待恢复数据的唯一编号，则该配置项设置为false。

metadata.name：名称，该配置为自定义的创建的存储类的名称，这个名称为使用存储类时的配置项。为存储类的唯一标识。

provisioner：供应商，该配置项为默认配置项，标识该配置是云数据管理系统。

parameters.cci：配置项，该配置为必须配置项，该配置项的内为待恢复数据对应的唯一编号。

步骤3：Kubernetes-Master创建持久化存储申请；Kubernetes-Master根据步骤2中自定义的的创建的存储类的名称配置到持久化存储申请的配置文件中，并修改其他的配置项；然后进行持久化存储申请的操作，并将创建的持久化存储申请发送到多个Kubernetes-Node。即Kubernetes-Master根据以下配置项执行kubectlapply-fclaim.yaml命令：

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: ui2-pvc

namespace: nginx-ingress

spec:

accessModes:

- ReadWriteMany

storageClassName: ecloudtech-iscsi-storage

resources:

requests:

storage: 1Gi

其中，apiVersion：该配置项为默认配置，是Kubernetes的一个必须标识。

kind：配置文件类型，PersistentVolumeClaim为持久化存储申请，该配置项使Kubernetes确定该配置文件是用于创建持久化存储申请的配置文件。

metadata.name：名称，该配置为创建的持久化存储申请定义名称，这个名称为使用持久化存储申请时的配置项。

metadata.namespace：命名空间，该配置为配置持久化存储申请的使用空间标识。

spec.accessModes：使用模式，ReadWriteMany读写多次。

spec.storageClassName：使用的存储类，该配置指定要使用的存储类；即为步骤2中字定义的存储类的名称。

spec.resources.requests.storage：存储使用空间，该配置定义了持久化存储申请调用的存储卷将分配的存储空间大小。

步骤4：Kubernetes-Node读取接收到的持久化申请并查看其中是否有云数据管理驱动的自定义配置，其是否设置为false，如果设置为false，则Kubernetes-Node中的云数据管理系统容器存储接口驱动将存储类的名称、待恢复数据的对应的唯一编码和Kubernetes-Node的IP地址等相关信息发送到云数据管理系统，并请求云数据管理系统创建恢复数据卷。

步骤5：云数据管理系统接收到Kubernetes-Node发送的请求和相关信息后，在存储服务器上创建恢复数据数据卷，并根据待恢复数据对应的唯一编码到待恢复数据，将待恢复数据通过快照的方式恢复到待恢复数据数据卷中；同时将接收到的存储类的名称和Kubernetes-Node的IP地址等相关信息均保存到待恢复数据数据卷中。

步骤6：存储服务器通过iSCSI的传输方式将步骤5中创建的恢复数据数据卷共享到Kubernetes-Node上。

步骤7：在Kubernetes-Node上挂载恢复数据数据卷中的数据。

这样用户就可以通过云数据管理系统直接在Kubernetes集上直接使用备份数据。