基于容器的外接设备管理方法、装置、设备及存储介质与流程

本发明实施例涉及计算机技术领域，尤其涉及一种基于容器的外接设备管理方法、装置、设备及存储介质。

背景技术：

kubernetes(简称：k8s)是google开源的容器集群管理系统。kubernetes是一套完备的分布式系统平台，具有完备的集群管理能力，以容器技术为基础，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。kubernetes包括：容器自动化部署、可扩展资源自动调度机制以及多粒度的资源配额管理等。

然而，基于kubernetes生成的容器本身无法支持加密狗、gpu(graphicsprocessingunit)、fpga等除设备主处理器外的其他处理器的运行，这样会限制基于kubernetes生成的容器的应用范围。

技术实现要素：

本发明提供了一种基于容器的外接设备管理方法、装置、设备及存储介质，以解决现有技术中基于kubernetes生成的容器无法支持除设备主处理器外的其他处理器的运行的技术问题。

第一方面，本发明实施例提供了一种基于容器的外接设备管理方法，包括：

在容器平台内加载至少一个目标设备；

启动并监听所述目标设备对应的外接设备管理插件，所述外接设备管理插件为所述容器平台内运行的应用；

通过所述外接设备管理插件管理所述目标设备对应的外接设备。

进一步的，所述外接设备为加密狗，所述外接设备管理插件包括第一加密狗插件；

所述通过所述外接设备管理插件管理所述目标设备对应的外接设备包括：

获取所述第一加密狗插件采集的外接设备接入信息；

记录所述外接设备接入信息，以对所述目标设备对应的外接设备进行标注。

进一步的，所述通过所述外接设备管理插件管理所述目标设备对应的外接设备还包括：

获取所述第一加密狗插件采集的加密狗类型信息；

根据所述类型信息确定所述加密狗的实现算法，并运行所述实现算法。

进一步的，所述外接设备管理插件还包括第二加密狗插件，

所述通过所述外接设备管理插件管理所述目标设备对应的外接设备还包括：

指示第二加密狗插件确认所述目标设备是否运行加密狗；

若所述目标设备没有运行加密狗，则指示所述第二加密狗插件驱散所述目标设备对应的加密狗pod。

进一步的，所述在容器平台内加载至少一个目标设备包括：

在容器平台内加载至少一个目标设备的内核模块，所述内核模块用于驱动外接设备运行；

在所述容器平台内加载外接设备管理插件的资源管理库；

确认所述目标设备及所述目标设备的目录。

进一步的，所述外接设备为所述目标设备的从处理器，所述外接设备管理插件包括从处理器管理插件；

所述通过所述外接设备管理插件管理所述目标设备对应的外接设备包括下述至少一项：

基于所述从处理器管理插件发送的注册请求进行注册响应，并更新节点扩展设备资源状态信息；

基于所述从处理器管理插件发送的从处理器健康状态信息确定所述从处理器的分配状态；

调用所述从处理器管理插件的allocate进行目标设备的外接设备分配。

第二方面，本发明实施例还提供了一种基于容器的外接设备管理装置，包括：

加载模块，用于在容器平台内加载至少一个目标设备；

监听模块，用于启动并监听所述目标设备对应的外接设备管理插件，所述外接设备管理插件为所述容器平台内运行的应用；

管理模块，用于通过所述外接设备管理插件管理所述目标设备对应的外接设备。

进一步的，所述外接设备为加密狗，所述外接设备管理插件包括第一加密狗插件；

所述管理模块包括：

接入信息获取单元，用于获取所述第一加密狗插件采集的外接设备接入信息；

设备标注单元，用于记录所述外接设备接入信息，以对所述目标设备对应的外接设备进行标注。

第三方面，本发明实施例还提供了一种基于容器的外接设备管理设备，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的基于容器的外接设备管理方法。

第四方面，一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面所述的基于容器的外接设备管理方法。

上述基于容器的外接设备管理方法、装置、设备及存储介质，通过在容器平台内加载至少一个目标设备，并启动及监听目标设备对应的外接设备管理插件，之后，通过外接设备管理插件管理外接设备的技术手段，实现了在基于kuberneters的容器平台内支持外接设备(即其他处理器)的运行，通过外接设备管理插件将外接设备的相关内容挂载到容器平台中，这样便可以在容器平台内查看和使用外接设备，扩大了基于kubernetes生成的容器的应用范围。

附图说明

