CN111443984A - 网络功能虚拟化nvf系统的容器部署方法及装置 - Google Patents

Abstract

本发明提供了一种网络功能虚拟化NVF系统的容器部署方法及装置，该方法包括：获取虚拟网络功能VNF的容器部署请求；根据容器部署请求，确定满足容器的部署条件的候选节点；在候选节点的标牌为白牌的情况下，将候选节点的标牌更改为容器的厂商牌，并将容器部署在候选节点上。本发明实施例通过动态打标，实现不同厂家网元的容器不共节点部署，避免了不同厂家网元互相攻击的情况，且能够实现按网元所需标记节点进行容器部署，提升节点资源池的利用率。

Description

网络功能虚拟化NVF系统的容器部署方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种网络功能虚拟化NVF系统的容器部署方法及装置。

背景技术

网络功能虚拟化(Network Function Virtualized，NFV)实现了网元的虚拟化和云化，随着容器(Pod)技术在互联网和云计算领域的成熟应用，以及电信网元逐步开始实现容器化，在NFV架构下引入容器成为趋势。为了向管理虚机一样管理容器，在NFV中引入容器需要对NFV架构做出一些改动，具体地，在NFV架构中引入容器，其中，容器可以是服务器或虚拟机，要求具备容器引擎等，对应虚拟机则节点管理为虚拟化基础设置管理器(Virtualized Infrastructure Manager，VIM)，对应服务器则节点管理可以为VIM(ironic)或其他方式。针对容器的管理和调度，引入容器集群管理平台。管理和编排系统(Management and Orchestration，MANO)体系支持容器化网元生命周期管理相关的功能、接口、流程等。虚拟网络功能描述(Virtualized Network Function Description，VNFD)所描述的VDU为容器而非虚拟机。

以容器化网元实例化为例，可由虚拟网络功能管理(Virtualized NetworkFunction Management，VNFM)解析VNFD到虚拟化部署单元(Virtualization DeploymentUnit，VDU)，而后通过容器集群管理平台将容器部署到节点，从而完成网元部署。容器集群管理平台可采用主流的kubernetes进行增强实现，即网元容器的调度、部署、管理等功能均由kubernetes实现。其中，Kubernetes包含控制节点(master)和普通节点(node)两类节点：其中普通节点是实际部署和运行容器的节点；控制节点用于运行api服务、容器调度、控制器等若干模块。

容器是一种轻量级隔离技术，隔离原理是通过OS内核的名称域(namespace)来隔离不同容器，不同容器共享节点OS内核，在OS内核层面可能有如下安全隐患：

通过在容器中执行攻击程序，恶意占用节点资源，导致同一节点上的其他容器或节点遭遇拒绝服务(Denial of Service，DoS)；在容器利用内核漏洞发生逃逸，进行提权后控制节点，以及对其他容器构成危险，如窃取其他容器内敏感数据，或访问属于其他容器的资源，或向其他容器注入恶意代码。

网元容器化部署时，如不进行特别干预，容器集群管理平台会根据网元VNFD中的资源描述以及节点状态进行容器部署的调度，同一节点可能存在多厂家网元的容器。基于容器共享节点OS内核的安全隐患，同一节点部署多厂家网元容器时，可能出现厂家容器之间的恶意攻击，并且由于有些厂家网元可能存在跨节点部署，因此安全隐患会扩散到其他节点，从而对整个资源池构成安全风险。

