CN112433823A - 动态虚拟化物理卡的设备及方法 - Google Patents

Abstract

本发明揭露一种动态虚拟化服务器上的多个物理卡的方案。发送来自多个物理卡的状态信息；接收指定虚拟卡的信息，指定虚拟卡是根据所述状态信息及容器所需的虚拟卡资源所选择；根据指定虚拟卡的信息，虚拟化特定物理卡，特定物理卡为多个物理卡至少其中之一；以及将指定虚拟卡分配给容器使用。本发明动态地根据实际容器应用的需要，自动地将物理卡虚拟化。

Description

动态虚拟化物理卡的设备及方法

技术领域

本发明一般地涉及计算机领域。更具体地，本发明涉及动态虚拟化物理卡方法、可读存储介质及服务器。

背景技术

时间片轮转调度在计算机领域是使用最广泛的算法。每个进程被分配一个时间段，称作时间片，即该进程允许运行的时间。如果在时间片结束时进程还在运行，则该进程会暂停并将处理器资源分配给另一个进程。如果进程在时间片结束前阻塞或结束，则处理器当即进行切换。调度程序所要做的就是维护一张就绪进程列表，当进程用完分配给它的时间片后，它的其他任务被移到队列的末尾。

时间片轮转调度存在许多问题，例如服务质量(QoS)、隔离性与队首阻塞(HOL)皆无法保证。特别是在人工智能计算卡需要大量的运算资源，如采用时间片轮转调度配置计算机资源，将会导致运行效益太低，便有了虚拟化人工智能计算卡的需求。

现有技术是利用SR-IOV技术将人工智能计算卡切分为多个虚拟卡后，通过kubernetes开源软件的设备插件接口开发对应的插件，管理这些虚拟卡，将虚拟卡提供给容器应用。实现容器应用对人工智能计算卡计算资源的共享。

在一个运行kubernetes的集群中，一旦将节点上的人工智能计算卡切分好后，就无法自动地选择卡的切分粒度。如果要将这些计算卡重新进行切分，就需要停止设备插件，重新进行切分，再重启设备插件。在一个大规模的集群中，特别是云服务器，暂停提供服务来重新切分虚拟卡是不现实。再者，事先切分好的虚拟卡的大小不一定是用户需要的，容易造成资源的浪费。

因此，一种根据需求动态切分物理卡的方案是迫切需要的。

发明内容

为了至少部分地解决背景技术中提到的技术问题，本发明的方案提供了一种动态虚拟化物理卡方法、可读存储介质及服务器。

在一个方面中，本发明揭露一种动态虚拟化集群上的多个物理卡的方法，所述多个物理卡设置于业务节点上。所述方法包括：接收来自所述多个物理卡的状态信息；根据所述状态信息及容器所需的虚拟卡资源，选择特定物理卡，所述特定物理卡为所述多个物理卡至少其中之一；根据所述虚拟卡资源，以及规划所述特定物理卡的虚拟化方式。

在另一个方面，本发明揭露一种动态虚拟化服务器上的多个物理卡的方法，包括：发送来自所述多个物理卡的状态信息；获得虚拟化方式；根据所述虚拟化方式，发送指定虚拟卡的信息，所述指定虚拟卡根据所述状态信息及容器所需的虚拟卡资源所选择；根据所述指定虚拟卡的信息，虚拟化特定物理卡，所述特定物理卡为所述多个物理卡至少其中之一；以及将所述指定虚拟卡分配给所述容器使用。

在另一个方面，本发明揭露一种计算机可读存储介质，其上存储有动态虚拟化集群上的多个物理卡的计算机程序代码，当所述计算机程序代码由处理装置运行时，执行前述的方法。

在另一个方面，本发明揭露一种动态虚拟化多个物理卡的服务器，包括处理器和存储器，所述存储器中存有计算机可读程序，所述处理器通过运行所述存储器中的程序，以完成前述的方法。

本发明提供一种切分物理卡并按需调度容器的方案，动态地根据实际容器应用的需要，自动地将服务器上的物理卡进行虚拟化，为容器应用提供适当切分粒度的虚拟卡，无需影响其他正在使用物理卡的用户的工作。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，并且相同或对应的标号表示相同或对应的部分其中：

图1是示出本发明实施例的框架图；

图2是示出本发明实施例的计算装置的内部结构示意图；

图3是示出本发明实施例弹性调配集群的示意图；

图4是示出本发明另一实施例的板卡的示意图；

图5是示出本发明另一实施例的云端设备的示意图；

图6是示出本发明另一实施例动态虚拟化物理卡的流程图；

图7是示出本发明另一实施例的调度扩展器的流程图；

图8是示出本发明另一实施例动态虚拟化物理卡示例的示意图；以及

图9是示出本发明另一实施例分配后各物理卡被占用的示意图。

具体实施方式

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

应当理解，本发明的权利要求、说明书及附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。本发明的说明书和权利要求书中使用的术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的，而并不意在限定本发明。如在本发明说明书和权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。还应当进一步理解，在本发明说明书和权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。

下面结合附图来详细描述本发明的具体实施方式。

虚拟化是一种将一个计算机设备虚拟为多个虚拟机的技术。当在一台计算机上同时运行多个虚拟机时，每个虚拟机可运行不同的操作系统，在操作系统上运行的应用程序可以在独立的空间内互不影响，从而显著提高计算机的工作效率。

虚拟化技术与多任务或是超线程技术是不同的。多任务是指在一个操作系统中多个程序同时运行，而在虚拟化技术中，则可以同时运行多个操作系统，而且每一个操作系统中都有多个程序在运行，每一个操作系统都运行在各自相对应的虚拟机上。超线程技术是单处理器模拟双处理器来平衡程序运行性能，这两个模拟出来的处理器是不能分离的，只能协同工作，而在虚拟化技术中，虚拟处理器或部件是独立运作的。

虚拟化技术通常是采用软件重新定义划分计算机的物理资源，以实现计算机资源的动态分配和灵活调度，进而提高资源利用率。

在本发明中会涉及到硬件、软件、固件的描述，硬件包括各类装置、单元、器、设备等，软件包括各类操作系统、机、程序、工具等，固件包括功能等，当涉及硬件、软件、固件的总称时，以部件描述之。这样的安排只为了更清楚的描述本发明的技术，并非对本发明的技术做任何的限制。

