一种镜像预加载方法及相关装置

技术领域

本申请涉及云计算技术领域，特别涉及一种镜像预加载方法、镜像预加载装置、服务器以及计算机可读存储介质。

背景技术

随着云计算技术的不断发展，出现了对于云平台中的镜像进行管理的平台工具。Kubernetes是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化，逐渐成为云计算的事实标准。

在实际的云计算业务场景中，经常会遇到如下两个场景：

1，某个服务需要立即启动。例如，金融行业的定时业务、电商平台的秒杀活动，需要在设定周期时间快速拉起服务。

2，某个服务需要快速扩容。例如，测试对服务压测、大促活动、由于资源紧张、工作负载增加等都需要对服务实例数进行快速扩容操作。

在这些场景中，一种解决方案是将容器镜像直接通过容器运行时的拉取命令如docker pull(操作指令)将镜像加载在集群工作节点上，这样Kubelet(镜像管理平台中的节点代理)不需要拉取这些镜像，而是立即使用已经拉取的镜像。据估计，如果能将sidecar(一种模式)容器的镜像、业务容器的基础镜像提前在节点上拉取，Pod(调度的最基本单位)创建过程可以大幅缩短，其中拉镜像的耗时甚至能优化70％以上。

相关技术中，docker(一种应用容器引擎)等容器运行时为单机部署，当集群规模较大时，例如包含成百上千个节点，在每个节点上执行拉取命令将所有需要的镜像预先加载在节点上将耗费大量的人力、物力。也就是说，镜像管理平台中没有提供面向镜像的友好的操作能力，增加了人员成本，降低了对镜像管理的效率。

因此，如何提高将镜像预先加载的效率是本领域技术人员关注的重点问题。

发明内容

本申请的目的是提供一种镜像预加载方法、镜像预加载装置、服务器以及计算机可读存储介质，提高将镜像预先加载的效率，避免在预加载过程投入大量的人工成本。

为解决上述技术问题，本申请提供一种镜像预加载方法，包括：

基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象；

通过缓存控制器基于所述缓存列表对象进行平台资源转换，得到所述镜像管理平台内部的镜像缓存对象；

执行所述镜像缓存对象，实现在对应的节点中预加载对应的镜像。

可选的，基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象，包括：

获取用户输入的资源缓存信息；

基于缓存列表类型的自定义资源对所述资源缓存信息进行处理，得到所述对应的缓存列表对象。

可选的，所述资源缓存信息包括镜像列表信息和节点标识信息，相应的，基于缓存列表类型的自定义资源对所述资源缓存信息进行处理，得到所述对应的缓存列表对象，包括：

将所述镜像列表信息和所述节点标识信息添加至所述缓存列表类型的自定义资源中，并配置超时时间信息和失败重试次数，得到所述对应的缓存列表对象。

可选的，通过缓存控制器基于所述缓存列表对象进行平台资源转换，得到所述平台内部的镜像缓存对象，包括：

通过缓存控制器中的镜像管理进程基于所述缓存列表对象中的镜像列表信息和节点标识信息，创建对应节点的多个镜像缓存对象。

可选的，还包括：

当得到所述缓存列表对象时，通过所述缓存控制器对所述缓存列表对象进行验证。

可选的，还包括：

通过缓存控制器中的镜像刷新进程按照预设周期对节点中的进行刷新处理；其中，所述刷新处理包括镜像补缺处理、镜像更新处理、镜像扩充加载处理。

可选的，执行所述镜像缓存对象，包括：

通过所述镜像缓存对象确定对应的镜像，并将所述镜像加载至对应的节点中。

本申请还提供一种镜像预加载装置，包括：

预加载列表获取模块，用于基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象；

对象创建模块，用于通过缓存控制器基于所述缓存列表对象进行平台资源转换，得到所述镜像管理平台内部的镜像缓存对象；

镜像缓存模块，用于执行所述镜像缓存对象，实现在对应的节点中预加载对应的镜像。

本申请还提供一种服务器，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上所述的镜像预加载方法的步骤。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的镜像预加载方法的步骤。