为了避免安全隐患，需要避免将不同厂家的网元容器调度到同一节点上，即同一节点只允许存在同一厂家网元的容器。为实现这个目的，需要提前对节点进行规划标记或分类，并且在VNFD中写好该网元的各个容器应当部署到哪个或者哪类节点上。以kubernetes为例，为了完成节点的标记，目前主要是在Pod的yaml文件中采用如下方式：强制匹配方式，Pod.spec.nodeName用于强制约束将Pod调度到指定的节点上，指定了节点名称的Pod会直接跳过调度逻辑，直接写入Pod列表(list)。强制约束方式，Pod.spec.nodeSelector是通过kubernetes的label-selector机制进行节点选择，由调度策略节点匹配选择(MatchNodeSelector)进行label匹配，调度Pod到目标节点。或者，Pod.spec.affinity.nodeAffinity和nodeSelector类似，通过label进行可调度Node的过滤。综上可以看到，现有技术需要提前对节点进行标记，在部署容器的过程中，根据Pod描述文件中的要求，通过调度选取合适的节点进行容器部署。但对节点的标记需要在准备节点时完成，是静态部署的，这样随着部署网元的动态变化，会出现有些网元厂家占用过多资源，有些网元厂家没有足够资源的情况，资源池的共享不均衡，资源利用率差。

发明内容

本发明提供一种网络功能虚拟化NVF系统的容器部署方法及装置，解决了现有技术中容器静态部署导致的资源池的共享不均衡、资源利用率差的问题。

本发明的实施例提供了一种网络功能虚拟化NVF系统的容器部署方法，包括：

获取虚拟网络功能VNF的容器部署请求；

根据容器部署请求，确定满足容器的部署条件的候选节点；

在候选节点的标牌为白牌的情况下，将候选节点的标牌更改为容器的厂商牌，并将容器部署在候选节点上。

本发明的实施例还提供了一种网络功能虚拟化NVF系统的容器部署装置，包括：

第一获取模块，用于获取虚拟网络功能VNF的容器部署请求；

确定模块，用于根据容器部署请求，确定满足容器的部署条件的候选节点；

第一处理模块，用于在候选节点的标牌为白牌的情况下，将候选节点的标牌更改为容器的厂商牌，并将容器部署在候选节点。

本发明的实施例还提供了一种网元，包括：处理器；与处理器相连接的存储器，以及与处理器相连接的收发机；其中，处理器用于调用并执行存储器中所存储的程序和数据，实现上述的网络功能虚拟化NVF系统的容器部署方法的步骤。

本发明的实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述的网络功能虚拟化NVF系统的容器部署方法的步骤。

本发明的上述技术方案的有益效果是：通过动态打标，实现不同厂家网元的容器不共节点部署，避免了不同厂家网元互相攻击的情况，且能够实现按网元所需标记节点进行容器部署，提升节点资源池的利用率。

附图说明

图1表示本发明实施例网络功能虚拟化NVF系统的容器部署方法的流程示意图；

图2表示本发明实施例NVF系统的架构框图；

图3表示本发明实施例网络功能虚拟化NVF系统的容器部署装置的模块结构示意图；

图4表示本发明实施例的网元框图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。在下面的描述中，提供诸如具体的配置和组件的特定细节仅仅是为了帮助全面理解本发明的实施例。因此，本领域技术人员应该清楚，可以对这里描述的实施例进行各种改变和修改而不脱离本发明的范围和精神。另外，为了清楚和简洁，省略了对已知功能和构造的描述。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。

在本发明的各种实施例中，应理解，下述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

另外，本文中术语“系统”和“网络”在本文中常可互换使用。

在本申请所提供的实施例中，应理解，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

如图1所示，本发明的实施例提供了一种网络功能虚拟化NVF系统的容器部署方法，应用于容器集群管理平台，具体包括以下步骤：

步骤11：获取虚拟网络功能VNF的容器部署请求。

其中，如图2所示，NVF系统包括网络功能虚拟编排器(Network FunctionVirtualized Orchestration，NFVO)210、虚拟网络功能管理VNFM220、容器集群管理平台230、管理节点240、虚拟网络功能VNF250等。其中，NFVO接收到VNF的实例化请求时，请求VNFM实例化该VNF。其中该实例化请求中携带有VNFD，VNFM解析该VNFD，得到VNF实例化所需容器及其部署条件(或称为部署要求)，要求容器集群管理平台完成容器部署，即向容器集群管理平台发送VNF的容器部署请求。其中，该容器部署请求中至少包括指示部署条件的信息。