本发明的一个实施例是一种采用虚拟化技术的框架，应用在人工智能芯片上。更详细来说，是用于神经网络的机器学习设备上，该机器学习设备可以是卷积神经网络加速器。图1是人工智能芯片虚拟化的框架图，该框架100包括用户空间102、内核空间104及片上系统106，在图上以虚线区隔开。用户空间102为用户程序的运行空间，只执行简单的运算，不能直接调用系统资源，必须通过系统接口，才能向内核发出指令。内核空间104是内核代码运行的空间，可以执行任意命令，调用系统的一切资源。片上系统106包括各种功能模块，通过内核空间104与用户空间102进行协作。

在此实施例中，用户空间102的硬件统一称之为器或设备，片上系统106的硬件统一称之为装置或单元，作为区分。这样的安排只为了更清楚的描述此实施例的技术，并非对本发明的技术做任何的限制。

除非另行强调，此实施例以将一个部件虚拟化为四个虚拟部件来示例说明，但本发明不限制虚拟部件的数量。

用户空间102在未运行虚拟化前，是由硬件监测器工具108所控制，通过调用接口获取片上系统106的信息。硬件监测器工具108不仅可以采集片上系统106的信息，还可以实时获取上层软件对片上系统106资源的开销，为用户实时掌握当前片上系统106的详细信息和状态，这些详细信息和状态可以是：硬件设备型号、固件版本号、驱动版本号、设备利用率、存储装置开销状态、板卡功耗和板卡峰值功耗、快速外设组件互连(PCIe)等数十种数据。基于硬件监测器工具108的版本及应用场景的不同，所监测的信息内容及数量会有所差异。

在系统启动虚拟化后，用户空间102的操作改由用户虚拟机110接管，用户虚拟机110是对真实计算环境的抽象和模拟，系统会分配一套数据结构来管理用户虚拟机110的状态，其数据结构包括全套寄存器、物理内存的使用情况、虚拟设备的状态等等。此实施例的用户空间102的物理空间虚拟化为四个虚拟空间112、114、116、118，这四个虚拟空间112、114、116、118独立互不影响，可分别搭载不同的用户操作系统，如图中所示的用户操作系统1、用户操作系统2、用户操作系统3及用户操作系统4，用户操作系统可以是Windows、Linux、Unix、iOS、安卓等，每个用户操作系统上分别运行不同的应用程序。

在此实施例中，用户虚拟机110是以快速仿真器(QEMU)来实现。QEMU是一个用C语言编写的开源虚拟化软件，通过动态二进制转换将接口虚拟化，并提供一系列的硬件模型，使得用户操作系统1、用户操作系统2、用户操作系统3、用户操作系统4都认为自己直接访问片上系统106。用户空间102包括处理器、存储器、I/O设备等，QEMU可以将用户空间102的处理器虚拟化为四个虚拟处理器，并将存储器虚拟化为四个虚拟存储器，亦将I/O设备的虚拟化为四个虚拟I/O设备。每个用户操作系统各占用一部分用户空间102的资源，例如各占四分之一，也就是分别能访问一个虚拟处理器、一个虚拟存储器及一个虚拟I/O设备，以执行该用户操作系统的任务。通过这种模式，用户操作系统1、用户操作系统2、用户操作系统3、用户操作系统4就能独立运作。

内核空间104载有内核虚拟机120及芯片驱动程序122。内核虚拟机120与QEMU搭配，主要负责内核空间104及片上系统106的虚拟化，使得每个用户操作系统在访问片上系统106时都能获得自己的地址空间。更详细来说，映射给用户操作系统的片上系统106上的空间实际上是映射给这个进程的虚拟部件。

从用户虚拟机110的角度来看，虚拟机运行期间，QEMU通过内核虚拟机120提供的系统调用接口进行内核设置，QEMU使用了内核虚拟机120的虚拟化功能，为自己的虚拟机提供硬件虚拟化加速以提高虚拟机的性能。从内核虚拟机120的角度来看，当用户无法直接跟内核空间104交互时，需要借助用户空间102的管理工具，因此需要借助QEMU这个运行在用户空间102的工具。

芯片驱动程序122用以驱动物理功能(physical function，PF)126，在虚拟机运行期间，用户空间102不由硬件监测器工具108经芯片驱动程序122来访问片上系统106，因此用户操作系统1、用户操作系统2、用户操作系统3、用户操作系统4分别配置有内核空间124，用以载入芯片驱动程序122，使得各用户操作系统依然可以驱动片上系统106。

片上系统106是通过kubernetes和SR-IOV技术来执行虚拟化的。kubernetes是一套用于自动部署、扩展和管理容器化应用程序的开源系统，其仅支持对处理器和内存等计算资源的管理，在云计算/云存储的应用场景下，此实施例进一步在开源系统的基础上针对图1的框架100设备进行调度和管理，为kubernetes创建了设备插件接口。此实施例通过使用这些接口来管理片上系统106的各装置或虚拟装置。SR-IOV技术可以使得片上系统106的各部件(即前述的功能模块)虚拟化，其是一种基于硬件的虚拟化解决方案，允许在虚拟机之间高效共享PCIe资源，SR-IOV技术使得单个PCIe资源可由片上系统106的多个虚拟部件共享，为这些虚拟部件提供专用的资源。这样，每个虚拟部件都有自己对应的唯一可访问的资源。

当用户虚拟机110开始运行时，用户操作系统112、114、116、118占用了硬件资源。在用户操作系统112、114、116、118之上，需要安装如docker的容器引擎。用户空间102通过容器引擎获取片上系统106的资源，并将这些资源分割为互相隔离的资源结构，即为容器(container)，每个容器看起来就像一个真实的操作环境，在其内部可以运行应用程序，原则上一个容器只启动一个进程。而kubernetes可以将多个紧密相关的容器整合成一个pod，作为调度的最小单位，使得pod中的容器的进程成为进程组，作为一个整体来调度，方便共享资源。

此实施例的片上系统106包含硬件和固件。硬件包括只读存储器ROM(未显示于图中)，用以存储固件，而固件包括物理功能126，用于支持或协作SR-IOV的PCIe功能，物理功能126拥有完全配置PCIe资源的权力。在实施SR-IOV技术时，物理功能126会虚拟化出多个虚拟功能(virtual function，VF)128，在此实施例中为四个虚拟功能128。虚拟功能128是一种轻量级PCIe功能，受物理功能126管理，可与物理功能126以及与同一物理功能126关联的其他虚拟功能128共享PCIe物理资源。虚拟功能128仅允许控制物理功能126配置给自己的资源。

