管理容器服务的方法和装置与流程

本申请涉及容器服务领域，尤其涉及一种管理容器服务的方法和装置。

背景技术：

网络功能虚拟化(networkfunctionvirtualization,nfv)提供了一种设计、部署和管理网络服务(networkservice，ns)的全新方式，它在通用的服务器、交换机和存储器中将部分电信网络功能的实现进行软件和硬件解耦，因而能够实现ns快速、高效的部署。由于nfv需要大量的虚拟化资源，因此需要高度的软件管理，业界称之为编排。网络功能虚拟化管理与编排(networkfunctionvirtualizationmanagementandorchestrator,nfvmano)是用于管理和协调虚拟化网络功能(virtualnetworkfunction，vnf)和其它软件组件的架构框架。

近年来，随着nfv技术的不断发展，原有的构建在网络功能虚拟化基础设施层(networkfunctionvirtualizationinfrastructure,nfvi)层的虚拟机(virtualmachine,vm)基础上的vnf的呈现形态融入了新的特性，支持云原生(cloudnative)的vnf和融合平台即服务(platformasaservice,paas)的云化架构将成为电信云发展的新趋势。在传统的电信网络功能通过容器化、服务化向云上搬迁，以及新形态的网络功能直接在云上开发交付的进程中，一个无法回避的问题是如何将容器服务的管理功能融合到nfvmano系统的管理框架内。而现有技术还没有一种机制能够实现将容器服务的管理功能融合到nfvmano系统中。

技术实现要素：

本申请提供一种管理容器服务的方法和装置，能够将容器服务以及容器服务的管理功能融合到nfvmano系统中。

第一方面，本申请提供一种管理容器服务的方法，该方法包括：容器服务管理实体接收容器服务的创建请求，创建请求用于请求创建指定的容器服务，创建请求中携带用于管理指定的容器服务的生命周期的第一管理策略；容器服务管理实体响应于创建请求，创建指定的容器服务；容器服务管理实体根据第一管理策略，对指定的容器服务的生命周期进行管理。

这里所说的容器服务对应本申请说明书中的caas(containerasaservice)，容器服务管理实体对应caas管理器。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：容器服务管理实体接收容器服务的删除请求，删除请求用于请求删除指定的容器服务，删除请求中携带指定的容器服务的标识信息；容器服务管理实体根据指定的容器服务的标识信息，删除指定的容器服务。

应理解，容器服务的删除请求必然是在已经创建了容器服务之后的。或者说，只有对于已经存在的容器服务，才有删除这个容器服务的请求。

结合第一方面，在第一方面的某些实现方式中，在中心数据中心部署容器服务以及容器服务的管理功能的情况下，容器服务管理实体接收容器服务的创建请求，包括：容器服务管理实体从虚拟网络功能管理器vnfm接收创建请求；以及，容器服务管理实体接收容器服务的删除请求，包括：容器服务管理实体从vnfm接收删除请求。

结合第一方面，在第一方面的某些实现方式中，在边缘数据中心部署容器服务的管理功能的情况下，容器服务管理实体接收容器服务的创建请求，包括：容器服务管理实体从网络功能虚拟化编排器nfvo接收所述创建请求；以及，容器服务管理实体接收容器服务的删除请求，包括：容器服务管理实体从nfvo接收所述删除请求。

即是说，在中心数据中心部署容器服务的管理功能的情况下，nfvmano系统的nfvo是作为容器服务的管理功能接入nfvmano系统的锚点实体。在边缘数据中心部署容器服务的管理功能的情况下，nfvmano系统的vnfm是作为容器服务的管理功能接入nfvmano系统的锚点实体。

结合第一方面，在第一方面的某些实现方式中，容器服务的管理包括容器应用的生命周期的管理和构建容器服务的容器资源的管理，以及，容器服务管理实体根据第一管理策略，对指定的容器服务的生命周期进行管理，包括：容器服务管理实体根据第一管理策略，对容器应用的生命周期和组成指定的容器服务的容器资源进行管理。

现有的nfvmano系统中对vnf的生命周期的管理和对该vnf所需的虚拟资源的管理分别由vnfm和vim执行，导致了vnf生命周期管理操作完成时间相对较长，无法适应vnf功能进行快速迭代更新的需求。而在本申请实施例中，容器服务的管理包括对封装在容器内的应用的生命周期管理以及对容器资源的管理。并且，容器应用的生命周期管理和容器资源管理由同一个管理实体(caas管理器)来执行，因此可以适应vnf功能快速迭代更新的需求。

第二方面，本申请提供一种管理容器服务的方法，该方法包括：虚拟网络功能管理器vnfm获取用于管理指定的容器化虚拟网络功能vnf的生命周期的第二管理策略；vnfm根据第二管理策略，生成用于管理指定的容器服务的生命周期的第一管理策略，指定的容器化vnf由指定的容器服务构成；vnfm向容器服务管理实体发送第一管理策略，以由容器服务管理实体根据第一管理策略对指定的容器服务的生命周期进行管理。

这里所说的容器服务管理实体对应本申请说明书中的caas管理器，容器服务对应说明书中的caas(containerasaservice)。

另外，第二方面的方法适用于在中心数据中心部署容器服务以及容器服务的管理功能的场景。

结合第二方面，在第二方面的某些实现方式中，第二管理策略不包括容器化vnf的实例化的管理策略，vnfm获取用于管理指定的容器化vnf的生命周期的第二管理策略，包括：vnfm从网络功能虚拟化编排器nfvo或网元管理系统em接收容器化vnf的实例化请求，实例化请求用于请求实例化指定的容器化vnf，其中，实例化请求中携带第二管理策略；vnfm从实例化请求中获取第二管理策略。

结合第二方面，在第二方面的某些实现方式中，vnfm向容器服务管理实体发送第一管理策略，包括：vnfm向容器服务管理实体发送容器服务的创建请求，创建请求用于请求创建指定的容器服务，创建请求中携带第一管理策略。

结合第二方面，在第二方面的某些实现方式中，第二管理策略不包括容器化vnf实例的终结的管理策略，该方法还包括：vnfm从nfvo接收容器化vnf实例的终结请求，终结请求用于请求终结指定的容器化vnf的实例，终结请求中携指定的容器化vnf的实例的标识信息；vnfm响应于终结请求，向容器服务管理实体发送容器服务的删除请求。

第三方面，本申请提供一种管理容器服务的方法，该方法包括：网络功能虚拟化编排器nfvo生成用于管理指定的容器服务的生命周期的第一管理策略，或者，nfvo生成用于管理指定的容器化虚拟网络功能vnf的生命周期的第二管理策略，其中，指定的容器化vnf由指定的容器服务构成；在nfvo生成第一管理策略的情况下，nfvo向容器服务管理实体发送第一管理策略；在nfvo生成第二管理策略的情况下，nfvo向虚拟化网络功能vnfm发送第二管理策略。

这里所说的容器服务对应说明书中的caas(containerasaservice)，容器服务管理实体对应本申请说明书中的caas管理器。