步骤12：根据容器部署请求，确定满足容器的部署条件的候选节点。

容器集群管理平台根据获取到的容器部署请求，根据部署要求对节点进行筛选和排序，得到最合适的候选节点。可选地，容器集群管理平台可以包括：数据库、应用程序编程接口-服务(Application Programming Interface-server，API-server)、容器编排管理平台-调度(kube-scheduler)等功能，其中，kube-scheduler监听到API-server上有要新创建的Pod，将新创建的Pod添加到调度队列。kube-scheduler根据新创建Pod的部署要求，对节点进行筛选和排序，得到最适合的候选节点。如解析容器部署文件(Pod.yaml)，以调度最合适的候选节点。其中，该候选节点的标牌(NodeLabel)可能为：白牌(WhiteLabel)、新创建的Pod的厂商牌或其他厂商牌。

步骤13：在候选节点的标牌为白牌的情况下，将候选节点的标牌更改为容器的厂商牌，并将容器部署在候选节点上。

假设新创建Pod的厂商为厂商A，那么当NodeLabel为白牌时，kube-scheduler按节点的亲和性部署要求(nodeAffinity)对应的强匹配规则，将节点信息中的NodeLabel改为Pod.yaml文件中的厂商A(VendorA)。kube-scheduler调用API-server的捆绑(Bind)接口，将新创建的Pod与该候选节点进行绑定，此时节点信息中NodeLabel更新为VendorA。在将新创建的Pod与候选节点绑定之后，API-server更新数据库中节点信息，更新容器与节点的绑定信息。

以上介绍了候选节点为白牌的情况，若候选节点的标牌为与容器厂商牌不同的其他厂商牌，则确定部署失败。在步骤12之后还包括：在候选节点的标牌为容器的厂商牌的情况下，将容器部署到候选节点。假设新创建Pod的厂商为厂商A，那么当NodeLabel为VendorA时，kube-scheduler调用API-server的捆绑(Bind)接口，将新创建的Pod与该候选节点进行绑定。在将新创建的Pod与候选节点绑定之后，API-server更新数据库中节点信息，更新容器与节点的绑定信息。

其中，候选节点可以包括部署功能(kubelet)和容器功能，API-server将Pod部署要求发给候选节点上的kubelet，携带新的NodeLabel，即VendorA；kubelet创建Pod前先检查NodeLabel，若与本节点不同，则调用容器编排管理平台操作指令(如kubectl指令)更新，将NodeLabel由WhiteLabel改为VendorA。然后kubelet再执行Pod的创建。

可选地，在本发明实施例中，步骤11之前还包括：对NVF系统中的所有节点进行初始化。其中，对NVF系统中的所有节点进行初始化的步骤包括：将NVF系统中的节点的标牌初始化为白牌。也就是说，本发明实施例中，容器集群管理平台在准备节点资源池时，初将节点全部标记为白牌。在网元VNFD的Pod描述中要求容器可部署在标记为白牌或各自厂商牌的节点中。可选地，准备节点资源时，容器集群管理平台无需提前将NodeLabel按厂家设置，将全部节点的标牌设置为WhiteLabel。在所有支持容器部署的节点(kubernetes node)上使用kubectl指令对节点添加标记，可参照以下方式对每个节点进行初始化：

#标记规则：kubectl label nodes<node-name><label-key>＝<label-value>

kubectl label nodes k8s.node1NodeLabel＝WhiteLabel

#确认标记

root@k8s.master1:～#kubectl get nodes k8s.node1--show-labels

NAME STATUS AGE LABELS

k8s.node1Ready 29d NodeLabel＝WhiteLabel,kubernetes.io/hostname＝k8s.node1