一旦在物理功能126中启用了SR-IOV，各个虚拟功能128就可以通过自身的总线、设备和功能编号去访问的自己的PCIe配置空间。每个虚拟功能128都具有一个内存空间，用于映射其寄存器集。虚拟功能128驱动程序对寄存器集进行操作以启用其功能，并直接指定给对应的用户虚拟机110。虽然是虚拟的，但会让用户虚拟机110认为是实际存在的PCIe设备。

片上系统106可以用一张物理卡搭配PCIe 138来实现，每张物理卡可以实现的功能不一定相同，在此实施例中，物理卡上的功能模块可以包括计算装置130、视频编解码装置132、JPEG编解码装置134、存储装置136。计算装置130为智能处理装置(intelligentprocessing unit，IPU)，用以执行神经网络的卷积计算；视频编解码装置132用以对视频数据进行编解码；JPEG编解码装置134用以对采用JPEG算法的静态图片进行编解码；存储装置136可以为动态随机存取存储器(DRAM)，用以存储数据。单张物理卡可以包括前述的所有、部分或单一装置种类。

PCIe 138即为前述的PCIe，在虚拟机运行期间，PCIe 138会虚拟化为四个虚拟接口140，虚拟功能128与虚拟接口140为一对一对应关系，也就是第一虚拟功能对接第一虚拟接口，第二虚拟功能对接第二虚拟接口，以此类推。

为方便说明，此实施例通过SR-IOV技术，示例性的将计算装置130最多虚拟化为4个虚拟计算装置142、将视频编解码装置132最多虚拟化为4个虚拟视频编解码装置144、将JPEG编解码装置134最多虚拟化为4个虚拟JPEG编解码装置146、将存储装置136最多虚拟化为四个虚拟存储装置148。

每个用户操作系统分别配置一组虚拟套件，每组虚拟套件包括一个用户虚拟机110、一个虚拟接口140、一个虚拟功能128、一个虚拟计算装置142、一个虚拟视频编解码装置144、一个虚拟JPEG编解码装置146及一个虚拟存储装置148。每组虚拟套件各自独立运行互不影响，用来执行相对应的用户操作系统所交付的任务，以确定每个用户操作系统能通过所配置的虚拟接口140及虚拟功能128访问所配置的虚拟计算装置142、虚拟视频编解码装置144、虚拟JPEG编解码装置146及虚拟存储装置148。

更详细来说，每个用户操作系统在执行任务时，响应pod内容器的任务不同，所需占用虚拟卡的类型及数量可能也不同，例如：某个任务是进行矩阵卷积计算，则该用户操作系统会通过所配置的虚拟接口140及虚拟功能128访问所配置的虚拟计算装置142全卡、半卡或

卡，数量可能是1张、2张或4张；如某个任务是进行视频编解码，则该用户操作系统会通过所配置的虚拟接口140及虚拟功能128访问所配置的虚拟视频编解码装置144全卡、半卡或

卡，数量可能是1张、2张或4张；如某个任务是进行JPEG编解码，则该用户操作系统会通过所配置的虚拟接口140及虚拟功能128访问所配置的虚拟JPEG编解码装置146全卡、半卡或

卡，数量可能是1张、2张或4张；如某个任务是读取或写入数据，则该用户操作系统会通过所配置的虚拟接口140及虚拟功能128访问所配置的虚拟存储装置148全卡、半卡或

卡，数量可能是1张、2张或4张。

图2示出了一种计算装置130的内部结构示意图。计算装置130示例性的展示十六个处理单元核(处理单元核0至处理单元核15)，用于执行矩阵计算任务，每四个处理单元核组成一个处理单元组，也就是集群(cluster)。更详细来说，处理单元核0至处理单元核3组成第一集群202，处理单元核4至处理单元核7组成第二集群204，处理单元核8至处理单元核11组成第三集群206，处理单元核12至处理单元核15组成第四集群208。计算装置130基本上是以集群为单元执行计算任务。

计算装置130还包括存储单元核210及共享存储单元212。存储单元核210主要用于控制数据交换，作为计算装置130与存储装置136沟通的渠道。共享存储单元212用以暂存这些集群202、204、206、208的计算中间值。在虚拟化运行期间，存储单元核210会相应切分为多个虚拟存储单元核，共享存储单元212也同样会切分为多个虚拟共享存储单元。

每个虚拟计算装置142分别配置一个虚拟存储单元核、一个虚拟共享存储单元以及一个集群，以支撑pod的任务。同样地，每个虚拟计算装置142各自独立运作，互不影响。

前述各装置均可弹性地根据pod的需求，适当地分配虚拟卡的数量以及所需资源。图3是以计算装置142为例示出可能的分配方式。第一种示例性的分配方式302即为前述有四个虚拟计算装置142的情况，每个虚拟计算装置142配置一个集群。第二种示例性的分配方式304为三个虚拟计算装置142的情况，假设第一虚拟计算装置所对应的pod需要使用较多的硬件资源，因此配置两个集群，而第二虚拟计算装置及第三虚拟计算装置分别配置一个集群。第三种示例性的分配方式306为两个虚拟计算装置142均分集群资源的情况，即各配置两个集群。第四种示例性的分配方式308同样是有两个虚拟计算装置142的情况，但第一虚拟计算装置所对应的pod需要使用较多的硬件资源，因此配置三个集群，而第二虚拟计算装置配置一个集群。

计算装置130的集群数量至少应与虚拟计算装置142的数量相同，以确保每个虚拟计算装置142能配置一个集群，当集群数量多于虚拟计算装置142的数量时，便可以根据pod的需求，将集群适当地配置给虚拟计算装置142，以增加硬件配置弹性。

本发明的另一个实施例同样采用图1所示的框架，与前述实施例不同处在于PCIe138被虚拟化为最多6个虚拟接口140，其他部件则维持最多4个虚拟部件。在此实施例中，系统会以所有部件中最少虚拟部件数量作为虚拟化运行的基础，也就是4个虚拟部件。在这种情况下，PCIe 138将有2个闲置虚拟接口140，QEMU可以选择关闭或不配置这两个闲置的虚拟接口140，或是将这两个虚拟接口140纳入虚拟化运行中，例如：第一虚拟功能及第二虚拟功能所对应的pod需要较多的接口资源，则QEMU可以分别配置2个虚拟接口140给第一虚拟功能及第二虚拟功能，而分别配置1个虚拟接口给其他虚拟功能。