图1为本发明实施例提供的一种基于容器的外接设备管理方法的流程图；

图2为本发明实施例提供的另一种基于容器的外接设备管理方法的流程图；

图3为本发明实施例提供的又一种基于容器的外接设备管理方法的流程图；

图4为本发明实施例提供的一种基于容器的外接设备管理装置的结构示意图；

图5为本发明实施例提供的一种基于容器的外接设备管理设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

图1为本发明实施例提供的一种基于容器的外接设备管理方法的流程图。本实施例提供的基于容器的外接设备管理方法适用于基于kubernetes生成的容器平台。

具体的，基于kubernetes生成的容器平台内最小计算硬件单元记为节点，节点可以是物理机器，也可以是托管在云供应商上的虚拟机。多个节点组成容器平台内的集群。一般而言，集群内包括一个master节点，master节点用于调度、控制集群的资源等功能，集群内还包括至少一个node节点，node节点为运行容器的节点，也就是运行服务的节点。当希望运行的程序部署到集群时，集群可以智能地将工作分配给内部的各个节点。集群调度的最小单元记为pod，一个pod可以是一个容器，也可以是多个容器。也可以理解为在基于kubernetes生成的容器平台内，将一个或多个容器封装到一个称为pod的高级结构中。相同pod中的任何容器都将共享相同的名称空间和本地网络，即pod主要是让几个紧密连接的几个容器之间共享资源。pod通常由一个抽象层来管理，该抽象层记为部署。部署的主要目的是声明一个pod应该同时运行多少个副本。当将部署添加到集群中时，它将自动地旋转加速所需的pod数量，然后监视pod。进一步的，集群通过发布应用的方式对外提供服务，即提供外界访问的接口。并且，集群通过持久卷进行数据存储，持久卷提供了可以挂载到集群的文件系统，而不与任何特定节点相关联。

示例性的，参考图1，该基于容器的外接设备管理方法具体包括：

步骤110、在容器平台内加载至少一个目标设备。

典型的，目标设备是指pod运行程序时使用的硬件设备。目标设备包括内嵌的至少一个外接设备，或者可以通过usb等物理接口连接的至少一个外接设备。其中，外接设备可以是gpu、加密狗、fpga、infiniteband交换机等。上述外接设备中，加密狗属于通过物理接口连接的外接设备，gpu、fpga、infiniteband交换机等属于目标设备内的非主处理器，实施例中记为从处理器。

进一步的，外接设备管理插件是用于管理与目标设备对应的外接设备的插件，其可以安装在目标设备中，也可以配置在容器平台内。具体的，设定容器平台内集群运行的程序为外接设备管理插件，即将外接管理设备插件作为一个或多个pod运行的程序。此时，在容器平台内加载目标设备是指加载设定内核模块、资源管理库，并明确运行程序的目标设备及目录，以在后续过程中使相应的pod实现程序运行。可选的，设定该步骤具体包括步骤111-步骤113：

步骤111、在容器平台内加载至少一个目标设备的内核模块，所述内核模块用于驱动外接设备运行。

具体的，每个目标设备包括多个内核模块。其中，内核模块是linux内核向外部提供的一个插口，其全称为动态可加载内核模块。内核模块具有独立功能的程序，其可以被单独编译，但不能独立运行。内核模块在运行时被链接到内核，以作为内核的一部分在内核空间运行。内核模块通常由一组函数和数据结构组成，用来实现一种文件系统、一个驱动程序或其他内核上层的功能。实施例中，设定内核模块用于驱动外接设备运行，例如，外接设备为gpu，相应的，内核模块用于驱动gpu运行。再如，外接设备为加密狗，相应的，内核模块用于驱动加密狗运行。

进一步的，由master节点实现加载目标设备的内核模块，以实现目标设备驱动外接设备运行。

步骤112、在所述容器平台内加载外接设备管理插件的资源管理库。

一般而言，加载内核模块后，为了在容器平台内运行外接设备管理插件，容器平台会为外接设备管理插件分配资源。其中，在分配资源时，会将相关的资源分配及使用情况加载至pod对应的资源管理库。可以理解的是，加载资源管理库的过程为现有技术，其相关技术细节可以参考现有技术。

步骤113、确认所述目标设备及所述目标设备的目录。