本申请所提供的一种镜像预加载方法，包括：基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象；通过缓存控制器基于所述缓存列表对象进行平台资源转换，得到所述镜像管理平台内部的镜像缓存对象；执行所述镜像缓存对象，实现在对应的节点中预加载对应的镜像。

通过在镜像预加载方法内基于自定义资源创建对应的缓存列表对象，实现配置出对应的自定义的缓存列表对象，然后通过缓存控制器基于所述缓存列表对象进行平台资源转换，得到所述镜像管理平台内部的镜像缓存对象，通过该镜像缓存对象实现自动的镜像缓存操作，而不需要通过手动方式配置每个节点，提高对镜像进行预加载的效率，进一步的提高镜像使用的效率。

本申请还提供一种镜像预加载装置、服务器以及计算机可读存储介质，具有以上有益效果，在此不作赘述。

附图说明

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

图1为本申请实施例所提供的一种镜像预加载方法的流程图；

图2为本申请实施例所提供的一种镜像预加载装置的结构示意图；

图3本申请实施例所提供的一种服务器的结构示意图。

具体实施方式

本申请的核心是提供一种镜像预加载方法、镜像预加载装置、服务器以及计算机可读存储介质，提高将镜像预先加载的效率，避免在预加载过程投入大量的人工成本。

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

相关技术中，docker等容器运行时为单机部署，当集群规模较大时，例如包含成百上千个节点，在每个节点上执行拉取命令将所有需要的镜像预先加载在节点上将耗费大量的人力、物力。也就是说，镜像管理平台中没有提供面向镜像的友好的操作能力，增加了人员成本，降低了对镜像管理的效率。

因此，本申请提供一种镜像预加载方法，通过在镜像预加载方法内基于自定义资源创建对应的缓存列表对象，实现配置出对应的自定义的缓存列表对象，然后通过缓存控制器基于所述缓存列表对象进行平台资源转换，得到所述镜像管理平台内部的镜像缓存对象，通过该镜像缓存对象实现自动的镜像缓存操作，而不需要通过手动方式配置每个节点，提高对镜像进行预加载的效率，进一步的提高镜像使用的效率。

以下通过一个实施例，对本申请提供的一种镜像预加载方法进行说明。

请参考图1，图1为本申请实施例所提供的一种镜像预加载方法的流程图。

本实施例中，该方法可以包括：

S101，基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象；

可见，本步骤旨在基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象。

其中，自定义资源(CRD，Custom Resource Definition)为Kubernetes(镜像管理平台)的一种资源，允许用户自定义新的资源类型，可基于已有的Kubernetes资源，例如Deployment、Job等，拓展集群能力，通过CRD资源，可以将用户自定义资源类型转换为k8s上资源类型。除CRD还需要用户提供一个Controller(控制器)以实现自己的逻辑，专门负责监听对应的资源类型的资源变化，将对应资源实例化为对应k8s上的资源对象。

进一步的，本步骤可以包括：

步骤1，获取用户输入的资源缓存信息；

步骤2，基于缓存列表类型的自定义资源对资源缓存信息进行处理，得到对应的缓存列表对象。

可见，本可选方案中主要是说明如何生成缓存列表对象。本可选方案中，获取用户输入的资源缓存信息；基于缓存列表类型的自定义资源对资源缓存信息进行处理，得到对应的缓存列表对象。可见，本可选方案中可以基于用户输入的资源缓存信息确定到对应的缓存列表对象。

进一步的，资源缓存信息包括镜像列表信息和节点标识信息，上一可选方案中的步骤2可以包括：

将镜像列表信息和节点标识信息添加至缓存列表类型的自定义资源中，并配置超时时间信息和失败重试次数，得到对应的缓存列表对象。

可见，本可选方案中主要是说明如何具体生成缓存列表对象。本可选方案中，将镜像列表信息和节点标识信息添加至缓存列表类型的自定义资源中，并配置超时时间信息和失败重试次数，得到对应的缓存列表对象。

S102，通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象；

在S101的基础上，本步骤旨在通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象。

其中，镜像管理平台内部的镜像缓存对象可以是Job对象或CronJob对象。通过这些对象就可以在节点中预加载对应的镜像。

进一步的，本步骤可以包括：