本发明还揭露另一个实施例，为一种板卡，也就是物理卡，其包括了片上系统106的框架。如图4所示，板卡400包括至少一个芯片402(图中仅示出2个)、存储装置404、接口装置406和控制器件408。

图4的芯片402整合了图1的计算装置130、视频编解码装置132及JPEG编解码装置143等，可以处于多负载和轻负载等不同的工作状态。通过控制器件408可以实现对芯片402中的计算装置130、视频编解码装置132及JPEG编解码装置143的工作状态的调控。

存储装置404与芯片402通过总线414连接，用于存储数据。存储装置404即为图1的存储装置136，如前所述，其包括多组DDR通道410。每一组DDR通道410可以包括多个DDR4颗粒(芯片)。每一组DDR通道410与芯片402通过总线414连接。

接口装置406即为图1的PCIe 138，与芯片402电连接。接口装置406用于实现芯片402与外部设备412(即用户空间102)之间的数据传输。待处理的任务由外部设备412通过PCIe接口传递至芯片402，实现数据转移。接口装置406还可以是其他的接口，本发明并不限制接口的具体表现形式，能够实现虚拟化功能即可。另外，芯片402的计算结果仍由接口装置406传送回外部设备412。

控制器件408即为图1的内核空间104，与芯片402电连接，以便对芯片402的状态进行监控。具体地，芯片402与控制器件408可以通过SPI接口电连接。控制器件408可以包括单片机(micro controller unit，MCU)，并存储有内核虚拟机120和芯片驱动程序122。

本发明的另一个实施例是一种动态虚拟化集群上的多个物理卡的方法，需特别注意的是，此处的集群与图2的集群202、204、206、208不同，此处的集群指的是服务器的集合，以下将服务器的集合称为节点集群，以兹区别。此方法应用在如图5所示的云端设备上，此云端设备包括主节点501及多个业务节点502，每个节点都是一个服务器，上面装配有如图4所示的物理卡。

主节点501搭载kubernetes的主组件，作为节点集群的管理控制中心，用于管理业务节点502的容器化的应用。主组件可以在节点集群中任何节点上运行，但实务上为了分离控制平面与业务平面，一般会把管理组件放到单独的服务器上，以免业务和管理组件抢占计算资源互相干扰，故此实施例配置一台独立的服务器只运行所有主组件，即为图中的主节点501。主组件包括kube-apiserver 503、ETCD 504、kube-controller-manager 505、kube-scheduler 506等。kube-apiserver 503用于暴露kubernetes的应用程序接口，任何的资源请求/调用操作都是通过kube-apiserver 503所提供的接口进行。ETCD 504是kubernetes提供默认的存储系统，用于保存节点集群中所有的网络配置和对象的状态信息。kube-controller-manager 505作为节点集群内部的管理控制中心，负责节点集群内的各节点、pod副本、服务端点(end point)、命名空间(namespace)、服务账号(serviceaccount)、资源定额(resource quota)的管理，当某个业务节点502故障时，kube-controller-manager 505会及时发现并执行自动化修复流程，以确保节点集群始终处于预期的工作状态。kube-scheduler(调度器)506用以为pod选择一个合适的业务节点502。在此实施例中，kube-scheduler 506进一步根据容器的需求，规划并配置合适的虚拟卡。

每个业务节点502包括多张物理卡508，用来提供特定的硬件资源以执行任务，图中示例性的展示4张物理卡508。每张物理卡508均可被虚拟化为数量不一的虚拟卡509，供pod使用，每张虚拟卡509各自独立，不受其他虚拟卡509的影响。为方便说明，此实施例的物理卡508均可拆分为最多4张虚拟卡509，换言之，物理卡508可以被拆分成1张虚拟全卡、2张虚拟半卡或4张虚拟

卡。

业务节点502搭载kubernetes的节点组件，以提供kubernetes运行时的环境，并维护pod，进而促使业务节点502完成主节点501交付的任务。节点组件包括kubelet 510、kube-proxy 511、docker 512及设备插件513等，其中kubelet 510是节点代理的核心，用以监视已分配给业务节点的pod，kube-proxy 511维护网络规则并执行连接转发来实现kubernetes服务，docker 512用于运行容器，设备插件513虚拟化物理卡，并分配给容器使用。

图5中示例性的展示5个业务节点502，其集合即为节点集群，每个业务节点502示例性的包括4张物理卡508。此实施例的动态虚拟化集群上的多个物理卡的方法如图6所示。

在步骤601中，发送来自多个物理卡508的状态信息。各业务节点502的设备插件513将自己所拥有的物理卡508的状态信息发送给主节点501的kube-apiserver 503。状态信息包括每个物理卡508切分成虚拟卡509的上限值、每个物理卡508的可选择虚拟卡509的种类等。更详细来说，设备插件513收集并上报物理卡508卡的资源，上报时每一种资源的数量均为物理卡508的数量乘以最多可切分的虚拟卡509的数量。如前所述，在此实施例中，每个业务节点502包括4张物理卡508(第一物理卡、第二物理卡、第三物理卡、第四物理卡)，而每张物理卡508实际可以被切分成1、2或4个虚拟卡509，因此上报的状态信息如表一所示。

表1

kubelet 510将状态信息发送给主节点501的kube-apiserver 503。

在步骤602中，接收来自多个物理卡的状态信息。主节点501的kube-apiserver503接收表1的状态信息，暂存在ETCD 504中。

在步骤603中，根据状态信息及容器所需的虚拟卡资源，选择特定物理卡，特定物理卡为多个物理卡508至少其中之一。首先，kube-apiserver 503接收到请求虚拟卡资源的pod，在pod的定义中记录有容器需要的切分粒度的虚拟卡资源种类以及所需数量。kube-scheduler 506包括调度扩展器，在接收到使用虚拟卡资源的pod的调度请求后，kube-scheduler 506将调度任务委派给调度扩展器。调度扩展器执行如图7所示的流程。

在步骤701中，调度扩展器自ETCD 504中取得节点集群内的pod与节点信息，根据现有节点信息创建缓存，节点信息包含各业务节点502上所有物理卡508的信息，例如所有占用其资源的pod信息。更详细来说，节点信息为物理卡508上有哪些资源已被占用了，包括占用每个节点上的卡的pod、pod所占用的虚拟卡类型及ID、虚拟卡对应的物理卡ID等。调度扩展器也自ETCD 504中取得节点集群内的状态信息。