示例性的，容器平台需要明确可以运行外接设备管理插件的实体设备，实施例中记为目标设备，即创建容器平台内集群的node节点。其中，创建node节点的具体方式实施例不作限定。例如，通过kubectljoin指令将目标设备加入集群中。进一步的，在确定目标设备时，同步获取目标设备的目录。其中，目标设备的目录也可以理解为容器里的准备卷。目录中记载有目标设备运行外接设备管理插件时运行方式、数据存放位置、数据存放格式等数据。

步骤120、启动并监听所述目标设备对应的外接设备管理插件，所述外接设备管理插件为所述容器平台内运行的应用。

具体的，由于实施例中设定外接设备管理插件为所述容器平台内运行的应用，即将外接设备管理插件作为容器平台内一个或多个pod运行的程序，因此，在加载目标设备后，便可以启动外接设备管理插件。即控制运行外接设备管理插件。

一般而言，外接设备管理插件运行过程中，可以检测对应外接设备的接入、注册、运行状态以及资源利用等至少一类数据。进一步的，容器平台监听外接设备管理插件，以确认外接设备管理插件的运行情况、检测数据。其中，启动及监听过程的具体实施方式实施例不作限定，其对应于为pod运行程序的过程。

步骤130、通过所述外接设备管理插件管理所述目标设备对应的外接设备。

示例性的，在监听外接设备管理插件时，容器平台可以确认外接设备管理插件的运行情况、以及外接设备管理插件检测到的相关数据。之后，容器平台便可以结合监听情况指示外接设备管理插件的运行，进而管理外接设备。

例如，设定外接设备管理插件可以检测到外接设备是否插入目标设备。此时，在外接设备管理插件检测到外接设备插入时，便可以向容器平台上报接入信息，此时，容器平台可以根据接入信息确定被接入外接设备的目标设备，并对该目标设备及外接设备进行标注，以便于后续资源分配、调度以及监控运行情况。

再如，设定外接设备管理插件可以确定外接设备当前的健康状态信息，并向容器平台上报健康状态信息，容器平台根据健康状态信息确认外接设备当前处于非健康状态时，便可以中止外接设备当前执行的任务，或者，将外接设备移除可分配列表中，即停止为外接设备所在的目标设备分配相关的任务。

又如，当外接设备管理插件检测到目标设备停止运行外接设备时，向容器平台上报目标设备停止运行的信息，此时，容器平台可以根据该信息指示外接设备管理插件回收相关资源或者删除目标设备对应的pod，以实现合理利用资源。

可以理解的是，上述过程中，将外接设备管理插件作为容器平台内运行的程序，可以使容器平台通过外接设备管理插件查看及使用目标设备上的外接设备。

一般而言，容器平台也可以提供接口服务，以使其他设备或集群通过接口与外接设备管理插件进行通信。

上述，通过在容器平台内加载至少一个目标设备，并启动及监听目标设备对应的外接设备管理插件，之后，通过外接设备管理插件管理外接设备的技术手段，实现了在基于kuberneters的容器平台内支持外接设备(即其他处理器)的运行，通过外接设备管理插件将外接设备的相关内容挂载到容器平台中，这样便可以在容器平台内查看和使用外接设备，扩大了基于kubernetes生成的容器的应用范围。

图2为本发明实施例提供的另一种基于容器的外接设备管理方法的流程图。该基于容器的外接设备管理方法是在上述基于容器的外接设备管理方法的基础上进行具体化。

具体的，所述外接设备为加密狗，所述外接设备管理插件包括第一加密狗插件，所述通过所述外接设备管理插件管理所述目标设备对应的外接设备包括：获取所述第一加密狗插件采集的外接设备接入信息；记录所述外接设备接入信息，以对所述目标设备对应的外接设备进行标注。

其中，加密狗也称加密锁，是一种插在计算机外部接口上的软硬件结合的加密产品。加密狗基于硬件保护技术，通过对软件与数据的保护防止知识产权被非法使用。典型的，第一加密狗插件安装在目标设备中，第一加密狗插件也可以记为加密狗监听器。实际应用中，第一加密狗插件可以安装在容器平台内全部的设备中。第一加密狗插件可以监听目标设备中加密狗的插入/拔出事件，并可以向容器平台上报加密狗资源情况。同时，第一加密狗插件还用于区分加密狗的类别，以保证加密狗的准确运行。

进一步的，所述外接设备管理插件还包括第二加密狗插件，所述通过所述外接设备管理插件管理所述目标设备对应的外接设备还包括：指示第二加密狗插件确认所述目标设备是否运行所述加密狗；若所述目标设备没有运行所述加密狗，则指示所述第二加密狗插件驱散所述目标设备对应的加密狗pod。

