部署虚拟化网络功能的方法和装置

技术领域

本申请涉及通信领域，并且更具体地，涉及一种部署虚拟化网络功能的方法和装置。

背景技术

在容器化场景下，虚拟化网络功能(Virtualized Network Function，VNF)需要基于虚拟网络功能描述符(Virtualized Network Function Descriptor，VNFD)模板部署多个Pod，该VNFD模板内表达了Pod对待部署节点标签的诉求，根据该标签诉求在资源池中可以选择与该标签诉求匹配的节点部署该Pod，由于现有VNFD模板内表达Pod对节点标签的诉求方式是比较固定的，因此，基于现有的标签匹配机制，无法满足更加广泛的部署调度诉求。

发明内容

本申请提供一种部署虚拟化网络功能的方法和装置，能够满足VNF更加广泛灵活的部署调度诉求。

第一方面，提供了一种部署虚拟化网络功能的方法，该方法可以由第一网元执行，或者，也可以由配置于第一网元中的芯片或电路执行，本申请对此不作限定。

该方法可以包括：第一网元获取第一虚拟化网络功能描述VNFD模板，第一VNFD模板用于部署第一VNF的部署单元，第一VNFD模板包括多个键值对；第一网元获取键值对的第一取值，第一取值包括多个键值对中第一键值对的取值，第一键值对的取值用于指示第一键值对不作用于部署第一VNF的部署单元；第一网元根据第一VNFD模板和第一取值，向容器即服务CaaS管理器发送第一请求消息，第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上部署第一VNF的部署单元。

上述技术方案中，通过VNFD模板中第一键值对的取值来控制第一键值对是否生效，该机制可以基于一套VNFD模板满足不同局点的部署诉求，满足VNF更加广泛灵活的部署调度诉求，同时，也使得VNFD模板地发布更加简洁且适应性更强。

在第一方面的某些实现方式中，第一请求消息包括第一VNFD模板和第一取值；或者，第一请求消息包括第一VNFD模板的索引和第一取值；或者，第一请求消息包括第三VNFD模板和第三VNFD模板中一个或多个键值对的第三取值，第三VNFD模板为第一VNFD模板且不包含第一键值对，第三取值为第一取值且不包含第一键值对的取值。

上述技术方案中，当第一键值对的取值用于指示第一键值对不作用于部署第一VNF的部署单元之后，不向CaaS管理传递该第一键值对和该键值对的取值，从而使CaaS管理器在选择待部署节点时不会引入该键值对对节点的属性要求。

在第一方面的某些实现方式中，满足第一VNFD模板和键值对的第一取值的节点包括：节点的标签与第一VNFD模板和第一取值匹配的节点，或，节点的标签与第三VNFD模板和第三取值匹配的节点。

在第一方面的某些实现方式中，第一键值对的取值为第一键值对中键的取值。

在第一方面的某些实现方式中，第一键值对的取值为第一键值对中值的取值。

在第一方面的某些实现方式中，第一键值对的取值为第一键值对包含的至少一个值中的一个值的取值。

在第一方面的某些实现方式中，第一请求消息用于请求在满足第一VNFD模板和第一取值的节点上部署第一VNF的部署单元，包括：第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上重部署第一VNF的部署单元，或者，第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上扩容部署第一VNF的部署单元。

在第一方面的某些实现方式中，获取第一VNFD中第一取值之前，该方法还包括：第一网元获取键值对的第二取值，第二取值包括第一键值对的取值，第二取值中第一键值对的取值用于指示第一键值对作用于部署第一VNF的部署单元，第一网元根据第一VNFD模板和第二取值，向CaaS管理器发送第二请求消息，第二请求消息用于请求在满足第一VNFD模板和第二取值的节点上部署第一VNF的部署单元。

上述技术方案中，VNF在首次部署后，当VNF部署诉求发生变化，例如需要扩容或者重部署，基于上述方案有可以仍然沿用VNF首次部署时的VNFD模板，通过控制VNFD模板中键值对的取值来控制键值对是否生效，从而在选择待部署节点时引入更多属性限制或者减少属性限制，以改变或新增待部署节点，满足部署诉求的变化。

在第一方面的某些实现方式中，该方法还包括：第一网元向CaaS管理器发送第三请求消息，第三请求消息用于请求对第一类型节点的标签进行配置，其中，第三请求消息中包括第一信息和第二信息，第一信息包括第一类型节点的特征信息，第二信息包括第一类型节点的标签中待配置的键值对信息；第一网元接收来自CaaS管理器的第三请求响应消息，第三请求响应消息指示第一类型节点的标签配置成功。

在第一方面的某些实现方式中，该方法还包括：第一网元接收来自CaaS管理器的第一请求响应消息，第一请求响应消息指示第一VNF的部署单元部署成功。

在第一方面的某些实现方式中，部署单元为Pod，或者，部署单元为虚拟机VM。

在第一方面的某些实现方式中，第一网元为虚拟网络功能管理器VNFM或网络功能虚拟化编排器NFVO。

第二方面，提供了一种部署虚拟化网络功能的方法，该方法可以由CaaS管理器执行，或者，也可以由配置于CaaS管理器中的芯片或电路执行，本申请对此不作限定。

该方法可以包括：容器即服务CaaS管理器接收来自第一网元的第一请求消息，一请求消息用于请求在满足第一虚拟化网络功能描述VNFD模板和第一取值的节点上部署第一VNF的部署单元，其中，第一VNFD模板用于部署第一VNF的部署单元，第一VNFD模板包括一个或多个键值对，第一取值为键值对的取值，第一取值包括键值对中第一键值对的取值，第一键值对的取值用于指示第一键值对不作用于部署第一VNF的部署单元；CaaS管理器根据第一请求消息部署第一VNF的部署单元。

关于第二方面的有益效果参见第一方面的描述，这里不再赘述。

在第二方面的某些实现方式中，第一请求包括第一VNFD模板和键值对的第一取值；或者，第一请求包括第一VNFD模板的索引和键值对的第一取值。

在第二方面的某些实现方式中，满足第一VNFD模板和键值对的第一取值的节点包括：节点的标签与第一VNFD模板和第一取值匹配的节点。

在第二方面的某些实现方式中，第一键值对的取值为第一键值对中键的取值。

在第二方面的某些实现方式中，第一键值对的取值为第一键值对中值的取值。

在第二方面的某些实现方式中，第一键值对的取值为第一键值对包含的至少一个值中的一个值的取值。

在第二方面的某些实现方式中，第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上部署第一VNF的部署单元，包括：第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上重部署第一VNF的部署单元，或者，第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上扩容部署第一VNF的部署单元。

在第二方面的某些实现方式中，接收来自第一网元的第一请求消息之前，该方法还包括：CaaS管理器接收来自第一网元的第二请求消息，第二请求消息用于请求在满足第一VNFD模板和第二取值的节点上部署第一VNF的部署单元，第二取值为键值对的取值，第二取值包括多个键值对中第一键值对的取值，第二取值中第二键值对的取值用于指示第二键值对作用于部署第一VNF的部署单元；CaaS管理器根据第二请求消息部署第一VNF的部署单元。

在第二方面的某些实现方式中，当第一请求消息用于请求重部署第一VNF的部署单元时，根据第一请求消息部署第一VNF的部署单元，包括：如果第一节点和第二节点为同一节点，则CaaS管理器将第一VNF的部署单元保持部署在第二节点上，否则，CaaS管理器将第一部署单元从第二节点重部署至第一节点上，其中，第一节点为满足第一VNFD模板和第一取值且待重部署第一VNF的部署单元的节点，第二节点为当前部署第一VNF的部署单元且满足第一VNFD模板和第二取值的节点。

在第二方面的某些实现方式中，该方法还包括：CaaS管理器接收来自第一网元的第三请求消息，第三请求消息用于请求对第一类型节点的标签进行配置，其中，第三请求消息中包括第一信息和第二信息，第一信息包括第一类型节点的特征信息，第二信息包括第一类型节点的标签中待配置的键值对信息；CaaS管理器向第一网元发送第三请求响应消息，第三请求响应消息指示第一类型节点的标签配置成功。

在第二方面的某些实现方式中，该方法还包括：CaaS管理器向第一网元发送第一请求响应消息，第一请求响应消息指示第一VNF的部署单元部署成功。

在第二方面的某些实现方式中，部署单元为Pod，或者，部署单元为虚拟机VM。

在第二方面的某些实现方式中，第一网元为虚拟网络功能管理器VNFM或网络功能虚拟化编排器NFVO。

第三方面，提供了一种部署虚拟化网络功能的方法，该方法可以由第一网元执行，或者，也可以由配置于第一网元中的芯片或电路执行，本申请对此不作限定。

该方法可以包括：第一网元获取第一虚拟化网络功能描述VNFD模板，第一VNFD模板用于部署第一VNF的部署单元，第一VNFD模板包括一个或多个键值对，其中，一个或多个键值对中的第一键值对的第一值的取值的数量是可变的；第一网元获取键值对的第一取值，其中，第一取值包括第一值的取值构成的第一取值集合；第一网元根据第一VNFD模板和第一取值，向容器即服务CaaS管理器发送第一请求消息，第一请求消息用于请求在满足第一VNFD模板和第一取值的节点上部署第一VNF的部署单元。

上述技术方案中，支持一个键值对的一个值可以有多个取值，该方法可以实现比较灵活的跨资源池扩展诉求，扩展调整方式可以最大程度的减小业务中断，且资源池扩展方式，不会对存量资源池规划造成影响。

在第三方面的某些实现方式中，在第一网元获取第一取值之前，该方法还包括：第一网元获取键值对的第二取值，其中，第二取值包括第一值的取值构成的第二取值集合，第二取值集合包含第二数量的取值，第一取值集合包含第一数量的取值，第二数量与第一数量不同；第一网元根据第一VNFD模板和第二取值，向容器即服务CaaS管理器发送第二请求消息，第二请求消息用于请求在满足第一VNFD模板和第二取值的节点上部署第一VNF的部署单元。