在步骤702中，调度扩展器发起一个控制器协程“watch”，以监视kubernetes的资源动态，kubernetes所提供的watch功能是建立在对ETCD 504的监控上，当ETCD 504的关键数值出现变化时，watch协程会直接更新缓存信息，使得调度扩展器可以实时根据最新的缓存信息进行调度。

在步骤703中，调度扩展器进入预选阶段，根据节点信息和状态信息，即上限值、可选择虚拟卡种类及被占用的虚拟卡数量等信息，自多个物理卡508中预选符合虚拟卡种类及数量的预选物理卡508。

更详细来说，当调度扩展器接收到kube-scheduler 506的预选请求时，调度扩展器根据缓存里的信息汇总出每个节点上每张可分配的卡的一系列信息，这些信息包括物理卡508是否被pod占用、被切成了几份、哪些虚拟卡没有被占用等等。调度扩展器继续根据pod请求的虚拟卡资源类型及其数量，比较得出哪些物理卡508具有足够的资源可供pod使用，并将预选结果返回给kube-scheduler 506。

在步骤704中，调度扩展器进入优选阶段，根据预设条件，自预选物理卡中指定特定物理卡。当调度扩展器接收到kube-scheduler 506的优选请求时，对于kube-scheduler506给出的每个业务节点502，根据缓存中的信息设定预设条件，再基于预设条件选择合适的物理卡508。本发明不限制预设条件的规则及数量，此实施例可以设定预设条件为已被占用虚拟卡509的物理卡508优先于闲置的物理卡508，如果存在多个符合条件的物理卡508，进一步设定预设条件为被占用较多虚拟卡509的物理卡508优先于被占用较少虚拟卡509的物理卡508。

换言之，此实施例优先选择被占用较多虚拟卡509的物理卡508，其次选择被占用较少虚拟卡509的物理卡508，最后才考虑闲置的物理卡508。这样的安排能够充分利用已被占用虚拟卡509的物理卡508，在满足pod需求的前提下，使得剩余较少虚拟卡509的物理卡508优先被选择，不仅让物理卡508的使用率尽可能接近满载，还可以保留较为完整的物理卡508，供后续需要大量的虚拟卡资源的pod使用。

接着执行步骤604，根据虚拟卡资源，规划特定物理卡508的虚拟化方式。kube-scheduler 506发送绑定特定物理卡508的请求给调度扩展器，调度扩展器根据pod的需求规划虚拟化方式，并为pod分配虚拟卡509，最后将分配信息写入pod annotation中，将pod绑定到特定物理卡上。更详细来说，调度扩展器向kube-apiserver 503发送请求更新ETCD504内的pod信息，由于kubelet 510也会利用控制器协程watch实时掌握ETCD 504内的信息，所以kubelet 510可以得知某个pod调度到了自己管理的业务节点502上，从而进行下一步操作，调度扩展器也利用控制器协程watch获得ETCD 504更新的信息，同步更新自己的缓存。pod annotation是管理者可以任意定义的附加信息，以便于外部工具进行查找，用podannotation来记录的信息包括：时间戳、release ID号、PR号、镜像hash值、docker寄存器地址等。

在步骤605中，获得虚拟化方式。kubelet 510利用控制器协程watch从podannotation里获得了pod的分配信息，分配信息包括了分配给pod的虚拟卡的种类、虚拟卡的ID和对应物理卡的ID等。

在步骤606中，根据虚拟化方式，发送指定虚拟卡的信息给设备插件513。kubelet510根据虚拟化方式，发送指定虚拟卡的信息给设备插件513。

在步骤607中，根据指定虚拟卡的信息，虚拟化特定物理卡。设备插件513接收到指定虚拟卡的信息后，当相应的pod被调度到物理卡508上时，根据pod annotation中的物理卡ID检查需要分配的卡是否已被切分成需要的资源类型。若没有，则进行切分，并根据虚拟卡ID将指定的虚拟卡资源挂载到容器中。

在步骤608中，将指定虚拟卡分配给容器使用。

以下将以1个实际的例子阐述图6及图7的流程。为方便说明，假设一个简化的云计算中心包括1个主节点及1个业务节点。如图8所示，业务节点包括4个物理卡：第一物理卡801、第二物理卡802、第三物理卡803及第四物理卡804。每个物理卡均具有板卡400的结构，板卡400上的芯片402包括图1所示的片上系统106，即每个物理卡内有计算装置130、视频编解码装置132、JPEG编解码装置134及存储装置136，在此例子中物理卡最多可以被拆分成4张虚拟卡，因此计算装置130最多可以被拆分成4个虚拟计算装置142，视频编解码装置132最多可以被拆分成4个虚拟视频编解码装置144，JPEG编解码装置134最多可以被拆分成4个虚拟JPEG编解码装置146，存储装置136最多可以被拆分成4个虚拟存储装置148，虚拟卡的种类有全卡、半卡及

卡。

图8中的柱形代表可以被拆分的物理卡，而网底方格代表已被切分成虚拟卡且被占用。如图所示，第一物理卡801的计算装置已被占用的2个虚拟

卡，视频编解码装置已被占用的1个虚拟全卡，JPEG编解码装置闲置，存储装置已被占用的2个虚拟

卡；第二物理卡802的计算装置已被占用的1个虚拟半卡及1个虚拟

卡，视频编解码装置已被占用的2个虚拟

卡，JPEG编解码装置已被占用的1个虚拟半卡，存储装置已被占用的1个虚拟

卡；第三物理卡803的计算装置已被占用的1个虚拟

卡，视频编解码装置、JPEG编解码装置、存储装置闲置；第四物理卡804的计算装置、视频编解码装置、JPEG编解码装置、存储装置均闲置。

在步骤601中，业务节点的设备插件将自己所拥有的物理卡的状态信息发送给主节点的kube-apiserver，业务节点上报的状态信息如表1。在步骤602中，主节点的kube-apiserver接收这些状态信息，暂存在ETCD中。在步骤603中，根据状态信息及容器所需的虚拟卡资源，选择特定物理卡。假设当下的pod所需的虚拟卡资源为虚拟视频编解码装置半卡1张及虚拟JPEG编解码装置

卡1张。首先，kube-apiserver接收到请求虚拟卡资源的pod，在pod的定义中记录有前述虚拟卡资源。kube-scheduler在接收到使用虚拟卡资源的pod的调度请求后，将调度任务委派给调度扩展器。