具体地，nfvo生成第二管理策略的情况适用于在中心数据中心部署容器服务以及容器服务的管理功能的场景。而nfvo生成第一管理策略的情况适用于在边缘数据中心部署容器服务以及容器服务的管理功能的场景。即是说，在中心数据中心部署容器服务以及容器服务的管理功能的情况下，nfvo生成上述第二管理策略，并将第二管理策略发送给vnfm。而在边缘数据中心部署容器服务以及容器服务的管理功能的情况下，nfvo生成上述第一管理策略，并直接将第一管理策略发送给容器服务管理实体(caas管理器)。而容器服务以及容器服务的管理功能是部署在中心数据中心还是边缘数据中心，nfvo是能够获知的。例如，在组网的时候，nfvo就可以获知容器服务以及容器服务的管理功能的部署情况，包括具体是部署在中心dc还是部署在边缘dc。

结合第三方面，在第三方面的某些实现方式中，nfvo向容器服务管理实体发送第一管理策略，包括：nfvo向容器服务管理实体发送容器服务的创建请求，创建请求中携带第一管理策略。

结合第三方面，在第三方面的某些实现方式中，该方法还包括：nfvo向容器服务管理实体发送容器服务的删除请求，删除请求用于请求删除指定的容器服务，删除请求中携带指定的容器服务的标识信息。

结合第三方面，在第三方面的某些实现方式中，在nfvo生成第二管理策略的情况下，第二管理策略不包括容器化vnf的实例化的管理策略，nfvo向vnfm发送第二管理策略，包括：nfvo向vnfm发送容器化vnf的实例化请求，实例化请求用于请求实例化指定的容器化vnf，实例化请求中携带第二管理策略。

结合第三方面，在第三方面的某些实现方式中，第二管理策略不包括容器化vnf实例的终结的管理策略，以及，该方法还包括：nfvo向vnfm发送容器化vnf实例的终结请求，终结请求用于请求终结指定的容器化vnf的实例，终结请求中携指定的容器化vnf的实例的标识信息。

第四面，本申请提供一种管理容器服务的装置，用于执行第一方面及其任意可能的实现方式中的方法。具体地，该装置包括执行第一方面及其第一方面任意可能的实现方式的方法的单元。

第五面，本申请提供一种管理容器服务的装置，用于执行第二方面及其任意可能的实现方式中的方法。具体地，该装置包括执行第二方面及其第二方面任意可能的实现方式的方法的单元。

第六面，本申请提供一种管理容器服务的装置，用于执行第三方面及其任意可能的实现方式中的方法。具体地，该装置包括执行第三方面及其第三方面任意可能的实现方式的方法的单元。

第七方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述第一方面或第一方面的任意可能的实现方式中的方法。

第八方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述第二方面或第二方面的任意可能的实现方式中的方法。

第九方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述第三方面或第三方面的任意可能的实现方式中的方法。

第十方面，本申请提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网络设备执行上述第一方面及其第一方面的任意可能的实现方式中的方法。

第十一方面，本申请提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网络设备执行上述第二方面及其第二方面的任意可能的实现方式中的方法。

第十二方面，本申请提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网络设备执行上述第三方面及其第三方面的任意可能的实现方式中的方法。

第十三方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述第一方面及其第一方面的任意可能的实现方式中的方法。

第十四方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述第二方面及其第二方面的任意可能的实现方式中的方法。

第十五方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述第三方面及其第三方面的任意可能的实现方式中的方法。

第十六方面，本申请提供一种网络设备，包括收发器、处理器和存储器。处理器用于控制收发器收发信号，存储器用于存储计算机程序，处理器用于调用并运行存储器中存储的计算机程序，使得网络设备执行第一方面及其第一方面任意可能的实现方式中的方法。

第十七方面，本申请提供一种网络设备，包括收发器、处理器和存储器。处理器用于控制收发器收发信号，存储器用于存储计算机程序，处理器用于调用并运行存储器中存储的计算机程序，使得网络设备执行第二方面及其第二方面任意可能的实现方式中的方法。

第十八方面，本申请提供一种网络设备，包括收发器、处理器和存储器。处理器用于控制收发器收发信号，存储器用于存储计算机程序，处理器用于调用并运行存储器中存储的计算机程序，使得网络设备执行第三方面及其第三方面任意可能的实现方式中的方法。

第十九方面，本申请提供一种管理容器服务的系统，该系统包括第一方面及其第一方面任意可能的实现方式中的容器服务管理实体，第二方面及其第二方面任意可能的实现方式中的vnfm，和/或第三方面及第三方面任意可能的实现方式中的nfvo。

本申请提供的技术方案，通过将nfvmano系统中的vnfm或nfvo作为容器服务的管理功能接入nfvmano系统的锚点实体，无论在中心数据中心或边缘数据中心，都可以实现将容器服务以及容器服务的管理功能融合到nfvmano系统中。

附图说明

图1是nfvmano系统的架构图。

图2是一种容器服务的管理编排系统的架构图。

图3是本申请提出的一种网络架构的示意图。

图4是本申请提供的容器化vnf的组成。

图5是根据本申请提供的管理容器服务的方法创建容器服务的一个示例。

图6是根据本申请提供的管理容器服务的方法创建容器服务的另一个示例。

图7是根据本申请提供的管理容器服务的方法删除容器服务的一个示例。

图8是本申请提出的另一种网络架构的示意图。

图9是本申请提供的容器化移动边缘应用的组成。

图10是根据本申请提供的管理容器服务的方法创建容器服务的一个示例。

图11是根据本申请提供的管理容器服务的方法创建容器服务的另一个示例。

图12是根据本申请提供的管理容器服务的方法删除容器服务的一个示例。

图13是适用于本申请实施例的管理容器服务的装置800的示意性框图。

图14是适用于本申请实施例的管理容器服务的装置900的示意性框图。

图15是适用于本申请实施例的管理容器服务的装置1000的示意性框图。

图16是适用于本申请实施例的管理容器服务的网络设备2000的示意性框图。

图17是适用于本申请实施例的管理容器服务的网络设备3000的示意性框图。

图18是适用于本申请实施例的管理容器服务的网络设备4000的示意性框图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

参见图1，图1是nfvmano系统的架构图。如图1所示，nfvmano有三个主要功能块，分别是nfv编排器、vnf管理器和虚拟基础设施管理器(virtualisedinfrastructuremaneger,vim)。简单来说，nfv编排器可以对服务和资源进行编排，可以控制新的网络服务并将vnf集成到虚拟架构中，nfv编排器还能够验证并授权nfv基础设施的资源请求。vnf管理器能够管理vnf的生命周期。vim能够控制并管理nfv基础设施，包括计算资源、存储资源以及网络资源等。为了是nfvmano行之有效，它必须与现有系统中的应用程序接口(applicationinterface,api)集成，以便跨多个网络域使用多个厂商的技术，同样地，运营商的运营支撑系统(operationsupportsystem,oss)和商务支撑系统(businesssupportsystem,bss)也需要与nfvmano系统实现互操作