其中，第二加密狗插件安装在目标设备中，第二加密狗插件也可以记为加密狗pod管理器。实际应用中，第二加密狗插件可以安装在容器平台内全部的设备中。典型的，第二加密狗插件可以检测到目标设备上的加密狗运行情况，并且根据加密狗的运行情况确定是否驱散目标设备对应的加密狗pod。

可以理解的是，目标设备可以同时安装第一加密狗插件和第二加密狗插件，也可以结合实际情况选择性的安装其中一个插件。如果目标设备同时安装第一加密狗插件和第二加密狗插件，那么第一加密狗插件和第二加密狗插件也可以作为两个模块集成在同一插件中。下述基于容器的外接设备管理方法以目标设备同时安装第一加密狗插件和第二加密狗插件为例进行描述。

具体的，参考图2，该基于容器的外接设备管理方法具体包括：

步骤210、在容器平台内加载至少一个目标设备。

步骤220、启动并监听所述目标设备对应的外接设备管理插件，所述外接设备管理插件为所述容器平台内运行的应用。

具体的，启动并监听第一加密狗插件和第二加密狗插件。

步骤230、获取所述第一加密狗插件采集的外接设备接入信息。

示例性的，第一加密狗插件可以监听加密狗的插入事件。

具体的，第一加密狗插件可以监听目标设备中外部接口是否有设备插入。其中，外部接口可以是并行接口或串行接口。实施例中，以外部接口为usb接口为例进行描述。加密狗插入usb接口后，第一加密狗插件通过电流变化情况确定usb接口插入外接设备。

进一步的，第一加密狗插件监听到插入事件后，确定插入的外接设备是否为加密狗。其中，识别加密狗的手段实施例不作限定，例如，设定第一加密狗插件从外接设备获取身份信息，并根据身份信息确认外接设备是否为加密狗。或者是，由目标设备识别外接设备是否为加密狗，第一加密狗插件对该过程进行监听。当第一加密狗插件监听到目标设备将外接设备识别为加密狗时，确认监听到加密狗插入事件。之后，第一加密狗插件根据加密狗插入事件生成外接设备接入信息。其中，外接设备接入信息用于使容器平台明确加密狗插入事件。外接设备接入信息包含的内容可以根据实际情况设定。例如，外接设备接入信息包括：目标设备的身份信息或加密狗身份信息、加密狗插入标识等。之后，第一加密狗插件将外接设备接入信息上报至容器平台。可选的，第一加密狗插件将外接设备接入信息设置为设备资源上报格式，其中，设备资源上报格式为容器平台内各设备进行资源数据上报时的通用格式。这样做的好处是便于容器平台准确识别及解析外接设备接入信息。

步骤240、记录所述外接设备接入信息，以对所述目标设备对应的外接设备进行标注。

示例性的，容器平台获取外接设备接入信息后进行记录。同时，确认外接设备接入信息中目标设备的身份信息或加密狗身份信息，并通过上述信息对加密狗进行标注。其中，标注的具体方式可以根据实际情况设定。

一般而言，在资源管理库中对加密狗进行标注，可以使容器平台明确当前存在的加密狗及其所属的目标设备，便于后续加密狗运行时的资源管理及调度。

步骤250、指示第二加密狗插件确认目标设备是否运行加密狗。若目标设备没有运行加密狗，则执行步骤260。否则，指示第二加密狗插件保留目标设备对应的加密狗pod。

具体的，容器平台运行第二加密狗插件时最小的调度单元记为pod，实施例中记为加密狗pod。当目标设备运行加密狗时，目标设备对应的pod同样运行。当目标设备没有运行加密狗时，目标设备对应的pod可以停止运行，以防止资源浪费。

进一步的，设定容器平台指示第二加密狗插件监听目标设备是否运行加密狗。具体的，第二加密狗插件根据目标设备当前的进程确定加密狗是否运行，如果没有运行，则说明目标设备没有加密狗资源。如果确定目标设备运行加密狗，则说明相应pod正在运行，此时，指示所述第二加密狗插件保留目标设备对应的加密狗pod。

步骤260、指示所述第二加密狗插件驱散所述目标设备对应的加密狗pod。