上述技术方案中，VNF在首次部署后，当VNF部署诉求发生变化，例如需要扩容或者重部署，基于上述方案有可以仍然沿用VNF首次部署时的VNFD模板，通过更新VNFD模板中键值对的值的取值个数可以扩大部署单元对部署节点的选择范围，从而实现比较灵活的跨资源池扩展诉求，满足部署诉求的变化。

在第三方面的某些实现方式中，第一请求消息用于请求在满足第一VNFD模板和第一取值的节点上部署第一VNF的部署单元，包括：第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上重部署第一VNF的部署单元，或者，第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上扩容部署第一VNF的部署单元。

在第三方面的某些实现方式中，当第一值的取值包括多个取值时，多个取值中相邻的两个取值之间通过第一字符串接。

在第三方面的某些实现方式中，第一请求消息包括第一VNFD模板和第一取值；或者，第一请求消息包括第一VNFD模板的索引和所第一取值。

在第三方面的某些实现方式中，满足第一VNFD模板和键值对的第一取值的节点包括：节点的标签与第一VNFD模板和第一取值匹配的节点。

在第三方面的某些实现方式中，该方法还包括：第一网元向CaaS管理器发送第三请求消息，第三请求消息用于请求对第一类型节点的标签进行配置，其中，第二请求消息中包括第一信息和第二信息，第一信息包括第一类型节点的特征信息，第二信息包括第一类型节点的标签中待配置的键值对信息；第一网元接收来自CaaS管理器的第三请求响应消息，第三请求响应消息指示第一类型节点的标签配置成功。

在第三方面的某些实现方式中，该方法还包括：第一网元接收来自CaaS管理器的第一请求响应消息，第一请求响应消息指示第一VNF的部署单元部署成功。

在第三方面的某些实现方式中，部署单元为Pod，或者部署单元为虚拟机VM。

在第三方面的某些实现方式中，第一网元为虚拟网络功能管理器VNFM或网络功能虚拟化编排器NFVO。

第四方面，提供了一种部署虚拟化网络功能的方法，该方法可以由CaaS管理器执行，或者，也可以由配置于CaaS管理器中的芯片或电路执行，本申请对此不作限定。

该方法可以包括：容器即服务CaaS管理器接收来自第一网元的第一请求消息，第一请求消息用于请求在满足第一虚拟化网络功能描述VNFD模板和第一取值的节点上部署第一VNF的部署单元，其中，第一VNFD模板用于部署第一VNF的部署单元，第一VNFD模板包括一个或多个键值对，一个或多个键值对中的第一键值对的第一值的取值的数量是可变的，第一取值为键值对的取值，第一取值包括第一值的取值构成的第一取值集合；CaaS管理器根据第一请求消息部署第一VNF的部署单元。

关于第四方面的有益效果参见第三方面的描述，这里不再赘述。

在第四方面的某些实现方式中，第一请求消息用于请求在满足第一VNFD模板和第一取值的节点上部署第一VNF的部署单元包括：第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上重部署第一VNF的部署单元，或者，第一请求消息用于请求在满足第一VNFD模板和键值对的第一取值的节点上扩容部署第一VNF的部署单元。

在第四方面的某些实现方式中，该方法还包括：CaaS管理器接收来自第一网元的第二请求消息，第二请求消息用于请求在满足第一虚拟化网络功能描述VNFD模板和第二取值的节点上部署第一VNF的部署单元，其中，第二取值为键值对的取值，第二取值包括第一值的取值构成的第二取值集合，第二取值集合包含第二数量的取值，第一取值集合包含第一数量的取值，第二数量与第一数量不同；CaaS管理器根据第一请求消息部署第一VNF的部署单元。

在第四方面的某些实现方式中，当第一请求消息用于请求重调度第一VNF的部署单元时，根据第一请求消息部署第一VNF的部署单元，包括：如果第一节点和第二节点为同一节点，则CaaS管理器将第一VNF的部署单元保持部署在第二节点上，否则，CaaS管理器将第一部署单元从第二节点重部署至第一节点上，其中，第一节点为满足第一VNFD模板和第一取值且待重部署第一VNF的部署单元的节点，第二节点为当前部署第一VNF的部署单元且满足第一VNFD模板和第二取值的节点。

在第四方面的某些实现方式中，当一个或多个键值对中一个键值对的值的取值集合中包括多个取值时，多个取值中相邻的两个取值之间通过第一字符串接。

在第四方面的某些实现方式中，第一请求消息包括第一VNFD模板和第一取值；或者，第一请求消息包括第一VNFD模板的索引和所第一取值。

在第四方面的某些实现方式中，满足第一VNFD模板和键值对的第一取值的节点包括：节点的标签与第一VNFD模板和第一取值匹配的节点。

在第四方面的某些实现方式中，该方法还包括：CaaS管理器接收来自第一网元的第三请求消息，第三请求消息用于请求对第一类型节点的标签进行配置，其中，第二请求消息中包括第一信息和第二信息，第一信息包括第一类型节点的特征信息，第二信息包括第一类型节点的标签中待配置的键值对信息；CaaS管理器向第一网元发送第三请求响应消息，第三请求响应消息指示第一类型节点的标签配置成功。

在第四方面的某些实现方式中，该方法还包括：CaaS管理器向第一网元发送第一请求响应消息，第一请求响应消息指示第一VNF的部署单元部署成功。

在第四方面的某些实现方式中，部署单元为Pod，或者部署单元为虚拟机VM。

在第四方面的某些实现方式中，第一网元为虚拟网络功能管理器VNFM或网络功能虚拟化编排器NFVO。

第五方面，提供了一种部署虚拟化网络功能的方法，该方法可以由第一网元执行，或者，也可以由配置于第一网元中的芯片或电路执行，本申请对此不作限定。

该方法可以包括：第一网元向容器即服务CaaS管理器发送第一信息，第一信息包括自定义调度策略的相关信息，自定义调度策略为第一VNF的部署单元对待部署节点的个性化诉求信息；第一网元接收来自CaaS管理器发送第一消息，第一消息指示自定调度策略设置完成；第一网元向CaaS管理器发送第一请求消息，第一请求消息用于请求根据自定义调度策略部署第一VNF的部署单元；第一网元接收CaaS管理器的第一请求响应消息，第一请求响应消息指示第一VNF的部署单元部署成功。

上述技术方案中，通过自定义调度策略可以提供一种更灵活的容器部署/调度干预方法，从而让部署定制性要求较强的产品可以不受限于VNFD模板，在容器化场景下可以实现更加广泛的部署调度诉求。

结合第五方面，在第五方面的某些实现方式中，自定义调度策略的相关信息包括：自定义调度策略所在的文件的信息、自定义调度策略所需的输入参数和输出参数的定义。

结合第五方面，在第五方面的某些实现方式中，自定义调度策略的相关信息包括：自定义调度策略的生效周期。

结合第五方面，在第五方面的某些实现方式中，输入参数包括以下至少一项：第一节点的剩余资源、第一节点上已部署的部署单元、第一节点的标签信息，第一节点为资源池中可用于部署第一VNF的部署单元的备选节点，输出参数包括第一节点的匹配度，匹配度是基于输入参数的取值与自定义调度策略确定的。

结合第五方面，在第五方面的某些实现方式中，该方法还包括：第一网元向CaaS管理器发送第一VNFD模板，第一VNFD模板为第一VNF的容器化部署模板，第一VNFD模板包括第一信息。

结合第五方面，在第五方面的某些实现方式中，第一网元为虚拟网络功能管理器VNFM或网络功能虚拟化编排器NFVO。

第六方面，提供了一种部署虚拟化网络功能的方法，该方法可以由CaaS管理器执行，或者，也可以由配置于CaaS管理器中的芯片或电路执行，本申请对此不作限定。

该方法可以包括：容器即服务CaaS管理器接收来自第一网元的第一信息，第一信息包括自定义调度策略的相关信息，自定义调度策略为第一VNF的第一虚拟部署单元VDU对待部署节点的个性化诉求信息；CaaS管理器向第一网元发送第一消息，第一消息指示自定调度策略设置完成；CaaS管理器接收来自第一网元的第一请求消息，第一请求消息用于请求根据自定义调度策略部署第一VNF的部署单元；CaaS管理器根据自定义调度策略的信息部署第一VNF的部署单元至匹配的节点；CaaS管理器向第一网元发送第一请求响应消息，第一请求响应消息指示第一VNF的部署单元部署成功。

关于第六方面的有益效果参见第五方面的描述，这里不再赘述。

结合第六方面，在第六方面的某些实现方式中，自定义调度策略的相关信息包括：自定义调度策略所在的文件的信息、自定义调度策略所需的输入参数和输出参数的定义。

结合第六方面，在第六方面的某些实现方式中，自定义调度策略的相关信息包括：自定义调度策略的生效周期。

结合第六方面，在第六方面的某些实现方式中，输入参数包括以下至少一项：第一节点的剩余资源、第一节点上已部署的部署单元、第一节点的标签信息，第一节点为资源池中可用于部署第一VNF的部署单元的备选节点，输出参数包括第一节点的匹配度，匹配度是基于输入参数的取值与自定义调度策略确定的。

结合第六方面，在第六方面的某些实现方式中，CaaS管理器根据自定义调度策略的信息部署第一VNF的部署单元至匹配的节点，包括：CaaS管理器确定资源池中可用于部署第一VNF的部署单元的多个备选节点的匹配度；CaaS管理器将第一VNF的部署单元部署至多个备选节点中匹配度最高的节点上。

结合第六方面，在第六方面的某些实现方式中，CaaS管理器接收来自第一网元的第一信息，包括：CaaS管理器接收来自第一网元的第一VNFD模板，第一VNFD模板为第一VNF的容器化部署模板，第一VNFD模板包括第一信息。

结合第六方面，在第六方面的某些实现方式中，第一网元为虚拟网络功能管理器VNFM或网络功能虚拟化编排器NFVO。