为了便于理解，下面对图1中所示的架构中涉及到的各组件的功能进行介绍。

网络功能虚拟化编排器(networkfunctionvirtualizationorchestrator，nfvo)，用于实现对网络服务描述符(networkservicedescriptor，nsd)、虚拟网络功能转发图(virtualnetworkfunctionforwardinggraph，vnffg)的管理及处理，对网络服务的生命周期的管理，以及和虚拟网络功能管理器(virtualnetworkfunctionmanager,vnfm)配合，实现对虚拟网络功能(virtualnetworkfunction,vnf)的生命周期的管理和虚拟资源的全局视图功能。

vnfm：用于实现对vnf的生命周期的管理，包括vnf描述符(vnfdescriptor,vnfd)的管理、vnf的实例化、vnf实例的弹性伸缩(例如，扩容scalingout/up，和/或缩容scalingin/down)、vnf实例的治愈(healing)以及vnf实例的终止。vnfm还支持接收nfvo下发的弹性伸缩(scaling)策略，实现自动化的vnf的弹性伸缩。

虚拟基础设施管理器(virtualisedinfrastructuremanager,vim)：主要负责基础设施层的硬件资源、虚拟化资源的管理(包括，预留和分配)，以及虚拟资源状态的监控和故障上报，面向上层应用提供虚拟化资源池。

运营和商务支撑系统(operationsandbusinesssupportsystems,oss/bss)：指运营商现有的运行维护系统。

网元管理系统(elementmanager,em)：针对vnf执行传统的故障、配置、用户、性能和安全的管理(faultmanagement,configurationmanagement,accountmanagement,performancemanagement,securitymanagement，fcaps)的功能。

虚拟化网络功能(virtualizednetworkfunction,vnf)：对应于传统非虚拟化网络中的物理网络功能(physicalnetworkfunction,pnf),例如，虚拟化的演进分组核心网(evolvedpacketcore，epc)的移动性管理实体(mobilitymanagemententity,mme)、服务网关(servicegateway,sgw)、分组数据网关(packetdatanetworkgateway,pgw)等节点。网络功能的功能性行为和状态与虚拟化与否无关，nfv技术需求希望vnf和pnf拥有相同的功能性行为和外部接口。其中，vnf可以由一个或多个更低功能级别的vnf组件(virtualnetworkfunctioncomponent,vnfc)组成。因此，一个vnf可以部署在多个虚拟机(virtualmachine，vm)上，每个vm承载一个vnfc的功能。一个vnf也可以部署在一个vm上。

nfv基础设施(nfvinfrastructure,nfvi):由硬件资源、虚拟资源和虚拟化层组成。从vnf的角度来说，虚拟化层和硬件资源看起来是一个能够提供所需的虚拟资源的完整实体。

随着nfv技术的不断发展，原有的构建在nfvi层的vm基础上的vnf的呈现形态融入了新的特性，支持云原生(cloudnative)的vnf和融合平台即服务(platformasaservice,paas)的云化架构将称为电信云发生的新趋势。

在信息技术(informationtechnical,it)领域，云原生是一种方法，用于构建和运行充分利用云计算模型优势的应用。云计算不再将重点放在资本投资和员工上来运行企业数据中心，而是提供无限制的按需计算能力和根据使用情况付费的功能，因此重新定义了几乎所有行业的竞争格局。企业需要一个构建和运行云原生应用和服务的平台，来自动执行并集成devops、持续交付、微服务和容器等概念。

paas是将服务器平台功能作为一种服务的商业模式，通过网络提供软件程序的服务称为软件即服务(softwareasaservice,saas)，而云计算时代相应的云计算平台或者开发环境作为服务提供就成为paas。在云计算的典型层级中，paas层介于saas与基础设施即服务(infrastructureasaservice,iaas)之间。典型的paas平台主要提供如下功能：(1)应用运行环境，包括分布式计算运行环境、多种类型的数据存储、动态资源伸缩功能、应用全生命周期的支持(包括提供开发软件开发工具包(softwaredevelopmentkit,sdk)、电子集成驱动器(integrateddriveelectronics,ide)等加快应用的开发、测试和部署)。(2)以应用编程接口(applicationprogramminginterface,api)形式提供公共服务(例如，队列服务、存储服务和缓存服务)、监控、管理和计量；提供资源池、应用系统的管理和监控功能、精确计量。(3)集成、复合应用构建能力，包括连通性服务、整合服务、消息服务和流程服务等。

容器即服务(containerasaservice,caas)是一种特定类型的paas。一般来说，容器是一种操作系统级别的虚拟化技术，通过操作系统隔离技术，例如，linux下的控制组(controlgroup,cgroup)和命名空间(namespace)，将不同的进程隔离开来。容器技术不同于硬件虚拟化(hypervisor)技术，它并没有虚拟硬件，容器的内部也没有操作系统，而只有进程。正是由于容器技术的这个特点，使得容器相比于虚拟机更轻量、管理也更方便。在容器的运行态，定义了一组公共的管理操作，例如，启动、停止、暂停和删除等，从而可以对容器的生命周期进行统一管理。容器即服务的架构在电信网络功能云化进程中的引入为电信行业的开发运维带来了敏捷性的变革。与之相呼应的变化是，传统的大颗粒单体网络功能逐渐被解构进行服务化，甚至进一步地进行微服务化。每个服务化的功能独立进行开发、交付和维护。

其中，图1中示出的各组件和/或管理实体之间的接口(例如，os-ma-nfvo,ve-vnfm,nf-vi,or-vnfm，vi-vnfm，or-vi等)可以参考现有技术中nfvmano系统中的接口说明，本文不作赘述。

参见图2，图2是容器服务的管理编排系统的一种架构图。具体地，图2示出的是google公司基于开源平台的kubernetes容器集群管理系统。它的核心思想是“一切以服务为中心，一切围绕服务运转”，遵循这一思想在kubernetes上创建的容器应用不仅可以运行在物理机、虚拟机或企业私有云上，也可以被托管到公有云上。kubernetes的另一个特点是自动化，可以自我扩容、缩容、自我诊断，并且容易升级。kubernetes在docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整的功能。如图2所示，kubernetes系统包括控制节点(master)和一组工作节点(node)。master是集群控制节点，以上运行着与集群管理相关的一组进程，负责整个集群的管理和控制，实现容器的管理面。node是kubernetes系统中运行容器组(pod)的服务节点，是pod运行的宿主机。一个容器组(pod)可以包含一个容器或多个相关容器，是kubernetes系统中能够创建、调度、管理的最小单元。pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间(namespace)、互联网协议(internetprotocol，ip)地址，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。kubernetes系统对容器的管理编排功能自成体系，容器的生命周期管理闭环终结于kubernetes系统(master和node之间)，是一个分布式的容器管理系统。