接着执行步骤701，调度扩展器自ETCD中取得pod与节点信息，根据现有节点信息创建缓存。在步骤702中，调度扩展器发起一个控制器协程watch。在步骤703中，调度扩展器进入预选阶段，根据节点信息和状态信息，预选符合虚拟卡种类及数量的预选物理卡。由于当下的容器所需的虚拟卡资源为虚拟视频编解码装置半卡1张及虚拟JPEG编解码装置

卡1张，能符合需求的有第二物理卡802、第三物理卡803与第四物理卡804，其中第二物理卡802尚有可利用的虚拟视频编解码装置半卡1张及虚拟JPEG编解码装置半卡1张，第三物理卡803和物理卡804尚有可利用的虚拟视频编解码装置全卡1张及虚拟JPEG编解码装置全卡1张。调度扩展器将预选结果(第二物理卡802、第三物理卡803与第四物理卡804)返回给kube-scheduler。

在步骤704中，调度扩展器进入优选阶段，根据预设条件，自预选物理卡中指定特定物理卡。此实施例设定预设条件为已被占用虚拟卡的物理卡优先于闲置的物理卡，如果有多个符合条件的物理卡，进一步设定预设条件为被占用较多虚拟卡的物理卡优先于被占用较少虚拟卡的物理卡508。由于第二物理卡802与第三物理卡803为已被占用虚拟卡的物理卡，优先于闲置的第四物理卡804，且第二物理卡802相较于物理卡803被占用较多虚拟卡，因此调度扩展器指定第二物理卡802，即特定物理卡为第二物理卡802。

在步骤604中，kube-scheduler发送绑定第二物理卡802的请求给调度扩展器，调度扩展器为pod分配虚拟卡，最后将分配信息写入pod annotation，将pod绑定到第二物理卡802上。在步骤605中，kubelet利用控制器协程watch从pod annotation里获得了pod的分配信息。在步骤606中，kubelet根据虚拟化方式，发送指定虚拟卡的信息给设备插件。在步骤607中，设备插件接收指定虚拟卡的信息后，根据pod annotation中的分配信息检查需要分配的卡是否被切分成需要的资源类型，物理卡802的虚拟视频编解码装置已是1张半卡，无需拆分，而物理卡802的虚拟JPEG编解码装置为1张半卡，故虚拟化成

卡2张，其中一张

卡供pod使用，并将指定的虚拟卡资源(虚拟视频编解码装置1张半卡与虚拟JPEG编解码装置1张

卡)挂载到容器中。在步骤608中，将指定虚拟卡分配给容器使用。

图9示出分配后各物理卡被占用的情况，其中黑色方格为本次虚拟化并分配使用的虚拟卡。

前述说明虽以单个业务节点为例，本领域技术人员可以轻易地推及一个节点集群中包括多个业务节点的应用场景，故不赘述。

此实施例实现对kubernetes集群中人工智能计算卡的动态切分，避免了手动去停止插件、切分卡、重启插件的困难，使得所有用户在未察觉的情况下便完成动态虚拟化的作业。再者，此实施例根据实际pod需求进行指定粒度的虚拟卡资源调度，优先调度已经被切分的卡，提高资源的利用率，减少资源浪费。

在前述的实施例中，每个物理卡中的计算装置130、视频编解码装置132、JPEG编解码装置134及存储装置136可以独立的进行拆分，像是如图9所示一般，将物理卡802的虚拟视频编解码装置拆分成1张半卡，但同一张物理卡802的虚拟JPEG编解码装置却虚拟化成

卡。本发明的另一个实施例为节省虚拟化的操作，可以设定为每张物理卡的各装置同步拆分，且虚拟卡数量亦相同。以下同样基于图6及图7的流程进行说明。

在步骤601中，业务节点的设备插件将自己所拥有的物理卡的状态信息发送给主节点的kube-apiserver。在步骤602中，主节点的kube-apiserver接收这些状态信息，暂存在ETCD中。在步骤603中，根据状态信息及容器所需的虚拟卡资源，选择特定物理卡。

接着执行步骤701，调度扩展器自ETCD中取得pod与节点信息，根据现有节点信息创建缓存。在步骤702中，调度扩展器发起一个控制器协程watch。在步骤703中，调度扩展器进入预选阶段，根据节点信息和状态信息，预选符合虚拟卡种类及数量的预选物理卡。在此实施例中，调度扩展器不单单判断当下的容器所需的虚拟卡资源，还会考虑同一张物理卡上其他虚拟卡资源。举例来说，假设当下的容器需要虚拟视频编解码装置半卡1张，调度扩展器会评估有哪些物理卡除了能提供虚拟视频编解码装置半卡1张外，亦能提供虚拟计算装置半卡1张、虚拟JPEG编解码装置半卡1张及虚拟存储装置半卡1张。在步骤704中，调度扩展器进入优选阶段，根据预设条件，自预选物理卡中指定特定物理卡。此实施例的预设条件可以和前述实施例相同，故不赘述。

在步骤604中，kube-scheduler发送绑定特定物理卡的请求给调度扩展器，调度扩展器为pod分配虚拟卡，最后将分配信息写入pod annotation，将pod绑定到特定物理卡上。在步骤605中，kubelet利用控制器协程watch从pod annotation里获得了pod的分配信息。在步骤606中，kubelet根据虚拟化方式，发送指定虚拟卡的信息给设备插件，在此实施例中，指定虚拟卡的信息为虚拟视频编解码装置、虚拟计算装置、虚拟JPEG编解码装置及虚拟存储装置各半卡1张。在步骤607中，设备插件接收指定虚拟卡的信息后，根据podannotation中的分配信息检查需要分配的卡是否被切分成需要的资源类型，也就是虚拟视频编解码装置、虚拟计算装置、虚拟JPEG编解码装置及虚拟存储装置均被切分为半卡1张。在步骤608中，将指定虚拟卡分配给容器使用。

前述多个实施例均以选择单一物理卡进行虚拟化为例，但本发明不以此为限，本发明的另一个实施例可以根据pod的需求，动态虚拟化且分配多张物理卡的资源给容器，特别是当pod所需资源量大，或者是各物理卡被占用的资源过多时，单一物理卡无法支持pod的需求，故整合多张物理卡的资源进行调配。本领域技术人员可以在没有创造性努力的前提下，从前述各实施例的披露轻易推及动态虚拟化多张物理卡的技术方案，在此不赘述。