第七方面，提供一种通信装置，该装置用于执行上述第一方面或第三方面或第五方面提供的方法。具体地，该装置可以包括用于执行第一方面或第三方面或第五方面以及第一方面或第三方面或第五方面中任一种可能实现方式中的方法的单元和/或模块，如处理单元和/或通信单元。

在一种实现方式中，该装置为第一网元。当该装置为第一网元时，通信单元可以是收发器，或，输入/输出接口；处理单元可以是至少一个处理器。可选地，收发器可以为收发电路。可选地，输入/输出接口可以为输入/输出电路。

在另一种实现方式中，该装置为用于第一网元中的芯片、芯片系统或电路。当该装置为用于第一网元中的芯片、芯片系统或电路时，通信单元可以是该芯片、芯片系统或电路上的输入/输出接口、接口电路、输出电路、输入电路、管脚或相关电路等；处理单元可以是至少一个处理器、处理电路或逻辑电路等。

第八方面，提供一种通信装置，该装置用于执行上述第二方面或第四方面或第六方面提供的方法。具体地，该装置可以包括用于执行第二方面或第四方面或第六方面以及第二方面或第四方面或第六方面中任一种可能实现方式中的方法的单元和/或模块，如处理单元和/或通信单元。

在一种实现方式中，该装置为CaaS管理器。当该装置为CaaS管理器时，通信单元可以是收发器，或，输入/输出接口；处理单元可以是至少一个处理器。可选地，收发器可以为收发电路。可选地，输入/输出接口可以为输入/输出电路。

在另一种实现方式中，该装置为用于CaaS管理器中的芯片、芯片系统或电路。当该装置为用于终端设备中的芯片、芯片系统或电路时，通信单元可以是该芯片、芯片系统或电路上的输入/输出接口、接口电路、输出电路、输入电路、管脚或相关电路等；处理单元可以是至少一个处理器、处理电路或逻辑电路等。

第九方面，提供一种通信装置，该装置包括：包括至少一个处理器，至少一个处理器与至少一个存储器耦合，至少一个存储器用于存储计算机程序或指令，至少一个处理器用于从至少一个存储器中调用并运行该计算机程序或指令，使得通信装置执行第一方面或第三方面或第五方面以及第一方面或第三方面或第五方面中任一种可能实现方式中的方法。

在一种实现方式中，该装置为第一网元。

在另一种实现方式中，该装置为用于第一网元中的芯片、芯片系统或电路。

第十方面，提供一种通信装置，该装置包括：包括至少一个处理器，至少一个处理器与至少一个存储器耦合，至少一个存储器用于存储计算机程序或指令，至少一个处理器用于从至少一个存储器中调用并运行该计算机程序或指令，使得通信装置执行第二方面或第四方面或第六方面以及第二方面或第四方面或第六方面中任一种可能实现方式中的方法。

在一种实现方式中，该装置为CaaS管理器。

在另一种实现方式中，该装置为用于CaaS管理器中的芯片、芯片系统或电路。

第十一方面，本申请提供一种处理器，用于执行上述各方面提供的方法。

对于处理器所涉及的发送和获取/接收等操作，如果没有特殊说明，或者，如果未与其在相关描述中的实际作用或者内在逻辑相抵触，则可以理解为处理器输出和接收、输入等操作，也可以理解为由射频电路和天线所进行的发送和接收操作，本申请对此不做限定。

第十二方面，提供一种计算机可读存储介质，该计算机可读存储介质存储用于设备执行的程序代码，该程序代码包括用于执行上述第一方面或第二方面或第三方面或第四方面或第五方面或第六方面以及第一方面或第二方面或第三方面或第四方面或第五方面或第六方面中任一种可能实现方式中的方法。

第十三方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面或第二方面或第三方面或第四方面或第五方面或第六方面以及第一方面或第二方面或第三方面或第四方面或第五方面或第六方面中任一种可能实现方式中的方法。

第十四方面，提供一种芯片，芯片包括处理器与通信接口，处理器通过通信接口读取存储器上存储的指令，执行上述第一方面或第二方面或第三方面或第四方面或第五方面或第六方面以及第一方面或第二方面或第三方面或第四方面或第五方面或第六方面中任一种可能实现方式中的方法。

可选地，作为一种实现方式，芯片还包括存储器，存储器中存储有计算机程序或指令，处理器用于执行存储器上存储的计算机程序或指令，当计算机程序或指令被执行时，处理器用于执行上述第一方面或第二方面或第三方面或第四方面或第五方面或第六方面以及第一方面或第二方面或第三方面或第四方面或第五方面或第六方面中任一种可能实现方式中的方法。

第十五方面，提供一种通信系统，该通信系统包括第九方面以及第十方面所示的通信装置。

附图说明

图1为本申请实施例提供的一种基于NFV的网络架构的示意图。

图2是本申请提出的一种部署VNF的方法的示意性流程图。

图3是本申请提出的另一种部署VNF的方法的示意性流程图。

图4是应用本申请图2和图3所示的方法实现VNF1和VNF2的部署的示意图。

图5是应用本申请图3所示方法实现资源扩展诉求的示意图。

图6是应用本申请图2所示的方法实现部署差异化诉求的示意图。

图7是本申请提出的一种在第一VNF实例化过程中应用标签扩展机制的示意图流程图。

图8是本申请提出的一种在第一VNF重调整或扩容过程中应用标签扩展机制的示意图流程图。

图9是本申请提出的又一种部署VNF的方法的示意性流程图。

图10是本申请提出的一种对多个同一类型的节点的标签进行配置的示意性流程图。

图11为本申请提供的通信装置100的示意性框图。

图12为本申请提供的通信装置200的示意性结构图。

具体实施方式

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

图1为本申请实施例提供的一种基于NFV的网络架构的示意图。如图1所示，该网络架构包括：网络功能虚拟化编排器(Network Function Virtualization Orchestrator，NFVO)102、虚拟化网络功能管理器(Virtualized Network Function Manager，VNFM)104、虚拟化基础设施管理器(Virtualized Infrastructure Manager，VIM)106、网络功能虚拟化基础设施(Network Function Virtualization Infrastructure，NFVI)、虚拟化网络功能(Virtualized Network Function，VNF)108和网元管理系统(Element Manager System，EMS)110，其中，NFVO102、VNFM104和VIM106属于NFV系统的管理编排(Management andOrchestration，MANO)，MANO的相关功能可以通过硬件实现，也可以通过软件实现。下面，分别对上述网元进行简要介绍。

NFVO102，实现网络服务描述符(Network Service Descriptor，NSD)、虚拟网络功能描述符(Virtualized Network Function Descriptor，VNFD)、虚拟网络功能转发图(Virtualized Network Function Forwarding Graph，VNFFG)的管理，网络服务(NetworkService，NS)生命周期的管理，和资源的全局视图功能。主要负责处理虚拟化业务的生命周期管理，以及NFVI中虚拟资源的分配和调度等。NFVO102可以与一个或多个VNFM104通信，以执行资源相关请求，发送配置信息给VNFM104。收集VNF108的状态信息。另外，NFVO102也可与VIM106通信，执行资源分配，和/或预留，交换虚拟化硬件资源配置和状态信息。

VNFM104，负责一个或多个VNF108的生命周期管理，比如实例化(instantiating)，更新(updating)，查询，弹性伸缩(scaling)，终止(terminating)VNF108。VNFM104可以与VNF108通信以完成VNF生命周期管理及交换配置和状态信息。在NFV架构中VNFM104可以有多个，负责对不同类型的VNF进行生命周期管理。

VIM106，即虚拟化基础设施管理器，控制和管理VNF108与计算硬件112，存储硬件114，网络硬件116，虚拟计算118，虚拟存储120，虚拟网络122的交互。例如VIM106执行资源管理功能，包括管理基础设施资源、分配(例如增加资源给虚拟容器)及运行功能(例如收集NFVI故障信息)。VNFM104及VIM106可以相互通信，请求资源分配，交换虚拟化硬件资源配置和状态信息。

VNF108，也可称之为虚拟化网元，对应于传统的非虚拟化网络中的物理网络功能。网络功能的功能性行为和状态与网络功能的虚拟化与否无关。通过使用X86等通用性硬件以及虚拟化技术，来承载很多功能的软件处理，从而降低网络昂贵的设备成本。

EMS110，是传统电信系统中用于对设备进行配置，管理的系统，在NFV架构中，EMS110也可以用于对VNF进行配置和管理，以及向VNFM发起新的VNF的实例化等生命周期管理操作。

NFVI，即NFV的基础设施层，包含硬件部件，软件部件或两者组合，以建立虚拟化环境，部署，管理及实现VNF108。硬件资源和虚拟化层用于为VNF108提供虚拟化资源，如虚拟机和其他形式的虚拟容器。硬件资源包括计算(computing)硬件112，存储硬件114，网络硬件116。可选地，计算硬件112和存储硬件114的资源可以集中在一起。NFVI中的虚拟化层可以抽象硬件资源，解耦VNF108与底层的物理网络层。

OSS/BSS124，支持各种端到端电信业务。OSS支持的管理功能包括：网络配置，业务提供，故障管理等。BSS处理订单，付费，收入等，支持产品管理，订单管理，收益管理及客户管理。

为了便于理解本申请，在介绍本申请提供的方法之前，首先对本申请涉及的概念和技术做简要介绍。

1、云计算(cloud computing)：一种基于互联网的计算新方式，通过互联网上异构、自治的服务为个人和企业用户提供按需即取的计算。云计算包含三个层次的服务：基础设施即服务(IaaS)、平台即服务(platform as a service，PaaS)和软件即服务(softwareas aservice，SaaS)。其中，PaaS是把服务器平台作为一种服务提供的商业模式，实际上是指将软件研发平台作为一种服务，以SaaS的模式提交给用户。

2、容器(container)：一种操作系统级别的虚拟化技术，通过操作系统隔离技术将不同的进程隔离开来。用于将应用与其所有必要文件捆绑到一个运行时环境中的技术。作为一个单元，容器可以在任何环境下的任何操作系统上轻松移动和运行。

3、容器即服务(container as a service，CaaS)：是一种特定类型的PaaS。