具体的，目标设备没有运行加密狗后，容器平台确定加密狗pod不满足资源需求，即容器平台为运行该加密狗pod分配了资源，但是加密狗pod并没有运行加密狗。此时，容器平台指示第二加密狗插件驱散目标设备对应的加密狗pod，即在容器平台内挂掉该加密狗pod。其中，驱散加密狗pod的具体手段为现有技术。

进一步的，每个pod都有相关的pod数据。pod数据可以存储在运行的节点设备中，也可以存储在持久卷中。示例性的，设定加密狗插入目标设备后，对应的目标设备在运行的过程中会记录相关的pod数据，同时持久卷中会记录该pod数据。当加密狗pod驱散后，其对应的pod数据同步被删除。

举例而言，当加密狗从目标设备拔出时，第二加密狗插件确定目标设备没有运行加密狗，此时，容器平台指示第二加密狗插件驱散对应的加密狗pod。

需要说明的是，可以由第一加密狗插件监听加密狗拔出事件，并将加密狗拔出事件通知给第二加密狗插件，以使第二加密狗插件根据加密狗拔出事件驱散对应的加密狗pod。

上述，通过设定第一加密狗插件监听加密狗的插入事件，并生成外接设备接入信息，之后，第一加密狗插件向容器平台上报外接设备接入信息，以使容器平台根据外接设备接入信息确定加密狗插入事件并进行标注，同时，通过设定第二加密狗插件在加密狗停止运行后，驱散对应的加密狗pod的技术手段，实现了容器平台内支持加密狗的运行，同时通过第一加密狗插件和第二加密狗插件查看和运行加密狗，并且保证了资源的合理利用。

在上述基础上，考虑到运行不同类型的加密狗时，需要不同的算法。因此，为了保证在容器平台内准确运行加密狗，实施例中设定：所述外接设备为加密狗，所述外接设备管理插件包括第一加密狗插件，所述通过所述外接设备管理插件管理所述目标设备对应的外接设备还包括：获取所述第一加密狗插件采集的加密狗类型信息；根据所述类型信息确定所述加密狗的实现算法，并运行所述实现算法。

示例性的，设定第一加密狗插件可以确定加密狗类型信息。加密狗类型信息也可以理解为加密狗类别，一般而言，不同厂商或不同型号的加密狗类型不同。具体的，设定第一加密狗插件通过厂商编号和/或产品编号确定加密狗类型信息。进一步的，确定加密狗类型信息后，第一加密狗插件向容器平台上报加密狗类型信息。

之后，容器平台根据类型信息确定运行加密狗所需要的算法，并将该算法记为实现算法。可选的，设定容器平台内预先记录有不同加密狗类型对应的实现算法，当确定当前加密狗对应的类型信息后，便可以确认对应的实现算法，进而指示目标设备运行该实现算法，以实现在容器平台内准确运行加密狗。

图3为本发明实施例提供的又一种基于容器的外接设备管理方法的流程图。该基于容器的外接设备管理方法是在上述基于容器的外接设备管理方法的基础上进行具体化。具体的，本方法中，所述外接设备为所述目标设备的从处理器，所述外接设备管理插件包括从处理器管理插件。

其中，从处理器安装在目标设备中，具有一定的数据处理能力。实施例中，以从处理器为gpu为例进行描述。典型的，从处理器管理插件用于管理从处理器，即管理从处理器注册、发现、分配及回收。实施例中，以从处理器管理插件为deviceplugin+divicemanager为例进行表述。此时，可以将deviceplugin理解为简单的grpcserver。可以记理解的是，当deviceplugin以容器的方式运行时，需要挂载目标设备的相应目录，即实现在目标设备上运行deviceplugin。进一步的，目标设备中的deviceplugin与容器平台内的divicemanager进行通信。此时，容器平台通过divicemanager管理扩展硬件资源。通常，divicemanager可以实现提供注册grpcserver、接受deviceplugin的注册请求、获取并维护节点上的设备列表。divicemanager可以与deviceplugin保持长连接通信，并为deviceplugin提供回调函数，使得在gpu状态改变时，由deviceplugin通知devicemanager根据gpu列表信息，更新节点设备状态。同时，devicemanager还可以实现gpu的分配与管理，维护当前运行任务与已使用gpu的映射关系，提供待分配gpu列表，并通过调用deviceplugin的allocate，协助kubelet完成任务设备分配相关的工作。

参考图3，该基于容器的外接设备管理方法包括：

步骤310、在容器平台内加载至少一个目标设备。