根据上文对nfvmano系统和kubernetes系统的介绍可以发现，nfvmano系统和kubernetes系统相比，一个显著的区别就是nfvmano系统是集中式管理，无论是虚拟资源层或是vnf功能层监控的性能和告警数据，这些监控的运维数据都需要汇聚到nfvo。nfvo管理着域内全局性的资源视图、ns/vnf功能组成以及彼此之间的依赖关系或关联关系，并根据这些信息作出相应的决策，派发给相应的管理实体(例如，vnfm或vim)去执行。nfvmano系统的这些特点与自治管理能力较强的kubernetes系统大相径庭。在将容器服务的管理功能融合到nfvmano系统的新的趋势或需求下，如何确定一个平衡的功能支点来实现将两类管理模式差异显著(一个是集中式管理模式，一个是分布式管理模式)的系统的无缝融合和运行成为一个亟待考虑的问题。

为此，本申请提出一种管理容器服务的方法，旨在将容器服务以及容器服务的管理功能融合到nfvmano系统。

下面对本申请提出的管理容器服务的方法进行说明。

考虑到在面向运营商的中心数据中心(datacenter,dc)和边缘数据中心部署容器服务的场景的差异，本申请针对中心dc(也称为中心云)和边缘dc(也称为边缘云)，分别提供了不同的融合架构，下面分别进行说明。

1、中心dc的融合架构

参见图3，图3是本申请提出的适用于中心dc的一种融合架构。该融合架构的设计思想是在nfvmano架构中新增一个容器服务管理实体。本申请对该容器服务管理实体的名称不作具体限定，例如，容器服务管理实体可以称之为caas管理器(caasmanagement,caasmgt)，或者是采用其它的名称。以下实施例中，仅以将容器服务管理实体称作caas管理器作为示例，对容器服务管理实体的功能进行说明。如图3所示，caas管理器用于承担caas管理面的功能，主要负责对caas(即，容器服务)进行管理和编排。caas部署在vnf，作为vnfpaas层的一个子层。容器服务可以被vnf或者paas层的公共服务(commonservice)或专有服务(dedicatedservice)调用。caas是paas层的容器应用和iaas层的容器资源的集成。这样，caas管理器对caas的管理可以进一步分解为对容器应用的生命周期的管理和对容器资源的管理。这两部分功能在本申请提出的管理容器服务的方法中是耦合在一起。而在现有的nfvmano架构中，vnf的生命周期的管理和虚拟资源的管理是分开的，需要通过不同层次的vnfm和vim分别进行管理。也即前文图1中描述的，vnfm用于对vnf的生命周期进行管理，而nfvi层是由vim进行管理的。

需要说明的是，paas层的公共服务(commonservice)或专用服务(dedicatedservice)可以封装在vnfc中，和vnf的应用成功能组成多厂商互操作下场景下的vnf。caas位于paas层的底部，它集成了paas层和iaas层的服务能力，在iaas层的容器资源管理的基础上封装为paas层基座的平台服务。而caas不同于其它的paas层的服务，caas可以从vnf中独立出来作为独立的可被管理的对象，通过标准化的应用程序编程接口(applicationprogramminginterface,api)实现被不同厂商的容器应用或vnf调用。

下面结合图4，对容器化vnf的组成进行说明。

参见图4，图4示出了本申请提供的容器化vnf的组成。如图4所示，容器化vnf主要包括逻辑功能层、虚拟资源层和nfvi层。在vnf的逻辑功能层，一个vnf实例由一个或多个vnfc实例组成。一个vnfc可以映射为容器服务管理平台中的一个容器应用，并在虚拟资源层映射为一个容器组(pod)或一个容器(container)。

需要说明的是，本申请实施例中所说的容器化vnf区别于现有的nfvmano系统中的vnf。容器化vnf是指在容器上创建的vnf，而现有的vnf是创建在虚拟机上的。以下实施例中所说的vnf即是指现有的创建在虚拟机上的vnf，而容器化vnf即是指本申请提供的创建在容器上的vnf。

需要说明的是，本申请实施例基于如下一个假设，即容器化vnf的虚拟资源层所使用的容器资源的节点(包括虚拟机和/或裸机)资源池与nfvmano系统基于虚拟机的节点资源池彼此之前相互隔离。节点资源池相互隔离，可以保证在容器服务管理系统和nfvmano系统融合的初始阶段，每个系统都能专注于自身的特点运行，使得融合后的系统性能更加稳定、可靠，而不需要集中考虑在资源受限的环境中尽可能地提高资源的利用率。结合图3所示的融合架构来看，caas管理器和nfvmano系统各自具有自己的节点资源池。如图3所示，容器服务的管理功能的节点资源池由caas管理器进行管理，包括虚拟机和/或裸机。而nfvmano系统的节点资源池仍然由vim进行管理。

图3中所示的caas管理器与caas用户面之前的交互可以与现有的容器管理平台相同。例如，caas管理器与caas用户面之前的交互可以基于图2所示的kubernetes这样的开源平台作为事实标准，这与基于openstack的vim事实标准类似。因此，nfvmano架构与容器管理平台融合的问题更多体现在caas管理器的北向接口。也即，容器服务的管理功能如果通过caas管理器接入到nfvmano架构中。下面结合图5至图7的实施例来进行说明。

参见图5，图5是根据本申请提供的管理容器服务的方法创建容器服务的一个示例。具体地，在运营商的中心dc，caas管理器和nfvmano系统部署在同一个dc。vnf和容器化vnf混布在同一个dc。caas管理器将vnfm作为锚点实体接入到nfvmano系统。vnfm作为对vnf实例的生命周期进行管理的汇聚点，针对不同的网络功能(例如，vnf和容器化vnf)，vnfm将针对caas的生命周期的管理操作的命令派发给caas管理器，或者在自身终结。vnfm进一步向vim发起对vnf实例的生命周期进行管理所需的基于vm的虚拟资源的分配过程。

201、vnfm接收来自nfvo或em的容器化vnf的实例化请求消息。

实例化请求用于请求实例化一个(也可以是多个)指定的容器化vnf。实例化请求消息中携带该指定的容器化vnf实例的生命周期管理策略。其中，容器化vnf实例的生命周期管理策略用于对该指定的容器化vnf实例化之后的生命周期进行管理。应理解，容器化vnf实例即是指容器化vnf的实例。

该容器化vnf实例的生命周期管理策略包括但不限于：scaling操作的策略、healing操作的策略以及资源约束的策略等。其中，scaling操作的策略可以包括容器服务scaling操作的监控性能指标(performancemetrics,pm)的门限值。不同的门限值可以触发不同的scaling操作，例如scaling操作的类型和scaling操作的步长，其中，scaling操作的类型包括扩容或缩容。healing操作的策略，例如可以是基于容器服务scaling操作的监控事件执行容器服务healing操作。资源约束的策略可以包括在容器服务healing操作和/或容器服务healing操作中对调度资源的亲和性和/或反亲和性的要求等。

可选地，nfvo或em可以将容器化vnf实例的生命周期管理策略封装在容器化vnf的实例化请求消息中传输给vnfm，或者也可以通过单独的文件传输给vnfm。

在步骤201中，nfvo或em将容器化vnf实例的生命周期管理策略通过容器化vnf的实例化过程传递给vnfm，实际上也就是说，在上述的交互过程中，容器化vnf的生命周期管理仅保留了容器化vnf的实例化过程。