4、Kubernetes(K8S)：谷歌(Google)开源的容器集群管理系统，构建于docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩缩容等一整套功能，也就是说，K8S是负责自动化运维管理多个Docker程序的集群，本质上可看作是基于容器技术的迷你CaaS(mini-CaaS)管理器。

5、虚拟(virtual machine，VM)容器：基于虚拟机部署的容器化系统；包括虚拟化基础设施、容器化管理平台、及网元VNF。

6、裸机(bare metal)容器：基于裸机部署的容器化系统；包括裸机基础设施、容器化管理平台、及网元VNF。

7、主机组(host aggregate，HA)：OpenStack部署模型下的一个逻辑概念，表示一组计算单板(host)集合及其相关元数据。通常，体系结构相同(如X86或ARM体系)、规格均质(如2*32Core或者2*64Core等)的一组单板规划到一个HA资源池下。本申请中单板也可以理解为主机(host)，单板和主机在本申请中可以相互替换。

8、节点(Node)：用于部署应用或服务的工作节点，可以是虚拟机VM或者是裸机host。K8S的节点，在虚拟机容器场景下对应为VM，在裸机容器场景下对应为host。可以理解的是，当本实施例应用于其他容器管理平台或系统时，节点可以理解为相应平台或系统中的工作节点，此处不作限定。

9、最小部署单元(Pod)：K8S创建或部署的最小/最简单的基本单位，一个Pod对应一个应用的实例，部署在一个节点上。Pod可以包括一个或一组容器，它们之间共享资源。其中，HA，Node和Pod的关系为，一个HA可以包含多个Node，一个Node上面可以部署多个Pod。

10、K8S模板：Kubernetes社区对应的容器化部署模板文件。

11、VNFD模板：用于部署VNF的模板文件。VNFD的模板可以引用K8S模板，以及Helm模板等容器化部署扩展模板。

VNFD模板包括VNF的信息和VNF的部署单元信息。VNF的信息也可以理解为VNF的属性，例如包括VNF的类型。VNF的部署单元信息可以理解为VNF的部署单元的属性，例如包括部署单元的数量以及部署单元对待部署节点的属性要求(或者说部署单元对待部署节点的标签诉求)。

12、虚拟部署单元(virtual deployment unit，VDU)：基于VNFD模板，虚拟机场景下“VDU对象”指的是一个VM；容器场景下“VDU对象”可以指Pod。进一步，当VDU为Pod时，可以使用VNFD模板中的参数指明是虚拟机容器还是裸机容器。

应理解，VDU是VNF的一种部署单元，实例化VNF的过程也就是将VNF的一个或多个部署单元部署到相应的节点上。本申请实施例对VNF的部署单元的类型不作限定。

13、容器化部署扩展模板：除K8S模板外的、由社区或各设备供应商自行提供的容器化部署模板，比如Helm模板或者TOSCA模板。相对K8S模板而言，扩展模板会做一些定制化增强功能。常见的设备供应商采取的CaaS管理器一般都支持使用扩展模板。

14、标签(labels)：也称为节点标签，用于描述节点的属性，节点的标签例如包括附加到节点上的键值对(KEY/VALUE)。

为便于理解本申请实施例，下面对VNF的容器化部署过程进行介绍。

一种可能的具体VNF部署过程如下所示。

步骤1：通过容器化部署平台完成节点的创建及节点标签的配置。

其中，虚机容器场景，Pod调度对象VM随VNF动态创建并配置标签。裸机容器场景，Pod调度对象Host采取预先规划并配置标签。

步骤2：通过VNFD所包括的容器化部署模板，描述需要部署的Pod的个数，以及Pod对待部署节点的标签诉求。

步骤3：CaaS管理器根据每个Pod对待部署节点的标签诉求将Pod调度至匹配的节点。

示例的，通过VNFD中的容器化部署模板描述一个名称(name)为nginx的Pod对待部署节点的标签诉求如下所示：

可以看出，在上述模板中，名称为nginx的pod需要调度到符合匹配表达式(matchExpressions)的节点上面。该匹配表达式中包括两个标签，每个标签对应一个键值对，两个键值对分别为键值对key1/value和键值对key2/value。

应理解，上述模板中每个键值对中value的取值个数是固定的，为便于描述，如果一个键值对的VALUE有N个取值，本申请可以理解为该键值对对应N个VALUE，每个VALUE相应的只能有一个取值。示例性的，键值对key1/value中键key1的取值为disktype，键值对key1/value中包含两个值value，一个value的取值为ssd，另一个value的取值为normal。键值对key2/value中键key2的取值为mem，键值对key2/value包含两个值value，其中一个value的取值为2M，另一个value的取值为mem。

符合匹配表达式的节点同时具有如下特点：

1)该节点上同时具备key的取值为disktype和mem的标签。

2)该节点上key的取值为disktype的标签，对应的value的取值为{ssd,normal}中的一个。

3)该节点上key的取值为mem的标签，对应的value的取值为{2M,mem}中的一个。

在容器化场景下，基于现有的Pod对待部署节点的诉求和节点标签的匹配机制，由于模板内表达Pod对节点标签的诉求方式，是比较固定的，因此，无法满足更加广泛的部署调度诉求。该问题也类似的存在于非容器化场景下的VDU(即VM)部署过程，也存在于VNF其他部署单元的部署过程中。

有鉴于此，本申请提出一种部署虚拟化网络功能的方法，能够有效解决上述技术问题。

图2是本申请提出的一种部署VNF的方法的示意性流程图。该方法可以包括以下步骤。

S210，第一网元获取第一VNFD模板。

第一VNFD模板用于部署第一VNF的部署单元。也就是说，第一VNFD模板用于将第一VNF的部署单元部署到相应匹配的节点上，具体可见S240的内容。此处的部署可以指初次实例化该第一VNF时将第一VNF的部署单元部署到相应节点，也可以指在第一VNF已实例化一个或多个部署单元之后，在第一VNF下增加部署单元，使用第一VNFD模板将新增的部署单元部署到相应匹配的节点上，也就是扩容该第一VNF，也可以指在第一VNF已实例化之后改变第一VNF的部署单元所部署的节点，也就是重部署该第一VNF。部署第一VNF的部署单元也可以理解为部署第一VNF。

具体的，一个VNFD模板中，具体包括属性名称和该属性的取值。一个属性名称和该属性的取值可以理解为一个键值对，键值对的键(KEY)的取值为属性名称，键值对的值(VALUE)的取值为属性的取值。也就是说，VNFD模板可以包括一个或多个键值对，一个键值对的键KEY的取值可以指示要部署的VNF的pod的一种属性，该键值对的值VALUE的取值指示该属性的具体的取值。例如上述示例的包括键值对key1/value和键值对key2/value的VNFD模板中，VNF的部署单元对待部署节点的属性要求包括：第一属性和第二属性，其中，第一属性为disktype：ssd或disktype：normal(即键值对key1/value的取值)，第一属性为mem：2M或mem：mem(即键值对key2/value的取值)。本申请实施例对实现上述键值对的具体方式(例如数据结构)不作限定。

可选地，VNFD模板可以不包括键值对的具体取值，或，VNFD模板可以包括键值对的初始取值或者默认取值。在部署第一VNF时，第一网元可以通过不同方式获得VNFD模板的实际取值或更新VNFD模板中的初始值，具体可见S220步骤。具体的，第一网元可能获取多个VNFD模板，其中包括第一VNFD模板；第一网元获取部署第一VNF的需求后，选择第一VNFD模板来部署该第一VNF。

可选地，第一网元为VNFM或NFVO。需要说明的是，当第一网元为NFVO时，NFVO需要将获取到的信息发送给VNFM，VNFM再发送给CaaS管理器，实际与CaaS管理器进行交互的网元为VNFM。

本实施例中，后续以部署单元为Pod为例对方案进行介绍。可以理解的是当部署单元为VM或者为其他形式的VDU，仍可适用本方案。

S220，第一网元获取第一VNFD模板中键值对的第一取值。

该实施例中，第一VNFD模板中的键值对包括多个键值对，多个键值对中包括第一键值对，第一网元获取的键值对的第一取值中包括第一键值对的取值，该第一键值对的取值用于指示该第一键值对不作用于部署第一VNF的Pod。其中，不作用于部署第一VNF的Pod也可以理解为在为第一VNF的Pod匹配待部署节点时忽略第一VNFD模板中的第一键值对。

可选地，第一键值对取值可以是第一键值对中键KEY的取值或第一键值对中值VALUE的取值。示例的，第一键值对取值可以有多种表达形式，如包含但不限于“NONE”、“NULL”、或者“NA”等。这种取值可以理解为无效取值或者空取值。

需要说明的是，当一个键值对中包含多个值VALUE时，只要其中一个值VALUE的取值为NONE，则表示该键值对不作用于部署第一VNF的Pod。

可以理解，当第一网元获取第一VNFD模板中包括第一键值对在内的多个键值对的取值时，第一取值指的是第一键值对的空取值和其他键值对的实际取值；当第一网元仅获取第一键值对的空取值，第一取值指的是该空取值。此处的取值可以理解为键值对中键KEY和/或值VALUE的取值。可选的，若第一网元没有获取第一VNFD模板中部分键值对的取值，这部分键值对的取值采用初始值或者默认值。

可选地，操作人员在第一网元的部署界面输入第一取值，第一网元获取第一取值。

示例性的，第一VNFD模板包括两个键值对，第一键值对的取值为key1:value1-1，第二键值对的取值为key2:value2-1，如果根据第一VNFD模板中两个键值对的取值为第一VNF的Pod匹配待部署节点，则待部署节点需要与两个键值对的取值相匹配；如果获取到第一键值对的键KEY的取值为NONE，或，获取到第一键值对的值VALUE的取值为NONE，则表示在为第一VNF的Pod匹配待部署节点时忽略第一VNFD模板中的第一键值对，待部署节点的标签只要与第二键值对匹配即可。