步骤320、启动并监听所述目标设备对应的从处理器管理插件。

具体的，所述从处理器管理插件为所述容器平台内运行的应用。

步骤330、通过所述从处理器管理插件管理所述目标设备对应的从处理器。

一般而言，不同gpu资源或者同一种gpu的不同厂商均可开发对应gpu的deviceplugin。deviceplugin按照约定的api与基于kubernetes的容器平台中的devicemanager进行交互，实现对gpu的管理、分配、回收以及运行状态监控和健康检查。在运行deviceplugin前，预先在目标设备中安装gpu驱动，以保证目标设备内的gpu正常工作。

具体的，该步骤包括可以下述至少一个方案：

方案一、基于所述从处理器管理插件发送的注册请求进行注册响应，并更新节点扩展设备资源状态信息。

具体的，devicemanager内部维护一个供插件注册的grpcserver。容器平台内相应的kubelet启动时，deviceplugin向devicemanager发送注册请求，以通知devicemanager进行gpu注册。其中，deviceplugin利用grpc协议，并通过/var/lib/kubelet/device-plugins/kubelet.sock向devicemanager发起注册请求。通常，deviceplugin向devicemanager发起注册请求时，会向devicemanager汇报gpu的设备信息。其中，该设备信息可选包括：设备名称、api版本号以及unixsocket信息。

进一步的，devicemanager接收到注册请求后，进行注册响应。具体的，devicemanager响应registerrequest，并利用registerresponse向目标设备返回响应结果，以使目标设备确定注册成功。

进一步的，在注册成功后，更新节点扩展设备资源状态信息，以使容器平台确认gpu相关信息，进而实现gpu资源管理与调度。

可选的，如果devicemanager成功进行注册响应，即gpu注册成功，那么，devicemanage可以启动deviceplugin侧的gprcserver，以通过gprcserver实现devicemanager与deviceplugin的通信。

可选的，当容器平台内相应的kubelet重启时，需要重新执行上述步骤进行gpu的注册。

方案二、基于所述从处理器管理插件发送的从处理器健康状态信息确定所述从处理器的分配状态。

具体的，在注册成功后，devicemanager可以通过listandwatchgrpc请求获取当前gpu的健康状态信息。其中，健康状态信息包括健康状态和非健康状态。可选的，还可以获取gpu的列表。

一般而言，获取健康状态的过程是双向的。例如，当deviceplugin检测到某个gpu处于非健康状态时，也会主动通知devicemanager。

如果处于非健康状态的gpu处于空闲状态，那么devicemanager将该gpu挪出可分配列表。如果该gpu已经被某个任务使用，那么，相关的kubelet会中止此任务的使用。

需要说明的是，deviceplugin检测到gpu的健康状态信息的过程也可以称为设备发现过程。此时，deviceplugin的设备发现过程可以具体为：getdevices函数获取gpuuuid，并将其传递给devicemanager。其中，gpuuuid由deviceplugin调用nvidia的nvml库获取。

方案三、调用所述从处理器管理插件的allocate进行目标设备的外接设备分配。

一般而言，从处理器管理插件具有allocate功能，allocate功能可以配置设备的运行环境，即实现目标设备的外接设备分配。在kubelet创建任务时，可以通过gprc调用从处理器管理插件的allocate，进而，通过allocate完成gpu的分配，进而确保gpu在容器中的正常使用。通常，allocate功能配置设备的运行环境时，包括设置环境变量、挂载volume、初始化容器所需的目标设备等。

例如，以设置环境变量为例，说明从处理器管理插件根据allocate进行外接设备分配。具体的，devicemanager传递待分配gpuuuid列表，并调用相关deviceplugin的allocate模块。之后，由allocate模块设置环境变量。

需要说明的是，从处理器管理插件除了执行上述过程外，还可以对外接设备进行回收。具体的，从处理器管理插件可以卸载外接设备的驱动。当然，在任务结束时，外接设备也可以不卸载对应的驱动，此时，从处理器管理插件可以结合实际情况停止进行外接设备回收。同时，容器平台设定由kubelet控制释放任务资源。

上述，通过微处理器管理插件将gpu等从处理器的相关内容挂载到容器平台中，这样便可以在容器平台内查看和使用从处理器，即实现了从处理器的资源管理与调度。

图4为本发明实施例提供的一种基于容器的外接设备管理装置的结构示意图。参考图4，该基于容器的外接设备管理装置包括：加载模块401、监听模块402以及管理模块403。