本发明另一个实施例为一种计算机可读存储介质，其上存储有动态虚拟化多个物理卡的计算机程序代码，当所述计算机程序代码由服务器运行时，服务器包括处理器和存储器，存储器中存有前述的计算机程序代码，处理器运行存储器中的计算机程序代码。在一些实现场景中，上述集成的单元可以采用软件程序模块的形式来实现。如果以软件程序模块的形式实现并作为独立的产品销售或使用时，所述集成的单元可以存储在计算机可读取存储器中。基于此，当本发明的方案以软件产品(例如计算机可读存储介质)的形式体现时，该软件产品可以存储在存储器中，其可以包括若干指令用以使得计算机设备(例如个人计算机、服务器或者网络设备等)执行本发明实施例所述方法的部分或全部步骤。前述的存储器可以包括但不限于U盘、闪存盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本发明提供一种切分物理卡并按需调度容器的方案，动态地根据实际容器应用的需要，将业务节点上的卡进行切分，为容器应用提供合适切分粒度的虚拟卡，并优先调度被切分的卡，以善用资源。

根据不同的应用场景，本发明的电子设备或装置可以包括服务器、云端服务器、服务器集群、数据处理装置、机器人、电脑、打印机、扫描仪、平板电脑、智能终端、PC设备、物联网终端、移动终端、手机、行车记录仪、导航仪、传感器、摄像头、相机、摄像机、投影仪、手表、耳机、移动存储、可穿戴设备、视觉终端、自动驾驶终端、交通工具、家用电器、和/或医疗设备。所述交通工具包括飞机、轮船和/或车辆；所述家用电器包括电视、空调、微波炉、冰箱、电饭煲、加湿器、洗衣机、电灯、燃气灶、油烟机；所述医疗设备包括核磁共振仪、B超仪和/或心电图仪。本发明的电子设备或装置还可以被应用于互联网、物联网、数据中心、能源、交通、公共管理、制造、教育、电网、电信、金融、零售、工地、医疗等领域。进一步，本发明的电子设备或装置还可以用于云端、边缘端、终端等与人工智能、大数据和/或云计算相关的应用场景中。在一个或多个实施例中，根据本发明方案的算力高的电子设备或装置可以应用于云端设备(例如云端服务器)，而功耗小的电子设备或装置可以应用于终端设备和/或边缘端设备(例如智能手机或摄像头)。在一个或多个实施例中，云端设备的硬件信息和终端设备和/或边缘端设备的硬件信息相互兼容，从而可以根据终端设备和/或边缘端设备的硬件信息，从云端设备的硬件资源中匹配出合适的硬件资源来模拟终端设备和/或边缘端设备的硬件资源，以便完成端云一体或云边端一体的统一管理、调度和协同工作。

需要说明的是，为了简明的目的，本发明将一些方法及其实施例表述为一系列的动作及其组合，但是本领域技术人员可以理解本发明的方案并不受所描述的动作的顺序限制。因此，依据本发明的公开或教导，本领域技术人员可以理解其中的某些步骤可以采用其他顺序来执行或者同时执行。进一步，本领域技术人员可以理解本发明所描述的实施例可以视为可选实施例，即其中所涉及的动作或模块对于本发明某个或某些方案的实现并不一定是必需的。另外，根据方案的不同，本发明对一些实施例的描述也各有侧重。鉴于此，本领域技术人员可以理解本发明某个实施例中没有详述的部分，也可以参见其他实施例的相关描述。

在具体实现方面，基于本发明的公开和教导，本领域技术人员可以理解本发明所公开的若干实施例也可以通过本文未公开的其他方式来实现。例如，就前文所述的电子设备或装置实施例中的各个单元来说，本文在考虑了逻辑功能的基础上对其进行拆分，而实际实现时也可以有另外的拆分方式。又例如，可以将多个单元或组件结合或者集成到另一个系统，或者对单元或组件中的一些特征或功能进行选择性地禁用。就不同单元或组件之间的连接关系而言，前文结合附图所讨论的连接可以是单元或组件之间的直接或间接耦合。在一些场景中，前述的直接或间接耦合涉及利用接口的通信连接，其中通信接口可以支持电性、光学、声学、磁性或其它形式的信号传输。

在本发明中，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元示出的部件可以是或者也可以不是物理单元。前述部件或单元可以位于同一位置或者分布到多个网络单元上。另外，根据实际的需要，可以选择其中的部分或者全部单元来实现本发明实施例所述方案的目的。另外，在一些场景中，本发明实施例中的多个单元可以集成于一个单元中或者各个单元物理上单独存在。

在另外一些实现场景中，上述集成的单元也可以采用硬件的形式实现，即为具体的硬件电路，其可以包括数字电路和/或模拟电路等。电路的硬件结构的物理实现可以包括但不限于物理器件，而物理器件可以包括但不限于晶体管或忆阻器等器件。鉴于此，本文所述的各类装置(例如计算装置或其他处理装置)可以通过适当的硬件处理器来实现，例如中央处理器、GPU、FPGA、DSP和ASIC等。进一步，前述的所述存储单元或存储装置可以是任意适当的存储介质(包括磁存储介质或磁光存储介质等)，其例如可以是可变电阻式存储器(Resistive Random Access Memory，RRAM)、动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)、静态随机存取存储器(Static Random Access Memory，SRAM)、增强动态随机存取存储器(Enhanced Dynamic Random Access Memory，EDRAM)、高带宽存储器(High Bandwidth Memory，HBM)、混合存储器立方体(Hybrid Memory Cube，HMC)、ROM和RAM等。

依据以下条款可更好地理解前述内容：

条款A1、一种动态虚拟化集群上的多个物理卡的方法，所述多个物理卡设置于业务节点上，所述方法包括：接收来自所述多个物理卡的状态信息；根据所述状态信息及容器所需的虚拟卡资源，选择特定物理卡，所述特定物理卡为所述多个物理卡至少其中之一；以及根据所述虚拟卡资源，规划所述特定物理卡的虚拟化方式。

条款A2、根据条款A1所述的方法，其中所述状态信息包括每个物理卡切分成虚拟卡的上限值。

条款A3、根据条款A2所述的方法，其中所述状态信息还包括每个物理卡的可选择虚拟卡种类。

条款A4、根据条款A3所述的方法，其中所述虚拟卡资源包括虚拟卡种类及数量。

条款A5、根据条款A4所述的方法，其中所述选择步骤包括：根据所述上限值、所述可选择虚拟卡种类及被占用的虚拟卡数量，自所述多个物理卡中预选符合所述虚拟卡种类及数量的预选物理卡。

条款A6、根据条款A5所述的方法，其中所述选择步骤还包括：根据预设条件，自所述预选物理卡中指定所述特定物理卡。