通过缓存控制器中的镜像管理进程基于缓存列表对象中的镜像列表信息和节点标识信息，创建对应节点的多个镜像缓存对象。

可见，本可选方案中主要是说明如何创建镜像缓存对象。本可选方案中，通过缓存控制器中的镜像管理进程基于缓存列表对象中的镜像列表信息和节点标识信息，创建对应节点的多个镜像缓存对象。

进一步的，本实施例还可以包括：

当得到缓存列表对象时，通过缓存控制器对缓存列表对象进行验证。

可见，本可选方案中主要是说明还可以对对象数据进行验证。本可选方案中，当得到缓存列表对象时，通过缓存控制器对缓存列表对象进行验证。

进一步的，本实施例还可以包括：

通过缓存控制器中的镜像刷新进程按照预设周期对节点中的进行刷新处理；其中，刷新处理包括镜像补缺处理、镜像更新处理、镜像扩充加载处理。

可见，本可选方案中主要是说明还可以对镜像进行刷新。本可选方案中，通过缓存控制器中的镜像刷新进程按照预设周期对节点中的进行刷新处理；其中，刷新处理包括镜像补缺处理、镜像更新处理、镜像扩充加载处理。

其中，镜像补缺处理是对存在缺失的镜像进行补全。其中，镜像更新处理是指对镜像进行更新。其中，镜像扩充加载处理是对存在扩充的新节点时，对该节点进行镜像的加载处理。

S103，执行镜像缓存对象，实现在对应的节点中预加载对应的镜像。

在S102的基础上，本步骤旨在执行镜像缓存对象，实现在对应的节点中预加载对应的镜像。

进一步的，本步骤可以包括：

通过镜像缓存对象确定对应的镜像，并将镜像加载至对应的节点中。

综上，本实施例通过在镜像预加载方法内基于自定义资源创建对应的缓存列表对象，实现配置出对应的自定义的缓存列表对象，然后通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象，通过该镜像缓存对象实现自动的镜像缓存操作，而不需要通过手动方式配置每个节点，提高对镜像进行预加载的效率，进一步的提高镜像使用的效率。

以下通过另一具体的实施例，对本申请提供的一种镜像预加载方法做进一步说明。

首先，对Kubernetes平台中的Job、CronJob、Label、Selector等内置对象进行说明。

其中，Job对象用来创建1个或多个Pod,并保证指定数量(.spec.completions)的Pod成功完成。当一个Pod成功完成时(.status.phase＝Succeeded)，Job会记录已完成的Pod的数量，但完成的数量达到指定值时，这个Job就完成了。当Pod执行失败时，Job会不断创建一个新的Pod进行重试，直到失败次数达到.spec.backoffLimit指定的数值，整个Job的执行失败。

其中，CronJob对象是管理Job，也就是每一个周期创建一个Job去执行任务,一次只能管理一个Job。CronJob和Linux中的CronTab就非常类似，在Job的基础上加上了时间调度，在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。

其中，Label对象是是一组绑定到K8s资源对象上的key/value对。同一个对象的labels属性的key必须唯一，label可以附加到各种资源对象上，如Node,Pod,Service等。通过给指定的资源对象捆绑一个或多个不用的label来实现多维度的资源分组管理功能，以便于灵活，方便地进行资源分配，调度，配置，部署等管理工作。

其中，Selector对象是Kubernetes的分组机制，通过Label Selector客户端/用户能够识别一组有共同特征或属性的资源对象。

可见，基于上述原生的kubernetes资源，可以创建如下的Job/CronJob对象实现将特定的一组镜像缓存在集群内的特定的一组节点上。

其中，yaml文件中image为需要加载至节点上的镜像，key和value为需要加载镜像的节点上的label键值对。因此，用户可以在Job中指定一个镜像进行预加载的范围，以及这个镜像的拉取策略、Job的生命周期等。一个Job创建并执行完成后，会分别在具有匹配label的节点上创Pod，以此来完成规模化的预热。从而，应用程序pod几乎立即启动，因为不需要从registry(镜像仓库)中提取镜像。