可以理解，当前VNFD模板内表达Pod对节点标签的诉求方式，是比较固定的。这种固定体现在，VNFD模板中Pod的MatchExpressions(匹配表达式)的键值对的个数是固定的且每个键值对都要能与Pod待部署节点的标签匹配上，Pod才能往该节点进行调度，否则Pod不能往该节点进行调度。在上文示例的名称(name)为nginx的Pod的标签诉求中，该Pod对应两个key，且这两个key的键值对必须都能匹配上，才能完成Pod往对应节点的调度。在只发布一套模板情况下，无法实现一个VNF部署时disktype和mem两个键值对只生效一个，另一个VNF部署时disktype和mem两个键值对同时生效。而基于键值对的是否为空取值来控制键值对是否生效，不再要求VNFD模板内描述的所有键值对都去实际匹配，即VNFD模板内键值对个数虽然固定，但实际参与匹配调度的键值对个数却可通过控制键值对的实际取值是否为空取值来灵活控制。

S230，第一网元根据第一VNFD模板和第一取值，向CaaS管理器发送第一请求消息。对应的，CaaS管理器接收来自第一网元的第一请求消息。对应的，CaaS管理器接收来自第一网元的第一请求消息。

其中，该第一请求消息用于请求在满足第一VNFD模板和模板中键值对的第一取值的节点上部署第一VNF的Pod。

可选的，第一请求消息包括上述第一VNFD模板和第一取值；或者，第一请求包括第一VNFD模板的索引和第一取值，CaaS管理器可以根据该索引获取第一VNFD模板。

S240，CaaS管理器根据第一请求消息部署第一VNF的Pod。

具体的，部署Pod的节点的标签需要与第一VNFD模板中的键值对的取值相匹配，具体可参考前述示例的内容例如前述VNF的容器化部署过程，此处不再赘述。

特别的，CaaS管理器通过第一键值对的取值获知第一键值对不作用于第一VNF的Pod的部署，因此在选择节点时仅考虑第一VNFD模板中除第一键值对外的其他键值对，也就是选择节点标签与第一VNFD模板中其他键值对的取值相匹配的节点，而不需要考虑节点标签与第一键值对的取值是否匹配。

可选的，S250，CaaS管理器向第一网元发送第一请求响应消息，第一请求响应消息指示第一VNF的Pod部署成功。对应的，第一网元接收来自CaaS管理器发送的第一请求响应消息。

上述技术方案中，可以通过VNFD模板中的键值对的取值来控制该键值对是否生效，该机制可以基于一套模板满足不同局点的部署诉求，使得模板发布更加简洁且适应性更强。

可选的，上述第一请求消息可以用于实例化(或者说首次部署)第一VNF，相应的，CaaS管理器在收到第一请求消息后为第一VNF选择相应的节点以部署第一VNF的Pod。或者，第一请求消息用于重部署第一VNF，相应的，CaaS管理器在收到第一请求消息后为第一VNF重新选择相应的节点以部署第一VNF的Pod；或者第一请求消息用于扩容第一VNF，相应的，CaaS管理器在收到第一请求消息后为第一VNF匹配满足条件的节点以部署扩容的第一VNF。可以理解，扩容部署是指增加部署第一VNF的pod，例如，第一VNF之前已经实例化部署了10个Pod，后面基于实际需求，第一请求消息请求部署在第一VNF下新增的10个Pod，CaaS管理器基于第一请求消息将新增的10个Pod部署到满足条件的节点上以实现扩容部署第一VNF。

可以理解，当第一请求消息用于请求扩容部署或者重部署第一VNF，在S220之前，已有属于第一VNF的Pod已部署在相应的节点上，也就是说在S220之前还包括以下流程：

S2201，第一网元获取第一VNFD模板中键值对的第二取值，第二取值中第一键值对的值与第一取值中第一键值对的取值可以不同，例如，第二取值中第一键值对的取值用于指示第一键值对作用于部署第一VNF的部署单元，即第二取值中第一键值对的取值不是空值，第一键值对的取值需要与第一VNF的pod的待部署节点的标签匹配，从而通过第一取值表达变化后的第一VNF的部署诉求。

S2202，第一网元根据第一VNFD模板和第二取值，向CaaS管理器发送第二请求消息。该第二请求消息用于请求在满足第一VNFD模板和模板中键值对的第二取值的节点上部署第一VNF的Pod。对应的，CaaS管理器接收来自第一网元的第二请求消息。

S2203，CaaS管理器在满足第一VNFD模板和第二取值的节点上部署第一VNF的Pod。可选的，CaaS管理器向第一网元发送第二请求响应消息，第二请求响应消息指示第一VNF的Pod部署成功。

上述流程具体可参考上述对S220至S250的具体介绍。特别的是，上述第二取值可以包括一个或多个键值对的空取值，也可以不包括任何键值对的空取值(也就是第二取值包括的都是需要作用于部署第一VNF的Pod的取值)。当第二取值不包括任何键值对的空取值，上述流程具体还可参考现有VNF的Pod的部署流程。

上述技术方案中，VNF在首次部署后，当VNF部署诉求发生变化，例如需要扩容或者重部署，基于上述方案有可以仍然沿用VNF首次部署时的VNFD模板，通过控制VNFD模板中键值对的取值来控制键值对是否生效，从而在选择待部署节点时引入更多属性限制或者减少属性限制，以改变或新增待部署节点，满足部署诉求的变化。

可选的，上述第一请求消息可以包括第三VNFD模板和第三VNFD模板中一个或多个键值对的第三取值。也就是说，第一网元在获取上述第一VNFD模板和第一取值后，根据第一键值对的取值获知第一键值对不作用于部署第一VNF的Pod，然后第一网元不向CaaS管理器传递第一键值对，而是向CaaS管理器传递第一VNFD模板中除第一键值对以外的信息以及第一取值中除第一键值对的取值以外的取值。上述第一VNFD模板中除第一键值对以外的信息，在本申请实施例中称为第三VNFD模板，也就是该第三VNFD模板为第一VNFD模板且不包含该第一键值对。上述第一取值中除第一键值对的取值以外的取值，在本申请实施例中称为第三取值，也就是该第三取值为上述第一取值且不包含第一键值对的取值。示例的，第一VNFD模板包括第一键值对和第二键值对，第一取值包括第一键值对的取值key1:NONE，以及第二键值对的取值value2-1，可以理解为第三VNFD模板包括第二键值对，而不包括第一键值对，相应的，第三取值包括第二键值对的取值，而不包括第一键值对的取值，即第三取值为第二键值对的取值key2:value2-1。

当第一请求消息包括第三VNFD模板和第三取值，上述S240可以替换为：CaaS管理器在满足第三VNFD模板和第三取值的节点上部署第一VNF的Pod。可以理解的是，与原S240步骤不同的是，此时，CaaS管理器不需要识别哪些键值对的取值为空取值，也就是CaaS管理器采用现有技术已有的节点选择方案即可。

上述技术方案中，可以通过VNFD模板中的键值对的取值来控制该键值对是否生效。第一网元识别到取值为空取值的键值对之后，不向CaaS管理传递该键值对和该键值对的取值，从而使CaaS管理器不获取该键值对的信息，在选择待部署节点时不会引入该键值对对节点的属性要求。该机制可以基于一套模板满足不同局点的部署诉求，使得模板发布更加简洁且适应性更强。

图3是本申请提出的另一种部署VNF的方法的示意性流程图。该方法可以包括以下步骤。

S310，第一网元获取第一VNFD模板。第一VNFD模板用于部署第一VNF的部署单元，第一VNFD模板包括一个或多个键值对，其中，一个或多个键值对中的第一键值对的第一值的取值的数量是可变的。

其中，第一值的取值的数量是可变的，可以理解为第一值的取值的数量可以根据实际需求进行更改。

可选地，第一值的取值为多个取值时，多个取值中相邻的两个取值之间通过第一字符串接。示例的，第一字符包括但不限于“/”或“；”或“、”等。

可以理解，现有模板要求每个键值对中的VALUE的取值个数是固定的，即每个键值对中VALUE的取值个数是固定为1个。例如，在上文示例的名称(name)为nginx的Pod对待部署节点的标签诉求中，该Pod的待部署节点的标签需要与第一键值对key1/value的取值和第二键值对key2/value的取值匹配，每个键值对都包括两个VALUE，每个VALUE只能有一个取值，即现有模板中一个VALUE对应的取值个数不能灵活的增加。那么，示例的，在只发布一套VNFD模板的情况下，无法实现在第一键值对的两个VALUE的取值数量分别为1的情况下，将第一键值对的两个VALUE的取值更新为{2M,1G,mem}，即无法实现第一键值对的值的取值个数从2变成3。而本申请提出的方法可以实现将第一键值对的两个VALUE的取值更新为{2M,1G,mem}，例如，将第二键值对key2/value中第一个VALUE的取值更新为{2M,1G}，第二个VALUE的取值的取值保持不变(即仍为men)；或者，将第二键值对key2/value中第一个VALUE的取值保持不变(即仍为2M)，第二个VALUE的取值更新为{1G,mem}；或者，将第二键值对key2/value中第一个VALUE的取值更新为{2M,mem}，第二个VALUE的取值更新为{1G}，本申请对实现方式不做限定，这里不再一一赘述。可以看出，该方法中，VNFD模板中第一键值对的VALUE的个数并没有增加，但是VALUE的取值的个数却可以根据实际需求增加。同S210中的描述，第一VNFD模板用于部署第一VNF的部署单元，也就是说，第一VNFD模板用于将第一VNF的部署单元部署到相应的匹配的节点上。此处的部署可以指初次实例化该第一VNF时将第一VNF的部署单元部署到相应节点，也可以指在第一VNF已实例化一个或多个部署单元之后，将在第一VNF下增加部署单元，使用第一VNFD模板将新增的部署单元部署到更多相应匹配的节点上，也就是扩容该第一VNF，也可以指在第一VNF已实例化之后改变第一VNF的部署单元所部署的节点，也就是重部署该第一VNF。部署第一VNF的部署单元也可以理解为部署第一VNF。