条款A7、根据条款A6所述的方法，其中所述预设条件为已被占用虚拟卡的物理卡优先于闲置的物理卡。

条款A8、根据条款A6所述的方法，其中所述预设条件为被占用较多虚拟卡的物理卡优先于被占用较少虚拟卡的物理卡。

条款A9、根据条款A1所述的方法，其中所述集群包括管理节点，所述管理节点载有kubernetes，所述接收步骤是由kubernetes中的kube-apiserver所执行。

条款A10、根据条款A9所述的方法，其中所述选择步骤是由kubernetes中的调度器所执行。

条款A11、一种计算机可读存储介质，其上存储有动态虚拟化集群上的多个物理卡的计算机程序代码，当所述计算机程序代码由处理装置运行时，执行条款A1至10任一项所述的方法。

条款A12、一种动态虚拟化集群上的多个物理卡的服务器，包括处理器和存储器，所述存储器中存有计算机可读程序，所述处理器通过运行所述存储器中的程序，以完成条款A1至10任一项所述的方法。

条款A13、一种动态虚拟化服务器上的多个物理卡的方法，包括：发送来自所述多个物理卡的状态信息；获得虚拟化方式；根据所述虚拟化方式，发送指定虚拟卡的信息，所述指定虚拟卡根据所述状态信息及容器所需的虚拟卡资源所选择；根据所述指定虚拟卡的信息，虚拟化特定物理卡，所述特定物理卡为所述多个物理卡至少其中之一；以及将所述指定虚拟卡分配给所述容器使用。

条款A14、根据条款A13所述的方法，其中所述状态信息包括每个物理卡切分成虚拟卡的上限值。

条款A15、根据条款A14所述的方法，其中所述状态信息还包括每个物理卡的可选择虚拟卡种类。

条款A16、根据条款A15所述的方法，其中所述虚拟卡资源包括虚拟卡种类及数量。

条款A17、根据条款A13所述的方法，其中所述物理卡载有kubernetes，所述发送来自所述多个物理卡的状态信息的步骤与所述发送指定虚拟卡的信息的步骤是由kubernetes中的kubelet所执行。

条款A18、根据条款A17所述的方法，其中所述虚拟化步骤与所述分配步骤是由设备插件所执行。

条款A19、一种计算机可读存储介质，其上存储有动态虚拟化服务器上的多个物理卡的计算机程序代码，当所述计算机程序代码由处理装置运行时，执行条款A13至18任一项所述的方法。

条款A20、一种可动态虚拟化的服务器，包括处理器和存储器，所述存储器中存有计算机可读程序，所述处理器通过运行所述存储器中的程序，以完成条款A13至18任一项所述的方法。

以上对本发明实施例进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (20)

1.一种动态虚拟化集群上的多个物理卡的方法，所述多个物理卡设置于业务节点上，所述方法包括：

接收来自所述多个物理卡的状态信息；

根据所述状态信息及容器所需的虚拟卡资源，选择特定物理卡，所述特定物理卡为所述多个物理卡至少其中之一；以及

根据所述虚拟卡资源，规划所述特定物理卡的虚拟化方式。

2.根据权利要求1所述的方法，其中所述状态信息包括每个物理卡切分成虚拟卡的上限值。

3.根据权利要求2所述的方法，其中所述状态信息还包括每个物理卡的可选择虚拟卡种类。

4.根据权利要求3所述的方法，其中所述虚拟卡资源包括虚拟卡种类及数量。

5.根据权利要求4所述的方法，其中所述选择步骤包括：

根据所述上限值、所述可选择虚拟卡种类及被占用的虚拟卡数量，自所述多个物理卡中预选符合所述虚拟卡种类及数量的预选物理卡。

6.根据权利要求5所述的方法，其中所述选择步骤还包括：

根据预设条件，自所述预选物理卡中指定所述特定物理卡。

7.根据权利要求6所述的方法，其中所述预设条件为已被占用虚拟卡的物理卡优先于闲置的物理卡。

8.根据权利要求6所述的方法，其中所述预设条件为被占用较多虚拟卡的物理卡优先于被占用较少虚拟卡的物理卡。

9.根据权利要求1所述的方法，其中所述集群包括管理节点，所述管理节点载有kubernetes，所述接收步骤是由kubernetes中的kube-apiserver所执行。

10.根据权利要求9所述的方法，其中所述选择步骤是由kubernetes中的调度器所执行。

11.一种计算机可读存储介质，其上存储有动态虚拟化集群上的多个物理卡的计算机程序代码，当所述计算机程序代码由处理装置运行时，执行权利要求1至10任一项所述的方法。

12.一种动态虚拟化集群上的多个物理卡的服务器，包括处理器和存储器，所述存储器中存有计算机可读程序，所述处理器通过运行所述存储器中的程序，以完成权利要求1至10任一项所述的方法。

13.一种动态虚拟化服务器上的多个物理卡的方法，包括：

发送来自所述多个物理卡的状态信息；

获得虚拟化方式；

根据所述虚拟化方式，发送指定虚拟卡的信息，所述指定虚拟卡根据所述状态信息及容器所需的虚拟卡资源所选择；

根据所述指定虚拟卡的信息，虚拟化特定物理卡，所述特定物理卡为所述多个物理卡至少其中之一；以及

将所述指定虚拟卡分配给所述容器使用。

14.根据权利要求13所述的方法，其中所述状态信息包括每个物理卡切分成虚拟卡的上限值。

15.根据权利要求14所述的方法，其中所述状态信息还包括每个物理卡的可选择虚拟卡种类。

16.根据权利要求15所述的方法，其中所述虚拟卡资源包括虚拟卡种类及数量。

17.根据权利要求13所述的方法，其中所述物理卡载有kubernetes，所述发送来自所述多个物理卡的状态信息的步骤与所述发送指定虚拟卡的信息的步骤是由kubernetes中的kubelet所执行。

18.根据权利要求17所述的方法，其中所述虚拟化步骤与所述分配步骤是由设备插件所执行。

19.一种计算机可读存储介质，其上存储有动态虚拟化服务器上的多个物理卡的计算机程序代码，当所述计算机程序代码由处理装置运行时，执行权利要求13至18任一项所述的方法。

20.一种可动态虚拟化的服务器，包括处理器和存储器，所述存储器中存有计算机可读程序，所述处理器通过运行所述存储器中的程序，以完成权利要求13至18任一项所述的方法。

Images