可选地，步骤12包括：根据容器部署请求，按照预设匹配规则，确定满足容器的部署条件的候选节点。其中，预设匹配规则为调度匹配规则，包括但不限于强匹配规则、弱匹配规则和兼容性条件(如Pod部署条件)等。

进一步地，按照预设匹配规则，确定满足容器的部署条件的候选节点的步骤包括：按照第一匹配规则，在NVF系统的所有节点中筛选出满足容器的部署条件的候选节点集合，其中，第一匹配规则为容器只能部署在标牌为容器的厂商牌或白牌的节点上；按照第二匹配规则，在候选节点集合中确定容器的候选节点，其中，第二匹配规则为容器优先部署在标牌为容器的厂商牌的节点上。

其中，第一匹配规则为强匹配规则，第二匹配规则为弱匹配规则。在Pod部署描述中，明确Pod只能部署在Node label为厂家label或白牌的Node上，这是Pod部署的强制性匹配规则，必须满足。具体到kubernetes中，可在Pod的yaml文件中，采用nodeAffinity属性(Pod.spec.affinity.nodeAffinity)中的强匹配(requiredDuringSchedulingIgnoredDuringExecution或requiredDuringSchedulingRequiredDuringExecution)，在匹配规则(matchExpressions)中，关键字(key)和权重(values)的值表示Pod必须被部署到NodeLabel＝VendorA或者WhiteLabel的节点上。其中，在采用requiredDuringSchedulingIgnoredDuringExecution进行强制匹配时，如果Node label发生变化，运行中Pod不被驱逐出Node。或者，采用requiredDuringSchedulingRequiredDuringExecutio进行强制匹配时，如果Node label发生变化，运行中Pod立即被驱逐出Node。也就是说，若Node的NodeLabel为非WhiteLabel(假设VendorX)，那么该节点则只允许部署厂家X网元的容器(只要是厂家X就行，不需要是同一类网元)。若Node的NodeLabel为WhiteLabel，则所有厂家网元均可部署在上面，并将NodeLabel改为厂家Label。

相应地，在Pod部署描述中，明确Pod优先部署在Node label为厂家label的Node上。具体到kubernetes中，可在Pod的yaml文件中，采用nodeAffinity属性中的若匹配(preferredDuringSchedulingIgnoredDuringExecution或preferredDuringSchedulingRequiredDuringExecution)，在matchExpressions中，key和values的值表示Pod可以优先被部署到NodeLabel＝VendorA的Node上。

其中，本发明实施例中Pod的部署条件部署条件用于指示容器的部署需求，部署条件包括：容器的资源(如CPU、内存等资源)需求和/或亲和性需求。假设厂家A的VNF1由两个Pod组成，VendorA-VNF1两个Pod的部署过程如下：根据VNFD的解析，先启动Pod1的部署，kube-scheduler根据Node情况以及Pod其他部署策略要求(如cpu、内存、硬盘等要求，以及Pod亲和性要求等)，将Pod1调度到Node1上，并将Node1的NodeLabel从WhiteLabel改为VendorA。然后启动Pod2的部署，假设Pod其他部署要求包括Pod2与Pod1反亲和(或Node1不符合Pod2的cpu、内存等要求)，即使根据第一匹配规则和第二匹配规则应当优先将Pod2部署在NodeLabel＝VendorA的节点上(即Node1)，由于要与Pod其他部署要求兼容，Pod2无法部署到Node1，而是根据其他部署要求部署到其他Node，假设为Node2满足要求，Pod2部署到Node2过程中，将Node2的NodeLabel从WhiteLabel改为VendorA。这样，VendorA-VNF1的两个Pod部署完毕，资源池部署厂家A-VNF1后状态：Node1和Node2的标记均动态改为VendorA，后续只能部署厂家A的网元容器。

以上介绍了节点标牌初始化、容器动态部署和节点动态打标的实施例，下面将进一步介绍容器删除和动态去标的过程。该方法还包括：获取删除目标容器的容器删除请求；根据删除请求，将目标容器从目标节点上删除。其中，NFVO接收到终止VNF的指令时，请求VNFM终止该VNF。VNFM执行终止该VNF的任务时，向容器集群管理平台发送删除容器的容器删除请求，将目标容器从该节点上删除。