202、vnfm向nfvo发送针对容器化vnf的生命周期的操作许可请求。

其中，该容器化vnf的生命周期的操作许可请求消息中携带该容器化vnf实例的标识信息和该容器化vnf实例的生命周期管理策略。

203、nfvo确定是否许可针对该容器化vnf的生命周期的许可操作请求。

具体地，nfvo检查该容器化vnf所属的网络服务(networkservice,ns)的组成视图。如果与该容器化vnf实例存在依赖关系的vnf实例或嵌套ns实例的状态正常，则该容器化vnf实例的创建不会影响这些存在依赖关系的vnf实例或嵌套ns实例的运行状态，nfvo则允许该操作许可请求。

可选地，nfvo还可以检查该容器化vnf所属的ns的资源视图，如果容器资源的节点资源池中存在可用的容器资源，nfvo则允许该操作许可请求。

204、nfvo向vnfm返回针对操作许可请求的应答消息。

应答消息用于指示nfvo允许或拒绝对该指定的容器化vnf执行该操作许可请求所请求的操作。

可选地，如果nfvo需要调整操作许可请求中携带的容器化vnf实例的生命周期管理策略，则nfvo在应答消息中携带调整后的该容器化vnf实例的生命周期管理策略。

205、vnfm根据该指定的容器化vnf的生命周期管理策略，生成面向该指定的容器化vnf的容器服务的管理策略，并向caas管理器发送容器服务的创建请求。其中，创建请求中携带容器服务的管理策略。

相应地，caas管理器接收来自vnfm的创建请求，并从创建请求中获取容器服务的管理策略。

在本申请实施例中，为了将针对容器服务的生命周期管理策略和针对容器化vnf的生命周期管理策略进行区分，将针对容器服务的生命周期管理策略称之为第一管理策略，将针对容器化vnf的生命周期管理策略称之为第二管理策略。例如，上面步骤201中，容器化vnf的实例化请求中携带容器化vnf的生命周期管理策略，也可以说该容器化vnf的实例化请求中携带第二管理策略。而在步骤205中，vnfm根据容器化vnf的生命周期管理策略，生成面向该容器化vnf的容器服务的管理策略，即是vnfm根据第二管理策略，生成第一管理策略。

换句话说，在本申请实施例中，第二管理策略是面向容器化vnf层面的，用于管理容器化vnf的生命周期。而第一管理策略是面向容器服务层面的，用于管理容器服务的生命周期。

应该理解的是，容器服务的管理策略(也即第一管理策略)是容器化vnf的生命周期管理策略(也即第二管理策略)在vnfc层的分解和映射。例如，将根据scaling操作中对容器化vnf的性能指标的门限值进行监控而触发执行相应的scaling操作，映射为对某个vnfc(容器应用)的监控指标的门限值设定和执行步长的计算。

此外，容器服务的创建请求中还携带该指定的容器服务的名称和标识信息。

在本申请实施例中，构成所述指定的容器化vnf的容器服务称之为指定的容器服务。换句话说，指定的容器化vnf在vnfc层映射为指定的容器服务。

206、caas管理器与caas用户面进行交互，根据容器服务的管理策略创建容器服务的副本控制器(replicationcontroller，rc)和容器组(pod)，在容器组上完成容器应用的映像加载，并激活该容器服务。

步骤206即是caas管理器创建容器服务的过程。

其中，容器服务的管理策略可以作为创建副本控制器的输入。例如：根据scaling操作的容量范围和scaling操作的步长确定容器服务副本的大小和数量。

这里，容器服务的副本控制器(replicationcontroller)用来管理pod的副本，主要功能是保证集群中存在指定数量的pod的副本。一般来说，集群中pod的副本的数量大于指定数量，则会停止该指定数量之外多余的容器数量，反之，如果集群中pod的副本的数量少于指定数量，容器服务的副本控制器则会启动若干个容器，以保证该指定数量的容器。

207、caas管理器向vnfm返回针对创建请求的应答消息。

208、vnfm向nfvo或em返回针对容器化vnf实例化请求的应答消息。

图5所示的实施例适用于将传统的电信网络功能，例如，演进的分组核心网(evolvedpacketcore,epc)功能，进行容器化改造向云上搬迁的应用。在这种场景中，容器化vnf和非容器化vnf(即，构建在vm上的vnf)在中心dc同时存在，容器化vnf和vnf通过统一的管理实体vnfm在vnf层面实现管理功能的汇聚。

上述图5描述的创建容器服务的实施例，实现了容器化vnf的生命周期的管理从集中式按需(ondemand)管理向分布式自治管理的半程转变。即，nfvmano系统的接口上ondemand操作仅保留了vnf实例化和vnf实例的终结(vnf实例的终结可以参考下文图7中所示的实施例)。除此之外的vnf的生命周期的管理过程都通过caas管理器与caas用户面进行自治管理。

下面结合图6介绍另一种创建容器服务的方法。图6中要介绍的创建容器的方法与图5中描述的创建容器服务的方法相比，取消了nfvmano系统的接口上对容器化vnf的生命周期进行管理的所有操作，包括vnf实例化和vnf实例的终结在内的生命周期管理策略将全部映射为面向容器服务的管理策略传递给caas管理器，由caas管理器与caas用户面进行自治管理。

参见图6，图6是根据本申请提供的管理容器服务的方法创建容器服务的另一个示例。

301、nfvo或em向vnfm订阅容器化vnf的生命周期管理的状态改变通知。

其中，容器化vnf的生命周期管理的状态改变通知中指定订阅的容器化vnf的生命周期管理的状态为“实例化”。

302、vnfm向caas管理器订阅容器服务的生命周期管理的状态改变通知。

其中，容器服务的生命周期管理的状态改变通知中指定订阅的容器服务的生命周期的状态为“创建”。

303、nfvo或em向vnfm发送第一策略传递请求。vnfm接收第一策略传递请求。

第一策略传递请求中携带用于管理指定的容器化vnf的生命周期的管理策略(即，上文所说的第二管理策略)。

304、vnfm根据第二管理策略，生成第一管理策略，并向caas管理器发送第二策略传递请求。

第二策略传递请求中携带第一管理策略，其中，第一管理策略是面向指定的容器化vnf的容器服务的管理策略。

应理解，步骤303中所说的“指定的容器化vnf”是由步骤304中所说的“指定的容器服务”构成的。换句话说，根据指定的容器化vnf的生命周期管理策略，生成的是面向组成该指定的容器化vnf的容器服务的生命周期管理策略。

305、caas管理器创建容器服务的副本控制器、容器组，完成容器应用的映像加载并激活容器服务。

其中，第一管理策略可以作为创建副本控制器的输入。例如：根据scaling操作的容量范围和步长确定容器服务副本的大小和数量。

306、caas管理器向vnfm发送容器服务的生命周期管理的状态改变通知，通知vnfm新创建的容器服务。

307、vnfm根据新创建的容器服务实例化指定的容器化vnf。