具体的，一个VNFD模板中，包括一个或多个键值对，一个键值对的键KEY的取值指示要部署的VNF的pod的一种属性，该键值对的值VALUE的取值指示该属性的具体的取值。例如上述示例的包括键值对key1/value和键值对key2/value的VNFD模板中，VNF的部署单元对待部署节点的属性要求包括：第一属性和第二属性，其中，第一属性为disktype：ssd或disktype：normal(即键值对key1/value的取值)，第一属性为mem：2M或mem：mem(即键值对key2/value的取值)。本申请实施例对实现上述键值对的具体方式(例如数据结构)不作限定。

可选地，VNFD模板可以不包括键值对的具体取值，或，VNFD模板可以包括键值对的初始取值或者默认取值。在部署第一VNF时，第一网元可以通过不同方式获得VNFD模板的实际取值或更新VNFD模板中的初始值，具体可见S320步骤。具体的，第一网元可能获取多个VNFD模板，其中包括第一VNFD模板；第一网元获取部署第一VNF的需求后，选择第一VNFD模板来部署该第一VNF。

可选地，第一网元为VNFM或NFVO。需要说明的是，当第一网元为NFVO时，NFVO需要将获取到的信息发送给VNFM，VNFM再发送给CaaS管理器，实际与CaaS管理器进行交互的网元为VNFM。

本实施例中，后续以部署单元为Pod为例对方案进行介绍。可以理解的是当部署单元为VM或者为其他形式的VDU，仍可适用本方案。

S320，第一网元获取第一VNFD模板中键值对的第一取值。

第一取值包括第一值的取值构成的第一取值集合，第一取值集合中包括N个取值，N为正整数。

可以理解，当第一网元获取第一VNFD模板中包括第一键值对在内的多个键值对的取值时，第一取值指的是第一取值集合和其他键值对的实际取值；当第一网元仅获取第一键值对的第一值的取值，第一取值指的是第一取值集合。此处的取值可以理解为键值对中键KEY和/或值VALUE的取值。可选的，若第一网元没有获取第一VNFD模板中部分键值对的键或值的取值，这部分取值采用初始值或者默认值。

可选地，操作人员在第一网元的部署界面输入第一取值，第一网元获取第一取值。

S330，第一网元根据第一VNFD模板和第一取值，向CaaS管理器发送第一请求消息。对应的，CaaS管理器接收来自第一网元的第一请求消息。对应的，CaaS管理器接收来自第一网元的第一请求消息。

其中，该第一请求消息用于请求在满足第一VNFD模板和模板中键值对的第一取值的节点上部署第一VNF的Pod。

可选的，第一请求消息包括上述第一VNFD模板和第一取值；或者，第一请求包括第一VNFD模板的索引和第一取值，CaaS管理器可以根据该索引获取第一VNFD模板。

S340，CaaS管理器根据第一请求消息部署第一VNF的Pod。

具体的，部署Pod的节点的标签需要与第一VNFD模板中的键值对的取值相匹配，具体可参考前述示例的内容例如前述VNF的容器化部署过程，此处不再赘述。

应理解，如果第一键值对的第一值的取值为多个取值时，则第一键值对下将产生多组键值对取值，在进行匹配节点时，只要多组键值对取值中只要有一组键值对取值与待部署节点的标签匹配即可。示例的，第一键值对的键的取值为men，第一键值对的值只包括一个第一值，第一值的取值为{2M,1G,mem}，则第一键值对下将产生men：2M、men：1G和men：men这3组键值对取值，那么在实际匹配值，对于该键值对来说，只要3组键值对取值中只要有一组键值对取值与待部署节点的标签匹配即可。

可选的，S350，CaaS管理器向第一网元发送第一请求响应消息，第一请求响应消息指示第一VNF的Pod部署成功。对应的，第一网元接收来自CaaS管理器发送的第一请求响应消息。

上述技术方案中，支持一个键值对的一个值可以有多个取值，该方法可以实现比较灵活的跨资源池扩展诉求，扩展调整方式可以最大程度的减小业务中断，且资源池扩展方式，不会对存量资源池规划造成影响。

可选的，上述第一请求消息可以用于实例化(或者说首次部署)第一VNF，相应的，CaaS管理器在收到第一请求消息后为第一VNF选择相应的节点以部署第一VNF的Pod。或者，第一请求消息用于重部署第一VNF，相应的，CaaS管理器在收到第一请求消息后为第一VNF重新选择相应的节点以部署第一VNF的Pod；或者第一请求消息用于扩容第一VNF，相应的，CaaS管理器在收到第一请求消息后为第一VNF匹配满足条件的节点以部署扩容的第一VNF。

可以理解，当第一请求消息用于请求扩容部署或者重部署第一VNF，在S320之前，已有属于第一VNF的Pod已部署在相应的节点上，也就是说在S320之前还包括以下流程：

S3201，第一网元获取第一VNFD模板中键值对的第二取值，第二取值包括第一键值对的第一值的取值构成的第二取值集合，第二取值集合包含M个取值，M为正整数，且M和第一取值集合的取值个数N不相同。

作为示例，在请求重部署第一VNF之前，第一VNFD模板中第一键值对的第一值的取值集合为{value1-1，value1-2}(即第二取值集合的一例)，之后，因为重部署诉求，需要将第一值的取值在原先的取值基础上增加一个新的取值value1-3，即更新后的第一值的取值集合为{value1-1，value1-2，value1-3}(即第二取值集合的一例)。

S3202，第一网元根据第一VNFD模板和第二取值，向CaaS管理器发送第二请求消息。该第二请求消息用于请求在满足第一VNFD模板和模板中键值对的第二取值的节点上部署第一VNF的Pod。对应的，CaaS管理器接收来自第一网元的第二请求消息。

S3203，CaaS管理器在满足第一VNFD模板和第二取值的节点上部署第一VNF的Pod。

可选的，CaaS管理器向第一网元发送第二请求响应消息，第二请求响应消息指示第一VNF的Pod部署成功。

上述流程具体可参考上述对S320至S350的具体介绍。

上述技术方案中，VNF在首次部署后，当VNF部署诉求发生变化，例如需要扩容或者重部署，基于上述方案有可以仍然沿用VNF首次部署时的VNFD模板，通过更新VNFD模板中键值对的值的取值个数可以扩大Pod对部署节点的选择范围，从而实现比较灵活的跨资源池扩展诉求，扩展调整方式可以最大程度的减小业务中断，且资源池扩展方式，不会对存量资源池规划造成影响，满足部署诉求的变化。

下面结合图4举例说明通过图2和图3所示的方法实现VNF1和VNF2的部署。

其中，VNF1和VNF2是同一种类型VNF的两个不同实例，VNF1和VNF2使用同一VNFD模板进行实例化部署，VNF1的3个Pod的部署诉求(即VNFD模板中的两个键值对的取值)为key1:value1-1和key2:NONE，VNF2的3个Pod的部署诉求(即VNFD模板中的两个键值对的取值)为key1:value1-1/value1-2和key2:value2-2。节点1和节点2的标签为key1:value1-1，key2:value2-1，节点3和节点4的标签为key1:value1-1，key2:value2-2，节点5和节点6的标签为key1:value1-2，key2:value2-2。

那么，VNF1的3个Pod在部署时可以忽略key2:NONE，待部署VNF1的3个Pod的节点的标签只需要与key1:value1-1匹配即可，那么，VNF1的3个Pod可以分别部署在节点1、节点2和节点3上，VNF2的3个Pod在部署时，节点不仅需要与key2:value2-2匹配，还需要与key1:value1-1/value1-2中key1:value1-1和key1:value1-2这2个配对结果中任一配对结果匹配，那么，VNF2的3个Pod可以分别部署在节点4、节点5和节点6上。

除了基本部署能力以外，通过通过图2和图3所示的方法还能实现资源扩展诉求和部署差异化诉求。下面结合图5和6举例具体说明。

(1)实现资源扩展诉求

如图5所示，由于VNF1、VNF2、VNF3的Pod在VNFD模板中的部署诉求均为key1:value1，资源池1中的任一节点的标签也为key1:value1，资源池2中的任一节点的标签为key1:value2，因此基于Pod的部署诉求和节点标签的匹配原则，VNF1、VNF2、VNF3只能基于资源池1部署，无法调度到资源池2上面去。如果一些VNF(如VNF2)之后有扩容诉求，但发现原有资源池1的容量已经无法再满足VNF扩容，此时就需要考虑让有扩容诉求的VNF，进行跨资源池扩展(如扩容出的pod直接调度到资源池2上面去)。

如果使用现有技术解决上述诉求，可能需要将资源1再次扩大；或者，创建一个新VNF3用来接替原VNF2业务后，再将VNF2卸载等。

但是基于本申请中提出的标签列表可选模型，可以很容易解决上述问题。如图5所示，对于需要进行跨资源池扩展的VNF2，只需要将VNF2扩展模板内待部署的扩容Pod对应的键值对的取值key1:value，从原有取值key1:value1更新为key1:value1/value2，这样即可实现key1的取值从模板中固定个数1变为2个。可以看出，按照图3所示方法，更新键值对的值VALUE的取值后，可以用于VNF2的Pod调度的资源池范围，将从资源池1变为资源池1和资源池2。而且，原资源池1下运行的VNF2的Pod始终与所在节点的标签匹配，因此不会造成VNF2下的已成功部署的Pod故障或业务中断。

(2)实现部署差异化诉求。

图6所示，VNF1、VNF2、VNF3是同一种类型VNF的三个不同实例。其中VNF3基于整个资源池1部署，VNF1和VNF2需要在资源池1内尽量集中部署，例如部署在一个更小的资源池2内，其中，资源池1中的任一节点的标签为key1:value1，资源池2中的任一节点的标签为key1:value1和key2:value2。这种部署目的，一方面是为了控制VNF1和VNF2的部署范围，另一方面让VNF3共享资源池1内剩余的资源碎片，提升资源池1的资源利用率。