其中，加载模块401，用于在容器平台内加载至少一个目标设备；监听模块402，用于启动并监听所述目标设备对应的外接设备管理插件，所述外接设备管理插件为所述容器平台内运行的应用；管理模块403，用于通过所述外接设备管理插件管理所述目标设备对应的外接设备。

在上述实施例的基础上，所述外接设备为加密狗，所述外接设备管理插件包括第一加密狗插件；所述管理模块403包括：接入信息获取单元，用于获取所述第一加密狗插件采集的外接设备接入信息；设备标注单元，用于记录所述外接设备接入信息，以对所述目标设备对应的外接设备进行标注。

在上述实施例的基础上，所述管理模块403还包括：类型信息获取单元，用于获取所述第一加密狗插件采集的加密狗类型信息；算法实现单元，用于根据所述类型信息确定所述加密狗的实现算法，并运行所述实现算法。

在上述实施例的基础上，所述外接设备管理插件还包括第二加密狗插件，所述管理模块403包括：运行确认单元，用于指示第二加密狗插件确认所述目标设备是否运行所述加密狗；pod驱散单元，用于若所述目标设备没有运行所述加密狗，则指示所述第二加密狗插件驱散所述目标设备对应的加密狗pod。

在上述实施例的基础上，所述加载模块401包括：模块加载单元，用于在容器平台内加载至少一个目标设备的内核模块，所述内核模块用于驱动外接设备运行；管理库加载单元，用于在所述容器平台内加载外接设备管理插件的资源管理库；目标确认单元，用于确认所述目标设备及所述目标设备的目录。

在上述实施例的基础上，所述外接设备为所述目标设备的从处理器，所述外接设备管理插件包括从处理器管理插件；所述管理模块403具体用于下述至少一项：基于所述从处理器管理插件发送的注册请求进行注册响应，并更新节点扩展设备资源状态信息；基于所述从处理器管理插件发送的从处理器健康状态信息确定所述从处理器的分配状态；调用所述从处理器管理插件的allocate进行目标设备的外接设备分配。

本发明实施例提供的基于容器的外接设备管理装置可用于执行上述基于容器的外接设备管理方法，具备相应的功能和有益效果。

图5为本发明实施例提供的一种基于容器的外接设备管理设备的结构示意图。如图5所示，该基于容器的外接设备管理设备包括处理器50、存储器51、输入装置52和输出装置53；基于容器的外接设备管理设备中处理器50的数量可以是一个或多个，图5中以一个处理器50为例；基于容器的外接设备管理设备中的处理器50、存储器51、输入装置52和输出装置53可以通过总线或其他方式连接，图5中以通过总线连接为例。其中，基于容器的外接设备管理设备可以是一个独立的设备个体进行独立运行，也可以是容器平台中多个设备个体组成的设备体系，此时，处理器50、存储器51、输入装置52和输出装置53分布在各个设备个体中。

存储器51作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的基于容器的外接设备管理方法对应的程序指令/模块(例如，基于容器的外接设备管理装置中的加载模块401、监听模块402以及管理模块403)。处理器50通过运行存储在存储器51中的软件程序、指令以及模块，从而执行基于容器的外接设备管理设备的各种功能应用以及数据处理，即实现上述的基于容器的外接设备管理方法。

存储器51可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据基于容器的外接设备管理设备使用所创建的数据等。此外，存储器51可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器51可进一步包括相对于处理器50远程设置的存储器，这些远程存储器可以通过网络连接至基于容器的外接设备管理设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置52可用于接收输入的数字或字符信息，以及产生与基于容器的外接设备管理设备的用户设置以及功能控制有关的键信号输入。输出装置53可包括显示屏等显示设备。

上述基于容器的外接设备管理设备包含基于容器的外接设备管理装置，可以用于执行任意基于容器的外接设备管理方法，具备相应的功能和有益效果。

本发明实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种基于容器的外接设备管理方法，该方法包括：

在容器平台内加载至少一个目标设备；

启动并监听所述目标设备对应的外接设备管理插件，所述外接设备管理插件为所述容器平台内运行的应用；

通过所述外接设备管理插件管理所述目标设备对应的外接设备。

当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任意实施例所提供的基于容器的外接设备管理方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-onlymemory,rom)、随机存取存储器(randomaccessmemory,ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述基于容器的外接设备管理装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。