然而，上述Job/CronJob对象只能实现将特定的某一个镜像对象加载在一组节点上，对于加载批量镜像的需求只能创建一组Job/CronJob对象，操作繁琐且对用户不友好。此外，Kubernetes原生Job/CronJob对象从机制上可实现于特定节点上加载特定镜像，但无法实现镜像缓存对象创建、更新、删除、查询等管理功能，需要将上述策略包装为k8s的操作器(即CRD)，用于直接在kubernetes集群的工作节点上创建和管理容器镜像的缓存。CRD本身是Kubernetes的一种资源，允许用户自定义新的资源类型，可基于已有的Kubernetes资源，例如Deployment、Job等，拓展集群能力，通过CRD资源，可以将用户自定义资源类型转换为k8s上资源类型。除了CRD还需要用户提供一个控制器以实现自己的逻辑，专门负责监听对应的资源类型的资源变化，将对应资源实例化为对应k8s上的资源对象。

本实施例可以定义了一个类型为“Cache”(缓存列表对象)的自定义资源，示例内容如下：

其中，images为需要加载至节点上的镜像列表，key和value为需要加载镜像的节点上的label键值对。

进一步的，当yaml文件中的node-selector为空时，可将images中表明的镜像部署于全部节点。

进一步的，imges字段中表明的镜像可为于私有仓库地址(如Harbor)，若有需要，可于imagePullSecrets字段中填充访问私有仓库地址所需的secret信息，这些secret必须存在cache所在的namespace中.

进一步的，timeoutSeconds为镜像拉取超时时间，backoffLimit为失败重试次数。

除CRD对象cache外，本实施例实现了一个控制器(可以称为cache-controller)和验证器(可以称为cache-webhooker)。其中，cache-webhook-server负责验证Cache资源的字段。用户可以使用kubectl命令来创建和删除cache资源，cache-controller有内置的Manager(镜像管理进程)例程，负责拉取和删除镜像；cache-controller有内置的refresh(镜像刷新进程)例程，负责周期性刷新镜像，此外cache-controller在Cache资源的status字段中更新镜像拉取、刷新和镜像删除的状态。

进一步的，上述操作的工作流程如下：

通过指定要拉取的镜像列表来创建cache，并用nodeSelector用于指定镜像应该被缓存的节点。该请求首先经由APIServer发送至cache-webhook-server验证cacheSpec的字段，在收到来自webhook的成功响应后，APIServer将Cache资源持久保存在etcd(一种存储系统)中。这会触发对cache-controller的manager例程处理，并将请求排队，对于每个请求，manager都会创建一组k8s-Job对象，负责将镜像拉取至节点上进行缓存。manager会跟踪它创建的job，一旦job完成，它就会将响应放在一个单独的队列中，来更新Cache资源的状态部分，并改变etcd中的状态数据。

除了manager进程外，refresh进程定期运行以保持镜像缓存刷新。其一，若节点缓存中缺少某镜像，它会重新将镜像拉取至该节点；其二，若镜像仓库中的镜像存在更新，它会重新拉取该镜像至所有节点；其三，若cache中表明的label键值对覆盖的节点范围有扩充，则会将镜像拉取至新节点上。

此外，cache对象中的images字段表明的镜像列表可以更新，nodeSelector也可以更改用于改变镜像需要加载至的节点范围。

此外，cache对象可以删除，cache对象删除前会清空所有加载至特定节点上的所有特定镜像，释放节点的存储资源，之后删除cache对象。

进一步的，使用场景如下：

1，集群维度预热

该场景可在整个集群维度持续预热一些基础镜像，可以是那些基本上每个业务Pod中都会带有的基础sidecar镜像。维持nodeselector字段对象为空，默认整个集群维度所有节点上统一加载images规定的所有镜像，预热后续新增的节点上也会立即自动做加载。提前做一次规模化的镜像预热，可以大幅提升后续Pod扩容、发布的速度。

2，节点维度预热

指定selector预热范围，可匹配key＝value标签的节点。因此，对于一些多租的Kubernetes集群中会存在多个不同的业务资源池，其中可能需要将一些特定的业务镜像按资源池维度来预热。