如果使用现有技术解决上述诉求，可能需要为一种类型的VNF发布多套局点定制化VNFD模板。如为了满足VNF1和VNF2的部署诉求，需要发布一套包括两个键值对的VNFD模板(即Pod通过2个键值对的取值key1:value1和key2:value2来选择节点)。为满足VNF3的部署诉求，需要发布另一套包括一个键值对的VNFD模板(Pod通过1个键值对的取值key1:value1来选择节点)。

但是基于本申请中图2提出的方法，可以使用一套VNFD模板解决上述问题。对该类型VNF可以采取包含N个键值对(N≥2)的VNFD模板。具体的，如图6所示，在部署VNF1和VNF2时配置模板中N个键值对中的两个键值对的取值为key1:value1；key2:value2，并将其他不需生效的键值对的取值配置为无效取值，则VNF1和VNF2这两个VNF实例对应的Pod只能在资源池2上调度。在部署VNF3时配置模板中N个键值对的一个键值对的取值为key1:value1，并将其他不需生效的键值对的取值配置为无效取值，则VNF3的Pod允许在整个资源池1上调度。

可以看出，在上述操作过程中，始终都是基于一套VNFD模板来实现不同部署诉求的，因此扩展后的模板的适应性非常强。理论上不管该类型VNF的多实例间面临的部署差异(引发因素可能是局点内不同VNF实例间部署要求不一致、也可能是不同运营商/客户部署诉求不一致等)有多大，只要事先考虑清楚各种场景，在VNFD模板内通过不同的键值对预埋所有可能的部署影响因素即可。待到具体局点实例化VNF时，基于该一套VNFD模板通过键值对取无效取值的方法选择性忽略掉本次部署的无关因素，即可实例化出来满足部署要求的VNF实例。

下面结合不同场景对图2和图3所示方法可能的具体实现流程进行描述。为便于描述，下面图7和图8中以第一网元为VNFM为例进行说明。

图7是本申请提出的一种实例化第一VNF的示意性流程图。该方法包括以下步骤。

S701，操作人员通过VNFM部署界面向CaaS管理器发送实例化第一VNF所必需的VNF软件包。

其中，该软件包包括容器镜像文件和VNFD模板，本申请中软件包包括的VNFD模板可以理解为出厂设置的原始VNFD模板。可选地，VNFD模板可以不包括键值对的具体取值，或，VNFD模板可以包括键值对的初始取值或者默认取值。

S702，操作人员通过VNFM的部署界面触发第一VNF实例化请求。

应理解，当触发第一VNF实例化的过程中，需要使用前述步骤上传的软件包。在第一VNF实际部署时，可以基于部署局点及网设规划的实际情况，指明第一VNF的Pod实际所需的实例数及这些Pod对待部署节点真实的标签诉求。

具体地，操作人员在VNFM部署界面基于原始VNFD模板，输入该模板中给定的输入(input)参数的取值后获得第一VNF的实际部署模板，该第一VNF的实际部署模板能够表达出第一VNF需要部署的Pod实例数及这些Pod对待部署节点的标签诉求。应理解，Pod对待部署节点的标签诉求通过VNFD模板中的键值对的取值进行表达。后文涉及相同地方不再赘述。为便于描述，后面将该第一VNF的实际部署模板称为模板#1。

示例的，操作人员根据第一VNF的实际部署诉求，输入或修改VNFD模板的输入参数的取值，指明第一VNF的Pod的实例数为3个，以及Pod对节点的标签诉求为key1:value1/value3和key2:NONE(即原始模板中键值对的取值)。关于两个键值对的取值的含义参见前文中的描述，这里不再赘述。

S703，VNFM向CaaS管理器发送第一请求消息，第一请求消息用于在满足模板#1要求的节点上部署第一VNF中的Pod。对应的，CaaS管理器接收来自VNFM的第一请求消息。

应理解，CaaS管理器在部署第一VNF时需要知道Pod的节点的标签诉求，因此，VNFM必须将Pod对节点的标签诉求信息传递给CaaS管理器。

可选地，第一请求消息包括模板#1。

可选地，第一请求消息包括原始模板的索引和模板#1中相关参数的取值。

可选地，当模板#1中的存在键值对的取值为无效取值时，第一请求消息包括一个新的部署模板，该新的部署模板为模板#1中去除键值对取值为无效取值的键值对以及该键值对的无效取值之后生成的模板。

S704，CaaS管理器部署第一VNF的Pod。

具体的，CaaS管理器根据第一VNF的实际部署模板，将模板中键值对的取值和节点标签进行一一匹配，将第一VNF的Pod调度到符合要求的节点上面去。

示例的，如果第一VNF的实际部署模板中一个键值对的键的取值为无效取值，则第一VNF的Pod匹配节点时忽略该键值对。如果第一VNF的实际部署模板中一个键值对的值的取值为无效取值，则第一VNF的Pod匹配节点时忽略该键值对。如果如果第一VNF的实际部署模板中一个键值对的值的取值包括多个取值，那么，该键值对下将产生多组键值对取值，在进行匹配节点时，只要多组键值对取值中只要有一组键值对取值与待部署节点的标签即可。

可选地，当CaaS管理器匹配到多个符合Pod标签诉求的节点时，CaaS管理器可以根据相应的策略(如随机选择、打分等)选择一个节点作为目标节点，并将Pod调度至目标节点。

S705，VNFM与CaaS管理器协作完成第一VNF的实例化。

具体的，VNFM确定第一VNF下所有Pod全部部署成功，则认为第一VNF部署成功，标识第一VNF的容器部署任务全部完成。

之后，VNFM可以在VNFM界面向用户显示已完成对第一VNF的实例化，以及第一VNF的部署结果。

图8是本申请提出的一种重部署或扩容第一VNF的示意性流程图。该方法包括以下步骤。

可以理解，该方法可以看做是在第一VNF实例化之后执行的操作。

S801，操作人员通过VNFM运维界面，修改第一VNF对待部署节点的标签诉求。

其中，修改第一VNF对待部署节点的标签诉求也可以理解为，替换或者修改第一VNF实例化部署时使用的VNFD模板中的一个或多个键值对的取值。为便于描述，这里将修改键值对取值后的得到的新的第一VNF的实际部署模板称为模板#2。

示例的，修改前的第一VNF实例化部署时使用的VNFD模板中第一VNF的Pod对节点的标签诉求为key1:value1和key2:value2，根据第一VNF的实施部署诉求，可以修改VNFD模板的键值对的取值，修改后的VNFD模板中Pod对节点的标签诉求为key1:value1/value3和key2:NONE。关于修改后的键值对的取值的含义这里不再赘述。

S802，VNFM向CaaS管理器发送第二请求消息，第二请求消息请求在满足模板#2的节点上重部署或扩容第一VNF的Pod。对应的，CaaS管理器接收来自VNFM的第二请求消息。

可选地，第二请求消息包括模板#2。

可选地，第二请求消息包括模板#2对应的原始模板的索引和模板#2中相关参数的取值。

可选地，当模板#2中的存在键值对的取值为无效取值时，第二请求消息包括一个新的部署模板，该新的部署模板为模板#2中去除键值对取值为无效取值的键值对以及该键值对的无效取值之后生成的模板。

可选地，第二请求消息请求在满足模板#2的节点上重部署第一VNF的Pod时，该方法还包括：

S803，CaaS管理器根据第二请求消息对第一VNF中已部署的Pod进行重部署。

示例的，如果第一VNF的Pod当前部署的节点的标签与刷新后的模板#2中的键值对的取值不匹配，则CaaS管理器根据模板#2选择匹配的节点完成第一VNF的Pod的部署调整。

示例的，如果第一VNF的Pod当前部署的节点的标签与刷新后的模板#2中的键值对的取值依然匹配，则CaaS管理器保持当前对VDU1的部署。

之后，VNFM可以在VNFM界面向用户显示已完成对第一VNF的部署调整，以及第一VNF的部署调整结果。

可选地，第二请求消息请求在满足模板#2的节点上扩容部署第一VNF的Pod时，该方法还包括：

S804，CaaS管理器根据第二请求消息将待扩容的第一VNF的Pod部署至匹配的节点上。

可选地，第二请求消息中包括待扩容的第一VNF的Pod的个数。

之后，VNFM可以在VNFM界面向用户显示已完成对第一VNF的扩容部署，以及第一VNF的扩容结果。

可以看出，以上VNF的调度扩展都是基于对VNFD模板的改进，在一定程度上还是受限于模板的输入参数，下面本申请介绍一种VNF调度方法，该方法可以实现VNF的任何部署诉求。为便于描述本申请中以第一网元为VNMF为例进行说明。

图9是本申请提出的又一种部署VNF的方法的示意性流程图。该方法可以包括以下步骤。

S901，VNFM向CaaS管理器发送第一信息，第一信息包括自定义调度策略的相关信息，自定义调度策略的信息为部署第一VNF的部署单元对应的节点的个性化诉求信息。对应的，CaaS管理器接收来自VNFM的第一信息。

本实施例中，后续以部署单元为Pod为例对方案进行介绍。可以理解的是当部署单元为VM或者为其他形式的VDU，仍可适用本方案。

可选地，如图9所示，S901的一种实现方式为：第一信息可以包含于操作人员通过VNFM部署界面上传的第一VNF容器化部署所必需的VNF软件包中，其中，该软件包包括容器镜像文件和VNFD模板。示例的，第一信息可以预埋在上传的VNFD模板内，之后，VNFM向CaaS管理器发送该VNF软件包。

可选地，如图9所示，S901的另一种实现方式为：操作人员通过VNFM部署界面，向CaaS管理器设置第一信息的内容。

可选地，自定义调度策略的相关信息包括：自定义调度策略所在的文件的信息、自定义调度策略的输入参数和输出参数的定义。示例的，自定义调度策略所在的文件的信息包括该文件所在的路径或位置信息。

可选地，自定义调度策略的相关信息还可以包括：自定义调度策略的生效周期。

示例的，自定义调度策略的生效周期可以设置为一直生效，或者，通过明确指令(包含但不限于开关/请求参数等)设置单次生效时间。