308、vnfm向nfvo或em发送容器化vnf的生命周期管理的状态改变通知，通知nfvo或em新创建的容器化vnf实例。

参见图7，图7是根据本申请提供的管理容器服务的方法删除容器服务的一个示例。

401、nfvo或em向vnfm发送容器化vnf的终结请求。vnfm从nfvo或em接收容器化vnf的终结请求。

其中，容器化vnf的终结请求用于请求终结指定的容器化vnf的实例。终结请求中携带该指定的容器化vnf的实例标识。

402、vnfm根据容器化vnf的终结请求，向caas管理器发送针对指定的容器服务的删除请求。

删除请求中携带指定的容器服务的标识信息。

403、caas管理器删除容器服务的副本控制器，释放容器服务使用的容器组资源，并去激活容器服务。

步骤403即是caas管理器删除容器服务的过程，也即终结容器化vnf实例的过程。

可见，与图5中所示的创建容器服务的过程类似，图7中所示的容器服务的删除过程由nfvo或em发起的vnf终结过程触发。进一步地，vnfm向caas管理器发起组成vnf实例的容器服务的删除过程。

容易理解的是，容器服务的删除请求是针对已经存在的容器服务而言的。也就是说，对于已经创建好的容器服务，才有可能需要删除它。因此，图7中的请求删除的容器服务可以是图5或图6中新创建的容器服务，当然也可以是早先已经创建的容器服务，这里不作限定。如果是图5或图6中描述的新创建的容器服务，那么删除请求必然在创建请求之后，且是指定的容器服务已经创建完成之后的操作。

需要说明的是，在图6中提供的创建容器服务的实施例中，在融合架构中取消了nfvmano系统的接口(指nfvo和caas管理器)上对容器化vnf的生命周期的全部管理操作(包括上文图5描述的容器化vnf的实例化过程以及图7中描述的容器化vnf实例的终结过程)，反映到nfvo或vnfm派发给caas管理器的第二管理策略中，则是第二管理策略不包括对容器化vnf的实例化的管理策略，和/或第二管理策略不包括对容器化vnf实例的终结的管理策略。应该理解，第二管理策略不包括对容器化vnf的实例化的管理策略和该容器化vnf实例的终结的管理策略，是指第二管理策略包括针对该容器化vnf的整个生命周期管理的其它全部操作，而仅排除对该容器化vnf的实例化和终结的管理操作。例如，第二管理策略包括对该容器化vnf的弹性伸缩、healing操作以及自终结等的管理。

上文对本申请提出的中心dc的融合架构以及在中心dc的融合架构下容器服务的创建和删除进行了说明。下面介绍本申请提出的边缘dc的融合架构，以及在边缘dc的融合架构下容器服务的创建和删除。容器服务的创建也可以理解为容器服务的实例化过程，容器服务的删除也可以理解为容器服务实例的终结过程。实例化过程和实例终结过程是基本的生命周期管理过程，可以参考etsinfv标准中关于vnf或ns的实例化和终结过程。

2、边缘dc的融合架构

考虑到在运营商网络的边缘侧，例如，边缘数据中心(也称为边缘云)，通常都不会部署nfvmano系统，而是轻量化的移动边缘应用(mobileedgeapplication,meapp)通过自治的容器管理系统(例如图2所示的kubernetes系统)完成容器应用的部署和容器服务的生命周期的管理，整个过程无需nfvmano系统的参与。从而，本申请提出了如图8所示的适用于边缘dc的融合架构。

参见图8，图8是本申请提出的适用于边缘dc的一种融合架构。

在边缘dc部署caas管理器，caas管理器和中心dc的nfvmano系统通过跨dc的广域网(wideareanetwork，wan)进行连接。边缘dc的容器服务作为特殊的远端vnf通过中心dc的nfvo接入到nfvmano系统。也即，在边缘dc的融合架构下，nfvo作为caas管理器接入到nfvmano系统的锚点实体。

另外，在图8所示的融合架构中，caas管理器可以是基于开源平台的kubernetes系统，也可以是移动边缘编排器(mobileedgeorchestrator,meo)。其中，meo是遵循欧洲通信标准协会(europeantelecommunicationsstandardsinstitute,etsi)移动边缘计算(mobileedgecomputing,mec)003(groupspecification,gs)规范定义的移动边缘侧管理编排功能的统一出口。mec也可以理解为多接入边缘计算(multi-accessedgecompute)，是etsi对移动边缘计算概念进行了扩展，包括了蜂窝移动、固定网络及wifi等多种不同形式的边缘网络的边缘计算。

参见图9，图9示出了本申请提供的容器化移动边缘应用的组成。与图4中所示的容器化vnf的组成类似，容器化移动边缘应用(即，meapp)也包括逻辑功能层、虚拟资源层和nfvi层。其中，在逻辑功能层，一个移动边缘应用可以映射为一个nfvmano系统中的vnf，同时可以映射为容器管理平台中的一个容器应用。一个移动边缘应用在虚拟资源层可以进一步映射为一个容器组(pod)资源或者一个容器(container)资源。

下面介绍在边缘dc的融合架构下，如何进行容器服务的创建和删除。

图10是根据本申请提供的管理容器服务的方法创建容器服务的一个示例。

501、nfvo向caas管理器发送容器服务的创建请求。caas管理器接收来自nfvo的创建请求。

其中，创建请求中携带nfvo请求创建的容器服务的标识信息、名称以及用于管理容器服务的生命周期的第一管理策略。

nfvo向caas管理器发送容器服务的创建请求可以是nfvo解析自己管理的网络服务(networkservice，ns)的生命周期的管理需求，确定需要在边缘dc创建容器服务而触发的。

需要说明的是，边缘dc的融合架构的实施例中的第一管理策略的，可以参考中心dc的融合架构下各实施例中对于第一管理策略的说明。中心dc的融合架构下各实施例对第一管理策略的说明都可以适用在边缘dc的融合架构下的各实施例中。

502、caas管理器创建容器服务的副本控制器、容器组，完成容器应用的映像加载并激活容器服务。

其中，第一管理策略可以作为创建副本控制器的输入。例如，caas管理器根据scaling操作的容量范围和步长确定容器服务副本的大小和数量。

503、caas管理器向nfvo返回容器服务的创建请求的应答。

下面再结合图11介绍本申请提供的另一种创建容器服务的方法。

参见图11，图11是根据本申请提供的管理容器服务的方法创建容器服务的另一个示例。

601、nfvo向caas管理器订阅容器服务的生命周期管理的状态改变通知。

其中，容器服务的生命周期管理的状态改变通知中指定订阅的容器服务的生命周期管理的状态为“创建”。

602、nfvo向caas管理器发送策略传递请求，策略传递请求中携带针对容器服务的第一管理策略。

603、caas管理器创建容器服务的副本控制器、容器组pod，完成容器应用的映像加载，并激活容器服务。

604、caas管理器向nfvo返回容器服务的生命周期管理的状态改变通知。

容器服务的生命周期管理的状态改变通知用于通知nfvo新创建的容器服务。