进一步地，根据删除请求，将目标容器从目标节点上删除的步骤包括：检测目标容器是否为目标节点上的最后一个容器；若是，则删除目标容器，并将目标节点的标牌更改为白牌。容器集群管理平台的API-server检查数据库，判断被删除的Pod是否为所在节点的最后一个Pod，若是则将该节点信息中的NodeLabel从厂商牌(如VendorA)改为白牌。若被删除的Pod不是所在节点最后一个容器，则不更改该节点的NodeLabel信息。具体地，API-server将Pod删除请求发给对应节点上的kubelet，其中删除请求中携带有NodeLabel。kubelet判断删除请求中NodeLabel与本节点NodeLabel是否不同，若不同则用kubectl指令更新NodeLabel，即由VendorA改为WhiteLabel。最后，kubelet再执行Pod删除。

也就是说，当节点上最后一个容器被删除时，动态地将该节点的标牌更改为白牌，从而该节点可以在后续流程中被其他厂家网元用来部署容器，提升节点资源池的利用率。

本发明实施例的NVF系统的容器部署方法中，在节点资源池准备阶段，无需对节点标记厂家信息，而是全部标记为白牌。在容器部署过程中，先进行容器的调度，确定调度好的节点后，对该节点的标记进行修改，从白牌改为厂家标记，而后再进行实际的容器部署。在删除容器时，若该容器为节点最后的容器，则先将该节点标记从厂家改为白牌，而后在删除容器；否则删除容器前不更改节点标记。

本发明实施例的网络功能虚拟化NVF系统的容器部署方法中，通过动态打标，实现不同厂家网元的容器不共节点部署，避免了不同厂家网元互相攻击的情况，且能够实现按网元所需标记节点进行容器部署，提升节点资源池的利用率。

以上实施例分别就本发明的网络功能虚拟化NVF系统的容器部署方法做出介绍，下面本实施例将结合附图对其对应的装置做进一步说明。

具体地，如图3所示，本发明实施例的网络功能虚拟化NVF系统的容器部署装置300，包括以下功能模块：

第一获取模块310，用于获取虚拟网络功能VNF的容器部署请求；

确定模块320，用于根据容器部署请求，确定满足容器的部署条件的候选节点；

第一处理模块330，用于在候选节点的标牌为白牌的情况下，将候选节点的标牌更改为容器的厂商牌，并将容器部署在候选节点上。

可选地，网络功能虚拟化NVF系统的容器部署装置300还包括：

第二处理模块，用于在候选节点的标牌为容器的厂商牌的情况下，将容器部署到候选节点。

可选地，该网络功能虚拟化NVF系统的容器部署装置300还包括：

初始化模块，用于对NVF系统中的所有节点进行初始化。

其中，初始化模块包括：

初始化子模块，用于将NVF系统中的所有节点的标牌初始化为白牌。

其中，确定模块320包括：

确定子模块，用于根据容器部署请求，按照预设匹配规则，确定满足容器的部署条件的候选节点。

其中，确定子模块包括：

筛选单元，用于按照第一匹配规则，在NVF系统的所有节点中筛选出满足容器的部署条件的候选节点集合，其中，第一匹配规则为容器只能部署在标牌为容器的厂商牌或白牌的节点上；

确定单元，用于按照第二匹配规则，在候选节点集合中确定容器的候选节点，其中，第二匹配规则为容器优先部署在标牌为容器的厂商牌的节点上。

其中，部署条件用于指示容器的部署需求，部署条件包括：容器的资源需求和/或亲和性需求。

可选地，该网络功能虚拟化NVF系统的容器部署装置300还包括：

第二获取模块，用于获取删除目标容器的容器删除请求；