可见，本实施例通过在镜像预加载方法内基于自定义资源创建对应的缓存列表对象，实现配置出对应的自定义的缓存列表对象，然后通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象，通过该镜像缓存对象实现自动的镜像缓存操作，而不需要通过手动方式配置每个节点，提高对镜像进行预加载的效率，进一步的提高镜像使用的效率。

下面对本申请实施例提供的镜像预加载装置进行介绍，下文描述的镜像预加载装置与上文描述的镜像预加载方法可相互对应参照。

请参考图2，图2为本申请实施例所提供的一种镜像预加载装置的结构示意图。

本实施例中，该装置可以包括：

预加载列表获取模块100，用于基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象；

对象创建模块200，用于通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象；

镜像缓存模块300，用于执行镜像缓存对象，实现在对应的节点中预加载对应的镜像。

可选的，该预加载列表获取模块100，具体用于获取用户输入的资源缓存信息；基于缓存列表类型的自定义资源对资源缓存信息进行处理，得到对应的缓存列表对象。

可选的，资源缓存信息包括镜像列表信息和节点标识信息，相应的，基于缓存列表类型的自定义资源对资源缓存信息进行处理，得到对应的缓存列表对象，包括：

将镜像列表信息和节点标识信息添加至缓存列表类型的自定义资源中，并配置超时时间信息和失败重试次数，得到对应的缓存列表对象。

可选的，该对象创建模块200，具体用于通过缓存控制器中的镜像管理进程基于缓存列表对象中的镜像列表信息和节点标识信息，创建对应节点的多个镜像缓存对象。

可选的，该装置还可以包括：

数据验证模块，用于当得到缓存列表对象时，通过缓存控制器对缓存列表对象进行验证。

可选的，该装置还可以包括：

镜像刷新模块，用于通过缓存控制器中的镜像刷新进程按照预设周期对节点中的进行刷新处理；其中，刷新处理包括镜像补缺处理、镜像更新处理、镜像扩充加载处理。

可选的，该镜像缓存模块300，具体用于通过镜像缓存对象确定对应的镜像，并将镜像加载至对应的节点中。

可见，本实施例通过在镜像预加载方法内基于自定义资源创建对应的缓存列表对象，实现配置出对应的自定义的缓存列表对象，然后通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象，通过该镜像缓存对象实现自动的镜像缓存操作，而不需要通过手动方式配置每个节点，提高对镜像进行预加载的效率，进一步的提高镜像使用的效率。

本申请还提供了一种服务器，请参考图3，图3本申请实施例所提供的一种服务器的结构示意图，该服务器可包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时可实现如上述任意一种镜像预加载方法的步骤。

如图3所示，为服务器的组成结构示意图，服务器可以包括：处理器10、存储器11、通信接口12和通信总线13。处理器10、存储器11、通信接口12均通过通信总线13完成相互间的通信。

在本申请实施例中，处理器10可以为中央处理器(Central Processing Unit，CPU)、特定应用集成电路、数字信号处理器、现场可编程门阵列或者其他可编程逻辑器件等。

处理器10可以调用存储器11中存储的程序，具体的，处理器10可以执行异常IP识别方法的实施例中的操作。

存储器11中用于存放一个或者一个以上程序，程序可以包括程序代码，程序代码包括计算机操作指令，在本申请实施例中，存储器11中至少存储有用于实现以下功能的程序：

基于用户输入的信息和镜像管理平台的自定义资源创建对应的缓存列表对象；

通过缓存控制器基于缓存列表对象进行平台资源转换，得到镜像管理平台内部的镜像缓存对象；

执行镜像缓存对象，实现在对应的节点中预加载对应的镜像。

在一种可能的实现方式中，存储器11可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及至少一个功能所需的应用程序等；存储数据区可存储使用过程中所创建的数据。

此外，存储器11可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

通信接口12可以为通信模块的接口，用于与其他设备或者系统连接。

当然，需要说明的是，图3所示的结构并不构成对本申请实施例中服务器的限定，在实际应用中服务器可以包括比图3所示的更多或更少的部件，或者组合某些部件。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现如上述任意一种镜像预加载方法的步骤。

该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

对于本申请提供的计算机可读存储介质的介绍请参照上述方法实施例，本申请在此不做赘述。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种镜像预加载方法、镜像预加载装置、服务器以及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。