在图11所示的创建容器服务的实施例中，在nfvmano系统的接口(指nfvo和caas管理器)上取消了所有对容器服务的管理操作。nfvo将包括容器服务的创建和容器服务删除在内的用于对容器服务的生命周期进行管理的第一管理策略传递给caas管理器，由caas管理器和caas用户面之间自治完成对vnf的生命周期管理策略的解析，生成用于管理容器服务的生命周期的第一管理策略。

下面结合图12，说明在边缘dc的融合架构下，删除容器服务的过程。

参见图12，图12是根据本申请提供的管理容器服务的方法删除容器服务的一个示例。

701、nfvo向caas管理器发送容器服务的删除请求。caas管理器从nfvo接收容器服务的删除请求。

删除请求用于请求删除指定的容器服务，其中，删除请求中携带指定的容器服务的标识信息。

702、caas管理器删除容器服务的副本控制器，释放容器服务使用的容器组，并去激活容器服务。

703、caas管理器向nfvo发送容器服务的删除请求的应答。

可见，在边缘dc的融合架构中，nfvo是作为caas管理器接入nfvmano系统的锚点实体。nfvmano系统的nfvo可以生成面向容器服务的第一管理策略，直接派发给caas管理器执行，而不要vnfm的参与。

结合上文中心dc的融合架构中nfvo在容器服务的创建和删除中执行的操作和/或流程，可以看出，在中心dc的融合架构中，nfvo首先生成用于管理容器化vnf的生命周期的第二管理策略并传递给vnfm。再由vnfm根据该第二管理策略生成面向组成该容器化vnf的容器服务的第一管理策略，并将第一管理策略派发给caas管理器执行。换句话说，nfvo在不同的融合架构中执行的操作和/或流程可以包括两种情况。一种情况是nfvo生成第二管理策略，并将第二管理策略发送给vnfm，这种情况应用于中心dc的融合架构中。另一种情况是nfvo生成第一管理策略，并将第一管理策略直接派发给caas管理器执行，这种情况应用于边缘dc的融合架构中。

容器服务以及容器服务的管理功能是部署在中心数据中心还是边缘数据中心，nfvo是能够获知的。例如，在组网的时候，nfvo就可以获知容器服务以及容器服务的管理功能的部署情况，包括具体是部署在中心dc还是部署在边缘dc。因此，nfvo在对容器服务的管理过程中，针对部署在边缘数据中心的caas管理器，nfvo则直接生成面向容器服务的第一管理策略，并派发给caas管理器执行。而针对部署在中心数据中心的caas管理器，nfvo生成的是面向容器化vnf的第二管理策略，并将第二管理策略派发给vnfm，由vnfm对第二管理策略进行解析，生成面向容器服务的管理策略再派发给caas管理器执行。

相应地，对于vnfm而言，在中心dc的融合架构下，vnfm从nfvo接收第二管理策略，并根据第二管理策略生成第一管理策略，再将第二管理策略发送给caas管理器执行。而在边缘dc的融合架构中，nfvo是作为caas管理器接入nfvmano系统的锚点实体，vnfm不参与容器服务的创建和删除过程。

上文结合图1至图12，对本申请提供的中心dc的融合架构和边缘dc的融合架构进行了说明，并对各自架构下容器服务的创建和删除过程作了详细介绍。

需要说明的，基于面向容器服务的生命周期的管理策略(也即，上文的第一管理策略)，caas管理器和caas的用户面之间可以自治完成对容器服务的生命周期进行管理的其它操作，例如，scaling操作，healing操作等。这些操作都不要nfvmano系统的参与，因此，也不涉及caas管理器和接入nfvmano系统的锚点实体的交互过程，因此，本文对这些操作过程不作介绍。caas管理器和caas的用户面之间自治完成对容器服务的生命周期进行管理的其它操作，可以参考现有的容器服务管理系统的管理流程，例如，可以参考现有的kubernetes系统。

在本申请提供的nfvmano系统和容器服务的管理系统的融合架构(包括针对中心dc的融合架构和针对边缘dc的融合架构)中，容器服务的管理功能将vnfm或nfvo作为接入nfvmano系统的锚点实体。通过锚点实体和caas管理器之间的交互，可以完成对容器服务的管理操作，保持caas管理器和caas用户面之间对容器应用的生命周期的自治管理，同时还可以保留对容器资源进行管理的既有特征，也可以保留nfvmano系统中锚点实体以上以nfvo为中枢进行集中式监控的nfvmano系统的功能基本不变，能够平滑地将容器服务的管理功能融合到nfvmano系统。

上文结合图1至图12对本申请提出的管理容器服务的方法作了详细说明。下文对本申请提出的管理容器服务的装置进行说明。

图13是本申请提出的管理容器服务的装置800的示意性框图。如图8所示，装置800包括获取单元810和管理单元820。

收发单元810，用于接收容器服务的创建请求，创建请求用于请求创建指定的容器服务，创建请求中携带用于管理指定的容器服务的生命周期的第一管理策略；

创建单元820，用于响应收发单元接收到的创建请求，创建指定的容器服务；

管理单元830，用于根据第一管理策略，对所述创建单元820创建的容器服务的生命周期进行管理。

可选地，收发单元810还用于接收容器服务的删除请求，删除请求用于请求删除指定的容器服务，删除请求中携带所述指定的容器服务的标识信息。以及，管理单元820还用于根据第一管理策略，删除创建单元820创建的该指定的容器服务。

具体地，在中心数据中心部署容器服务的管理功能的情况下，收发单元810用于从虚拟网络功能管理器vnfm接收创建请求。以及，从vnfm接收删除请求。在边缘数据中心部署容器服务的管理功能的情况下，收发单元810用于从网络功能虚拟化编排器nfvo接收创建请求。以及，从nfvo接收删除请求。

另外，在本申请实施例中，容器服务的管理包括容器应用的生命周期的管理和构成容器服务的容器资源的管理，管理单元830用于根据所述第一管理策略，对容器应用的生命周期和组成该指定的容器服务的容器资源进行管理。

在本申请实施例中，容器应用的生命周期的管理和容器资源的管理都是由caas管理器执行的。

可选地，上述装置800可以为上述实施例中的caas管理器，或者安装在网络设备上的芯片，该芯片具有执行上述方法实施例中的由caas管理器执行的相应操作和/或流程的功能。例如，在中心数据中的融合架构下，可以参考图5至图7中所示的caas管理器。在边缘中心数据的融合架构下，可以参考图10至图12中所示的caas管理器。

图14是本申请提出的管理容器服务的装置900的示意性框图。如图14所示，装置900包括获取单元910、生成单元920和收发单元930。

获取单元910，用于获取用于管理指定的容器化vnf的生命周期的第二管理策略。

生成单元920，用于根据获取单元910获取的第二管理策略，生成用于管理指定的容器服务的生命周期的第一管理策略。其中，所述指定的容器化vnf由所述指定的容器服务组成；

收发单元930，用于将生成单元920生成的第一管理策略发送给容器服务管理实体。