删除模块，用于根据删除请求，将目标容器从目标节点上删除。

其中，删除模块包括：

检测子模块，用于检测目标容器是否为目标节点上的最后一个容器；

删除子模块，用于若是，则删除目标容器，并将目标节点的标牌更改为白牌。

本发明的装置实施例是与上述方法的实施例对应的，上述方法实施例中的所有实现手段均适用于该装置的实施例中，也能达到相同的技术效果。该网络功能虚拟化NVF系统的容器部署装置，通过动态打标，实现不同厂家网元的容器不共节点部署，避免了不同厂家网元互相攻击的情况，且能够实现按网元所需标记节点进行容器部署，提升节点资源池的利用率。

为了更好的实现上述目的，如图4所示，本发明实施例还提供了一种网元，该网元包括：处理器400；通过总线接口与所述处理器400相连接的存储器420，以及通过总线接口与处理器400相连接的收发机410；所述存储器420用于存储所述处理器在执行操作时所使用的程序和数据；通过所述收发机410发送数据信息或者导频，还通过所述收发机410接收上行控制信道；当处理器400调用并执行所述存储器420中所存储的程序和数据时，实现如下的功能：

处理器400用于读取存储器420中的程序，执行下列过程：获取虚拟网络功能VNF的容器部署请求；根据容器部署请求，确定满足容器的部署条件的候选节点；在候选节点的标牌为白牌的情况下，将候选节点的标牌更改为容器的厂商牌，并将容器部署在候选节点上。

收发机410，用于在处理器400的控制下接收和发送数据。

其中，在图4中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器400代表的一个或多个处理器和存储器420代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机410可以是多个元件，即包括发送机和收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器400负责管理总线架构和通常的处理，存储器420可以存储处理器400在执行操作时所使用的数据。

本领域技术人员可以理解，实现上述实施例的全部或者部分步骤可以通过硬件来完成，也可以通过计算机程序来指示相关的硬件来完成，所述计算机程序包括执行上述方法的部分或者全部步骤的指令；且该计算机程序可以存储于一可读存储介质中，存储介质可以是任何形式的存储介质。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述网络功能虚拟化NVF系统的容器部署方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等。

此外，需要指出的是，在本发明的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本发明的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行，某些步骤可以并行或彼此独立地执行。对本领域的普通技术人员而言，能够理解本发明的方法和装置的全部或者任何步骤或者部件，可以在任何计算装置(包括处理器、存储介质等)或者计算装置的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本发明的说明的情况下运用他们的基本编程技能就能实现的。

因此，本发明的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。所述计算装置可以是公知的通用装置。因此，本发明的目的也可以仅仅通过提供包含实现所述方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本发明，并且存储有这样的程序产品的存储介质也构成本发明。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。还需要指出的是，在本发明的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本发明的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (20)

1.一种网络功能虚拟化NVF系统的容器部署方法，其特征在于，包括：

获取虚拟网络功能VNF的容器部署请求；

根据所述容器部署请求，确定满足容器的部署条件的候选节点；

在所述候选节点的标牌为白牌的情况下，将所述候选节点的标牌更改为所述容器的厂商牌，并将所述容器部署在所述候选节点上。

2.根据权利要求1所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，根据所述容器部署请求，确定满足容器的部署条件的候选节点的步骤之后，还包括：

在所述候选节点的标牌为所述容器的厂商牌的情况下，将所述容器部署到所述候选节点。

3.根据权利要求1所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，获取虚拟网络功能VNF的容器部署请求的步骤之前，还包括：

对所述NVF系统中的所有节点进行初始化。

4.根据权利要求3所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，对所述NVF系统中的所有节点进行初始化的步骤，包括：

将所述NVF系统中的所有节点的标牌初始化为白牌。

5.根据权利要求1所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，根据所述容器部署请求，确定满足容器的部署条件的候选节点的步骤，包括：

根据所述容器部署请求，按照预设匹配规则，确定满足容器的部署条件的候选节点。