示例的，输入参数包括以下至少一项：第一节点的剩余资源、第一节点上已部署的Pod、第一节点的标签信息，第一节点为资源池中可用于部署第一VNF的Pod的备选节点。

示例的，输出参数包括第一节点的匹配度，匹配度是基于输入数的取值与自定义调度策略确定的。S904中会举例说明如何根据自定义调度策略的输入和输出参数确定第一VDU的部署节点，这里暂不展开叙述。

S902，CaaS管理器向VNFM发送第一消息，第一消息指示自定调度策略设置完成。对应的，VNFM接收来自CaaS管理器的第一消息。之后，VNFM可以在VNFM界面向用户显示自定调度策略设置成功。

S903，VNMF向CaaS管理器发送第一请求消息，第一请求消息用于请求根据自定义调度策略的信息部署第一VNF的Pod。对应的，CaaS管理器接收来自VNFM的第一请求消息。

可以理解，第一请求消息中的信息是操作人员通过VNFM部署界面传输给CaaS管理器的。

示例的，第一请求消息用于请求根据自定义调度策略的信息部署第一VNF的Pod，具体可以理解为，第一请求消息用于请求根据自定义调度策略的信息实例化第一VNF的Pod，或，第一请求消息用于请求根据自定义调度策略的信息扩容部署第一VNF的Pod，或，第一请求消息用于请求根据自定义调度策略的信息重调整已部署的第一VNF的Pod。

S904，CaaS管理器根据自定义调度策略的信息部署第一VNF的Pod至匹配的节点。

为便于理解，结合S901中的自定义调度策略的输入参数和输出参数举例说明如何确定第一VNF的Pod的部署节点。示例的，第一VNF的Pod的自定义策略的内容为：待部署第一VNF的Pod的节点的剩余资源需要大于20G，且该待部署节点上必须已部署了第二VNF的Pod且没有部署第三VNF的Pod。

首先，CaaS管理器需要先计算可用于部署第一VNF的Pod的资源池中的每个节点(例如第一节点)的匹配度。之后，CaaS管理器根据自定义策略的输入项获取第一节点对应的各输入项的取值，具体的，该示例中通过自定义策略的输入项获取第一节点的剩余资源和第一节点上的Pod部署信息，之后，再根据获取到的第一节点的信息和自定义调度策略确定第一节点的匹配度。例如，则当第一节点的剩余资源为100G，第一节点部署了部署了第二VNF的Pod且没有部署第三VNF的Pod，则第一节点的匹配度得分为100，又例如，当第一节点的剩余资源为10G，第一节点部署了第二VNF的Pod且没有部署第三VNF的Pod，则第一节点的匹配度得分为50，又例如，当第一节点的剩余资源为50G，第一节点部署了第二VNF的Pod且部署第三VNF的Pod，则第一节点的匹配度得分为0。那么，当CaaS管理器计算出可用于部署VDU1的资源池中的每个节点的匹配度之后，CaaS管理器可以将第一VNF的Pod调度至匹配度得分最高的节点上。

应理解，如果第一VNF的Pod的自定义策略的输出结果不唯一(例如存在多个节点的匹配度得分为100)，则需要从多个节点之中选择一个节点，本申请对选择方法不做限定。

S905，VNMF接收来自CaaS管理器的第一请求响应消息，第一请求响应消息指示第一VNF的Pod部署成功。

之后，VNFM可以通过VNFM界面向用户显示已完成第一VNF的Pod的部署，以及第一VNF的Pod的部署结果。

可选地，本申请中的标签扩展机制也可以通过该实施例中的自定义调度策略实现，这里不再赘述。

上述技术方案中，通过自定义调度策略可以提供一种更灵活的容器部署/调度干预方法，从而让部署定制性要求较强的产品有机会享受容器化时代的红利。

如图10所示，本申请还提供了一种对多个同一类型的节点的标签进行配置的方法。该方法包括以下步骤。

S1010，第一网元向CaaS管理器发送第三请求消息，第三请求消息用于请求对第一类型节点的信息进行配置，对应的，CaaS管理器接收来自第一网元的第三请求消息，其中，第三请求消息中包括第一信息和第二信息，第一信息包括第一类型节点的特征信息，第二信息包括第一类型节点的标签中待配置的键值对信息。

可选地，第一网元可以为网设工具、NFVO、VNFM中的一个网元。

其中，对第一类型节点的标签进行配置可以理解为为第一类型节点增加标签信息，或，为第一类型节点删除标签信息，或为第一类型节点修改标签信息，本申请不做限制。

示例的，同一类型的节点的原则包含但不限于：拥有某些共同属性(如某个HA下的所有节点)，或者，拥有某个公共标签(如具备相同HA标签的所有节点)。

S1020，CaaS管理器根据第三请求消息对第一类型节点的标签进行配置。

S1030，CaaS管理器向第一网元发送第三请求响应消息，第三请求响应消息指示第一类型节点配置成功。对应的，第一网元接收来自CaaS管理器的第三请求响应消息。

应理解，本申请提出的方案对Pod和节点间的调度机制进行了改进，该方法同时适用于虚机容器和裸机容器场景下的pod调度、以及虚机和虚机容器场景下的VM调度。如果是虚机和虚机容器场景下的VM调度场景，将上述方法中的CaaS管理器替换为VIM部件，即可实现虚机和虚机容器场景下的VM部署范围调整，或资源池扩展的目的，这里不再一一赘述。

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

还应理解，在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

还应理解，在上述一些实施例中，主要以现有的网络架构中的设备为例进行了示例性说明，应理解，对于设备的具体形式本申请实施例不作限定。例如，在未来可以实现同样功能的设备都适用于本申请实施例。

可以理解的是，上述各个方法实施例中，由设备实现的方法和操作，也可以由设备的部件实现。

以上，结合图1至图10详细说明了本申请实施例提供的方法。上述方法主要从第一网元和CaaS管理器之间交互的角度进行了介绍。可以理解的是，第一网元和CaaS管理器，为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。

本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

以下，结合图11和图12详细说明本申请实施例提供的通信装置。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，部分内容不再赘述。本申请实施例可以根据上述方法示例对第一网元或CaaS管理器进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明。

图11是本申请实施例提供的通信装置100的示意性框图。如图11所示，该装置100可以包括通信单元110和处理单元120。通信单元110可以与外部进行通信，处理单元120用于进行数据处理。通信单元110还可以称为通信接口或收发单元。

在一种可能的设计中，该装置100可实现对应于上文方法实施例中的发送端设备执行的步骤或者流程，其中，处理单元120用于执行上文方法实施例中发送端设备的处理相关的操作，通信单元110用于执行上文方法实施例中发送端设备的发送相关的操作。

在又一种可能的设计中，该装置100可实现对应于上文方法实施例中的接收端设备执行的步骤或者流程，其中，通信单元110用于执行上文方法实施例中接收端设备的接收相关的操作，处理单元120用于执行上文方法实施例中接收端设备的处理相关的操作。

应理解，这里的装置100以功能单元的形式体现。这里的术语“单元”可以指应用特有集成电路(application specific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技术人员可以理解，装置100可以具体为上述实施例中的发送端设备，可以用于执行上述方法实施例中与发送端设备对应的各个流程和/或步骤，或者，装置100可以具体为上述实施例中的接收端设备，可以用于执行上述方法实施例中与接收端设备对应的各个流程和/或步骤，为避免重复，在此不再赘述。

上述各个方案的装置100具有实现上述方法中发送端设备所执行的相应步骤的功能，或者，上述各个方案的装置100具有实现上述方法中接收端设备所执行的相应步骤的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块；例如通信单元可以由收发机替代(例如，通信单元中的发送单元可以由发送机替代，通信单元中的接收单元可以由接收机替代)，其它单元，如处理单元等可以由处理器替代，分别执行各个方法实施例中的收发操作以及相关的处理操作。

此外，上述通信单元还可以是收发电路(例如可以包括接收电路和发送电路)，处理单元可以是处理电路。其中，通信单元可以是输入输出电路、通信接口；处理单元为该芯片上集成的处理器或者微处理器或者集成电路。在此不做限定。

图12为本申请实施例提供的通信装置200的示意性框图。该装置200包括处理器210和收发器220。其中，处理器210和收发器220通过内部连接通路互相通信，该处理器210用于执行指令，以控制该收发器220发送信号和/或接收信号。

可选地，该装置200还可以包括存储器230，该存储器230与处理器210、收发器220通过内部连接通路互相通信。该存储器230用于存储指令，该处理器210可以执行该存储器230中存储的指令。在一种可能的实现方式中，装置200用于实现上述方法实施例中的发送端设备对应的各个流程和步骤。在另一种可能的实现方式中，装置200用于实现上述方法实施例中的接收端设备对应的各个流程和步骤。

应理解，装置200可以具体为上述实施例中的发送端设备或接收端设备，也可以是芯片或者芯片系统。对应的，该收发器220可以是该芯片的收发电路，在此不做限定。具体地，该装置200可以用于执行上述方法实施例中与发送端设备或接收端设备对应的各个步骤和/或流程。可选地，该存储器230可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。该处理器210可以用于执行存储器中存储的指令，并且当该处理器210执行存储器中存储的指令时，该处理器210用于执行上述与发送端设备或接收端设备对应的方法实施例的各个步骤和/或流程。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。本申请实施例中的处理器可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

此外，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，当计算机指令在计算机上运行时，使得本申请各方法实施例中的方法被执行。

根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，计算机程序产品包括计算机程序代码或指令，当计算机程序代码或指令在计算机上运行时，使得本申请各方法实施例中的方法被执行。

根据本申请实施例提供的方法，本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行本申请各方法实施例中的方法。

此外，本申请还提供一种芯片，所述芯片包括处理器。用于存储计算机程序的存储器独立于芯片而设置，处理器用于执行存储器中存储的计算机程序，以使得本申请各方法实施例中的方法被执行。

进一步地，所述芯片还可以包括通信接口。所述通信接口可以是输入/输出接口，也可以为接口电路等。进一步地，所述芯片还可以包括存储器。

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

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

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

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

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

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。