可选地，第二管理策略不包括容器化vnf的实例化的管理策略，收发单元810具体用于从网络功能虚拟化编排器nfvo或网元管理系统em接收容器化vnf的实例化请求，并从实例化请求中获取第二管理策略。其中，实例化请求用于请求实例化指定的容器化vnf，实例化请求中携带第二管理策略。

可选地，第二管理策略不包括容器化vnf实例的终结的管理策略，收发单元810具体用于从nfvo接收容器化vnf实例的终结请求，终结请求用于请求终结指定的容器化vnf的实例，终结请求中携带指定的容器化vnf的实例的标识信息。收发单元810还用于响应于终结请求，向容器服务管理实体发送容器服务的删除请求。

可选地，上述装置900可以为上述方法实施例中的vnfm，或者安装在网络设备上的芯片，该芯片具有执行上述方法实施例中的由vnfm(例如，图5至图7中所示的vnfm)执行的相应操作和/或流程的功能。

图15是本申请提出的管理容器服务的装置1000的示意性框图。

生成单元1001，用于生成用于管理指定的容器服务的生命周期的第一管理策略，或者，生成用于管理指定的容器化虚拟网络功能vnf的生命周期的第二管理策略，其中，所述指定的容器化vnf是由所述指定的容器服务组成的。

收发单元1002，用于在生成单元1001生成第一管理策略的情况下，将第一管理策略发送给容器服务管理实体。或者，

收发单元1002，用于在生成单元1001生成第二管理策略的情况下，将第二管理策略发送给虚拟化网络功能vnfm。

可选地，收发单元1002用于向容器服务管理实体发送容器服务的创建请求，创建请求中携带第一管理策略。

可选地，收发单元1002还用于向容器服务管理实体发送容器服务的删除请求，删除请求用于请求删除指定的容器服务，删除请求中携带指定的容器服务的标识信息。

具体地，在nfvo生成第二管理策略的情况下，如果第二管理策略不包括容器化vnf的实例化的管理策略，收发单元1002用于向vnfm发送容器化vnf的实例化请求，实例化请求用于请求实例化指定的容器化vnf，实例化请求中携带第二管理策略。

如果第二管理策略不包括容器化vnf实例的终结的管理策略，收发单元1002用于向vnfm发送容器化vnf实例的终结请求，终结请求用于请求终结指定的容器化vnf的实例，终结请求中携指定的容器化vnf的实例的标识信息。

其中，nfvo生成第二管理策略的情况适用于在中心数据中心部署容器服务以及容器服务的管理功能的场景。而nfvo生成第一管理策略的情况适用于在边缘数据中心部署容器服务以及容器服务的管理功能的场景。

可选地，上述装置1000可以为上述方法实施例中的nfvo，或者安装在网络设备上的芯片，该芯片具有执行上述方法实施例中的由nfvo执行的相应操作和/或流程的功能。例如，在中心数据中心的融合架构下，可以参考图5至图7中所示的nfvo。在边缘数据中心的融合架构下，可以参考图10至图12中所示的nfvo。

图16是适用于本申请实施例的管理容器服务的网络设备2000的示意性结构图。如图16所示，网络设备2000包括：一个或多个处理器2001，一个或多个存储器2002，一个或多个收发器2003。处理器2001用于控制收发器2003收发信号，存储器2002用于存储计算机程序，处理器2001用于从存储器2002中调用并运行该计算机程序，使得网络设备2000执行本申请的管理容器服务的方法中由caas管理器执行的相应流程和/或操作。例如，网络设备2000部署在中心数据中心的情况下，网络设备2000执行图5至图7中由caas管理器执行的相应流程和/或操作。网络设备2000部署在边缘数据中心的情况下，网络设备2000执行图10至图12中由caas管理器执行的相应流程和/或操作。

图17是适用于本申请实施例的管理容器服务的网络设备3000的示意性结构图。如图9所示，网络设备3000包括：一个或多个处理器3001，一个或多个存储器3003，一个或多个收发器3003。处理器3001用于控制收发器3003收发信号，存储器3003用于存储计算机程序，处理器3001用于从存储器3003中调用并运行该计算机程序，使得网络设备3000执行本申请的管理容器服务的方法中由vnfm执行的相应流程和/或操作。例如，网络设备3000执行图5至图7中由vnfm执行的相应流程和/或操作。

图18是适用于本申请实施例的管理容器服务的网络设备4000的示意性结构图。如图9所示，网络设备4000包括：一个或多个处理器4001，一个或多个存储器4004，一个或多个收发器4004。处理器4001用于控制收发器4004收发信号，存储器4004用于存储计算机程序，处理器4001用于从存储器4004中调用并运行该计算机程序，使得网络设备4000执行本申请的管理容器服务的方法中由nfvo执行的相应流程和/或操作。例如，网络设备4000执行图5至图7或图10至图12中由nfvo执行的相应流程和/或操作。

此外，本申请还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述管理容器的方法实施例中由caas管理器执行的相应流程和/或操作。

本申请还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述管理容器的方法实施例中由vnfm执行的相应流程和/或操作。

本申请还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述管理容器的方法实施例中由nfvo执行的相应流程和/或操作。

此外，本申请还提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网络设备执行上述管理容器的方法实施例中由caas管理器执行的相应流程和/或操作。

本申请还提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网络设备执行上述管理容器的方法实施例中由vnfm执行的相应流程和/或操作。

本申请还提供一种芯片，包括存储器和处理器，存储器用于存储计算机程序，处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网络设备执行上述管理容器的方法实施例中由nfvo执行的相应流程和/或操作。

此外，本申请还提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述管理容器的方法实施例中由caas管理器执行的相应流程和/或操作。

本申请还提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述管理容器的方法实施例中由vnfm执行的相应流程和/或操作。

本申请还提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述管理容器的方法实施例中由nfvo执行的相应流程和/或操作。

此外，本申请还提供一种管理容器服务的系统，该系统包括上述管理容器服务的方法实施例中(例如，图5-图7，以及图10-图12)涉及到的caas管理器，vnfm和/或nfvo。

上述实施例中，“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况。其中a，b可以是单数或者复数。

以上实施例中，处理器可以为cpu、微处理器、特定应用集成电路(application-specificintegratedcircuit，asic)，或一个或多个用于控制本申请方案程序执行的集成电路等。例如，处理器可以包括数字信号处理器设备、微处理器设备、模数转换器、数模转换器等。处理器可以根据这些设备各自的功能而在这些设备之间分配移动设备的控制和信号处理的功能。此外，处理器可以包括操作一个或多个软件程序的功能，软件程序可以存储在存储器中。

处理器的所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

存储器可以是只读存储器(read-onlymemory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(randomaccessmemory，ram)或者可存储信息和指令的其他类型的动态存储设备。也可以是电可擦可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、只读光盘(compactdiscread-onlymemory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质等。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是计算机软件和电子硬件的结合来执行，取决于技术方案的特定应用和设计约束条件。本领域的技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式。本领域技术人员基于本申请揭露的技术方案，可想到其他实现方式。