6.根据权利要求5所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，按照预设匹配规则，确定满足容器的部署条件的候选节点的步骤，包括：

按照第一匹配规则，在所述NVF系统的所有节点中筛选出满足容器的部署条件的候选节点集合，其中，所述第一匹配规则为所述容器只能部署在标牌为所述容器的厂商牌或白牌的节点上；

按照第二匹配规则，在所述候选节点集合中确定所述容器的候选节点，其中，所述第二匹配规则为所述容器优先部署在标牌为所述容器的厂商牌的节点上。

7.根据权利要求1或5所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，所述部署条件用于指示所述容器的部署需求，所述部署条件包括：所述容器的资源需求和/或亲和性需求。

8.根据权利要求1所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，将所述容器部署在所述候选节点上的步骤之后，还包括：

获取删除目标容器的容器删除请求；

根据所述删除请求，将所述目标容器从目标节点上删除。

9.根据权利要求8所述的网络功能虚拟化NVF系统的容器部署方法，其特征在于，根据所述删除请求，将所述目标容器从目标节点上删除的步骤，包括：

检测所述目标容器是否为所述目标节点上的最后一个容器；

若是，则删除所述目标容器，并将所述目标节点的标牌更改为白牌。

10.一种网络功能虚拟化NVF系统的容器部署装置，其特征在于，包括：

第一获取模块，用于获取虚拟网络功能VNF的容器部署请求；

确定模块，用于根据所述容器部署请求，确定满足容器的部署条件的候选节点；

第一处理模块，用于在所述候选节点的标牌为白牌的情况下，将所述候选节点的标牌更改为所述容器的厂商牌，并将所述容器部署在所述候选节点上。

11.根据权利要求10所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，还包括：

第二处理模块，用于在所述候选节点的标牌为所述容器的厂商牌的情况下，将所述容器部署到所述候选节点。

12.根据权利要求10所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，还包括：

初始化模块，用于对所述NVF系统中的所有节点进行初始化。

13.根据权利要求12所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，初始化模块包括：

初始化子模块，用于将所述NVF系统中的所有节点的标牌初始化为白牌。

14.根据权利要求10所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，所述确定模块包括：

确定子模块，用于根据所述容器部署请求，按照预设匹配规则，确定满足容器的部署条件的候选节点。

15.根据权利要求14所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，所述确定子模块包括：

筛选单元，用于按照第一匹配规则，在所述NVF系统的所有节点中筛选出满足容器的部署条件的候选节点集合，其中，所述第一匹配规则为所述容器只能部署在标牌为所述容器的厂商牌或白牌的节点上；

确定单元，用于按照第二匹配规则，在所述候选节点集合中确定所述容器的候选节点，其中，所述第二匹配规则为所述容器优先部署在标牌为所述容器的厂商牌的节点上。

16.根据权利要求10或15所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，所述部署条件用于指示所述容器的部署需求，所述部署条件包括：所述容器的资源需求和/或亲和性需求。

17.根据权利要求10所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，还包括：

第二获取模块，用于获取删除目标容器的容器删除请求；

删除模块，用于根据所述删除请求，将所述目标容器从目标节点上删除。

18.根据权利要求17所述的网络功能虚拟化NVF系统的容器部署装置，其特征在于，所述删除模块包括：

检测子模块，用于检测所述目标容器是否为所述目标节点上的最后一个容器；

删除子模块，用于若是，则删除所述目标容器，并将所述目标节点的标牌更改为白牌。

19.一种网元，其特征在于，包括：处理器；与所述处理器相连接的存储器，以及与处理器相连接的收发机；其中，所述处理器用于调用并执行所述存储器中所存储的程序和数据，实现如权利要求1至9任一项所述的网络功能虚拟化NVF系统的容器部署方法的步骤。

20.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至9中任一项所述的网络功能虚拟化NVF系统的容器部署方法的步骤。

Images