容器资源分配方法与系统

技术领域

本发明属于通信技术领域，更具体地，涉及一种容器资源分配方法与系统。

背景技术

随着网络设备的技术演进，设备根据业务需要，部署多种形态的服务已经是必然趋势。传统网络设备本地资源的使用是基于“固化”的需求“确定性”分配的，这就要求“服务”是确定的，这就不能够适应灵活部署多种形态服务的需求。

而IT业当前的采用的灵活部署形态要求部署业务之时，需要了解配置的服务，知晓服务的输入输出各方面要求，了解当前系统硬件组织结构，并根据实际情况设置物理端口、虚拟网桥。但是网络设备通常对外展现为一个节点而内部是复杂的分布式多节点设备，系统复杂度，当作普通IT设备部署服务对使用者来说复杂度较高。

并且，由于网络设备运行要求较之IT基础设施更为严格，将网络管理权限“直接”交给用户对网络的稳定运行来说存在可靠性的隐患。

同时，由于网络切片的需求逐步明确，实际业务网络的创建与服务的部署可能并不同时产生，服务与业务的相关性不能够在初期创建服务时就形成，后创建业务与已形成服务之间的联动在基于“预先部署的容器”的形态下管理不便。

在传统网络架构下使用硬编码的形态将业务与服务做关联，这种应用方法要求事先确定业务与服务的相关性并硬编码，灵活性欠缺可能难以适应未来新的应用场景需要。

在IT环境下通常是针对业务的变化重新拉起服务，替代原服务，这种应用方法对“已有业务可能造成一定的影响”。云网融合的情况下，“网络设备”上基于容器形态承载“云服务”也对设备提出能够将网络基础设施抽象化，便于云服务应用的需求。

发明内容

要解决的技术问题：隔离网络设备基础设施与云服务，云服务的部署者在传统模式下需要了解基础设施的资源情况，根据实际需要想云服务提供对应的资源，这就要求部署者需要熟知云服务的实际业务形态。

云服务可以动态部署，有新的需求扩充可重新拉一个服务。但是单一云服务部署后其业务形态是“静态”的，这种应用形式对于网络基础设施来说不友好，在新上线服务与原有服务有关联性的情况下，会对已有业务的运行造成影响，可能会因为切换服务导致短暂的已有业务中断。

为实现上述目的，按照本发明的一个方面，提供了一种容器资源分配方法，包括以下步骤：

步骤一，基于网络设备的资源逻辑抽象：对网络接口资源、网络带宽资源、运算能力资源、内存资源、存储能力资源及管理能力资源，构建设备环境部署模板；

步骤二，基于上述模板构建诉求，构造对应的开放API：API本身当作一种资源配置到模板中，允许基于不同模板执行的服务能够获得对应的API；

步骤三，网络设备本地服务部署：基于“本地基础设施模板”、“本地资源管理模板”、“本地服务模板”在本地部署以下形态服务：本地基础设施、本地资源管理和本地服务；

步骤四，网络设备的其他服务部署：“其他服务”包含除去本地网络管理服务的其他形态服务，以及“第三方的其他服务”。

本发明的一个实施例中，在所述步骤一中，所述设备环境部署模板包括本地基础设施模板、本地资源管理模板、本地服务模板和第三方服务模板，其中：

本地基础设施模板，拥有整个设备所有的资源的管理权，在该模板内运行的管理程序能够获得分配运算能力资源、内存资源、存储资源、管理网络资源；

本地资源管理模板具备分配运算能力资源、内存资源、存储资源、管理网络资源的能力，包含的是对自身运行的“资源管理服务”分配到其他容器内的资源管理；

本地服务模板具备管理“由本地资源管理”分配给它的网络管控能力，能够与底层驱动交互，承担业务管控职责；

第三方服务模板，能够获得前述资源管理模块提供的运算能力资源、内存资源、存储资源和网络资源，并且基于上述资源运行自己的服务。

本发明的一个实施例中，在所述步骤二中：

最底层API的提供者是基于本地基础设施模板中执行的服务，本地基础设施模板在设备上只能有一个“本地基础设施服务”实例；每种本地基础设施模板中执行的服务，能够对基础设施注入自己提供服务的API，并且声明对应的API能够向什么级别的本地基础设施模板提供；API的使用者是“被声明有对应API权限的模板”，本地基础设施模板本身在被引用时，允许根据需要选择可以“额外”补充的API能力。

本发明的一个实施例中，在所述步骤三中：“本地基础设施服务”实例提供基础设施API；“本地资源管理服务”实例使用本地基础设施提供的API，获得本地资源管理能力，基于本地资源管理部署“本地服务”。

本发明的一个实施例中，所述“本地服务”包括：

第一个本地服务，是本地的网络管理服务，此网络管理服务允许“本地基础设施服务”与北向管理端建立被管理连接，同时它还向“本地基础设施服务”注册“管理网络”管理API，提供管理“管理网络”的能力的API；

第二个本地服务，是“业务网络管理服务”实例，向“本地基础设施服务”注册“业务网络”管理API。

本发明的一个实施例中，步骤四中“其他服务”的部署采用如下过程：

北向控制器通过管理网络接管基础设施，获得“服务部署能力”；

北向控制器基于API，向基础设施查询本地基础设施的全局能力，以获得可能部署什么服务，此时获得的是各个模板以及可以允许各模板使用的相关资源的全局情况；

北向控制器基于API向基础设施查询本地“可部署服务”本身，在查询时基础设施反馈“可部署服务”仅能够获得“基础的原生”服务；其中，“基础的原生”服务，基于业务的需求进行部署，以利于管理与应用效率；

北向控制器通过“基础设施”提供的API，向基础设施推送其硬件条件允许的“服务”；

北向控制器通过基础设施给出的API部署“新的服务”，且新的服务基于“本地服务模板”或“第三方服务模板”部署。

按照本发明的另一方面，还提供了一种容器资源分配系统，包括资源逻辑抽象模块、API构造模块、本地服务部署模块和其他服务部署模块，其中：

所述资源逻辑抽象模块，用于基于网络设备的资源逻辑抽象：对网络接口资源、网络带宽资源、运算能力资源、内存资源、存储能力资源及管理能力资源，构建设备环境部署模板；

所述API构造模块，用于基于上述模板构建诉求，构造对应的开放API：API本身也当作一种资源配置到模板中，允许基于不同模板执行的服务能够获得对应的API；

所述本地服务部署模块，用于网络设备本地服务部署：基于“本地基础设施模板”、“本地资源管理模板”、“本地服务模板”在本地部署以下形态服务：本地基础设施、本地资源管理和本地服务；

所述其他服务部署模块，用于网络设备的其他服务部署：“其他服务”包含除去本地网络管理服务的其他形态服务，以及“第三方的其他服务”。

本发明的一个实施例中，所述设备环境部署模板包括本地基础设施模板、本地资源管理模板、本地服务模板和第三方服务模板，其中：

本地基础设施模板，拥有整个设备所有的资源的管理权，在该模板内运行的管理程序能够获得分配运算能力资源、内存资源、存储资源、管理网络资源；

本地资源管理模板具备分配运算能力资源、内存资源、存储资源、管理网络资源的能力，包含的是对自身运行的“资源管理服务”分配到其他容器内的资源管理；

本地服务模板具备管理“由本地资源管理”分配给它的网络管控能力，能够与底层驱动交互，承担业务管控职责；

第三方服务模板，能够获得前述资源管理模块提供的运算能力资源、内存资源、存储资源和网络资源，并且基于上述资源运行自己的服务。

本发明的一个实施例中，在所述API构造模块中，最底层API的提供者是基于本地基础设施模板中执行的服务，本地基础设施模板在设备上只能有一个“本地基础设施服务”实例；每种本地基础设施模板中执行的服务，能够对基础设施注入自己提供服务的API，并且声明对应的API能够向什么级别的本地基础设施模板提供；API的使用者是“被声明有对应API权限的模板”，本地基础设施模板本身在被引用时，允许根据需要选择可以“额外”补充的API能力。

本发明的一个实施例中，在所述本地服务部署模块中，“本地基础设施服务”实例提供基础设施API；“本地资源管理服务”实例使用本地基础设施提供的API，获得本地资源管理能力，基于本地资源管理部署“本地服务”，所述“本地服务”包括：

第一个本地服务，是本地的网络管理服务，此网络管理服务允许“本地基础设施服务”与北向管理端建立被管理连接，同时它还向“本地基础设施服务”注册“管理网络”管理API，提供管理“管理网络”的能力的API；

第二个本地服务，是“业务网络管理服务”实例，向“本地基础设施服务”注册“业务网络”管理API。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有如下有益效果：

(1)北向控制器能够便捷的基于业务需求部署服务；

(2)服务能获得的权限、资源，是根据设备可提供资源以及业务需求预制的“能力”，而不是“结果”，在配置服务时可以灵活定制服务；

(3)服务是否可以运行是基于设备开发时的情况已经经过分析、分解的，给出了定量、定性的呈现，而不需要现场判断，有利于服务的部署与维护；

(4)由于隔离了物理呈现，维护人员不需要深入到设备底层系统了解设备底层资源，也就无需将底层设备的管理权析出给普通的维护人员，提高了设备的安全性；

(5)底层资源的隔离也保证了设备“基础设施”层面自身执行时的资源，避免了因为逐步铺开的智能化、自动化的运维部署的额外服务对设备稳定性的影响。

附图说明

图1是本发明实施例中容器资源分配方法的流程示意图；

图2是本发明实施例中容器资源分配方法的原理示意图；

图3是本发明实施例中其他服务分配的流程示意图；

图4是本发明实施例中其他服务的分配原理示意图；

图5是本发明实施例中容器资源分配系统的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

为了解决现有技术存在的问题，本发明提供一种根据网络基础设施设备上本身资源相匹配的“供给”方法，允许根据基础设施本身的能力灵活定制，并且允许云服务基于可变的业务承载需求灵活申请。

如图1所示，本发明提供了一种容器资源分配方法，包括如下步骤：

步骤一，基于网络设备的资源逻辑抽象：对网络接口资源、网络带宽资源、运算能力资源、内存资源、存储能力资源及管理能力资源，构建设备环境部署模板；

具体地，如图2所示，对网络接口资源(包括管理网络、业务网络)、网络带宽资源(管理网络、业务网络)、以及基础设施(包括运算能力资源、内存资源、存储能力资源)，及上述资源的管理能力资源，构建设备环境部署模板，设备环境部署模板包含下面几种形式：本地基础设施模板、本地资源管理模板、本地服务模板、第三方服务模板，其中：

本地基础设施模板为设备最强权限模板，拥有整个设备所有的资源的管理权，在该模板内运行的管理程序能够获得分配运算能力资源、内存资源、存储资源、管理网络资源等，但在基于该模板拉起的本地基础设施服务实例中并不直接分配资源，它的作用在于提供对后面拉起的其他“容器”化服务的基础设施。本地基础设施服务实例事实上接管了本地所有资源。

本地资源管理模板为设备第二强权限模板，较基础设施模板弱，但它依然具备分配运算能力资源、内存资源、存储资源、管理网络资源的能力，与本地基础设施模板的差异在于，在该模板内不会运行对整机的监控与管理。它包含的是对自身运行的“资源管理服务”分配到其他容器内的资源管理。

本地服务模板是设备第三强权限模板，它不再获得本地运算、内存、存储资源管控能力，但它具备管理由“本地资源管理服务”分配给它的网络(业务资源)管控能力，能够与底层驱动交互，它只承担业务管控职责。需要注意的是，网络设备的本地服务中，会存在一个为“本地资源管理服务”提供网络资源的实例。

第三方服务模板是最弱的权限模板，它仅能够获得前述资源管理模块提供的运算能力资源、内存资源、存储资源、网络资源，基于上述资源运行自己的服务。

步骤二，基于上述模板构建诉求，构造对应的开放API：API本身当作一种资源配置到模板中，允许基于不同模板执行的服务能够获得对应的API；

如图2所示，API本身也当作一种资源配置到模板中，允许基于不同模板执行的服务能够获得对应的API。

最底层API的提供者是基于本地基础设施模板中执行的服务，本发明中简称“本地基础设施服务”，本地基础设施模板在设备上只能有一个“本地基础设施服务”实例；每种本地基础设施模板中执行的服务，能够对基础设施注入自己提供服务的API，并且声明对应的API能够向什么级别的本地基础设施模板提供；API的使用者是“被声明有对应API权限的模板”，本地基础设施模板本身在被引用时，允许根据需要选择可以“额外”补充的API能力(通常情况下无需补充)。

步骤三，网络设备本地服务部署：基于“本地基础设施模板”、“本地资源管理模板”、“本地服务模板”在本地部署以下形态服务：本地基础设施、本地资源管理和本地服务；

如图2所示，本地基于“本地基础设施模板”、“本地资源管理模板”、“本地服务模板”部署以下形态服务：

“本地基础设施服务”实例，提供基础设施API。

“本地资源管理服务”实例，使用本地基础设施提供的API，获得本地资源管理能力，基于本地资源管理，部署“本地服务”。

第一个本地服务，是本地的网络管理服务，此网络管理服务允许“本地基础设施服务”与北向管理端建立被管理连接，同时它还向“本地基础设施服务”注册“管理网络”管理API，提供管理“管理网络”的能力的API。需要注意的是，“管理网络”的能力的API只有特权用户、特权容器才可获得，正常情况下不会向“其他服务”提供。

第二个本地服务，是“业务网络管理服务”实例，向“本地基础设施服务”注册“业务网络”管理API。

之后的服务均依赖上述服务提供的API展开工作。

步骤四，网络设备的其他服务部署：“其他服务”包含除去本地网络管理服务的其他形态服务，以及“第三方的其他服务”；

如图2所示，“其他服务”包含除去本地网络管理服务的其他形态服务，以及“第三方的其他服务”。

其他服务的“管理网络”、“业务网络”，均基于前文步骤一中给出的模板提供，它可获得前文步骤三提供的在其模板中已经确定可以供其使用的API。

如图3所示，为本发明实施例中其他服务分配的流程示意图，上述步骤四中“其他服务”的部署采用如下过程：

(4.1)北向控制器通过管理网络接管基础设施，获得“服务部署能力”。

(4.2)北向控制器基于前文提到的API，向“本地基础设施服务”查询本地基础设施的全局能力，以获得可能部署什么服务，此时获得的是各个模板，以及可以允许各模板使用的相关资源的全局情况。

(4.3)北向控制器基于前文提到的API向基础设施查询本地“可部署服务”本身，在“干净的设备上”，可能并没有额外的“可部署服务”，仅有“基础的原生”的服务，比如邻居发现等，但一些高级功能如智能采集、分析应用等，可能并未发布到设备上。此时，在查询时基础设施反馈“可部署服务”仅能够获得“基础的原生”服务。

“基础的原生”服务，也需要基于业务的需求部署，以利于管理与应用效率，无业务需求时，可以无需启动相关服务。

(4.4)北向控制器能够通过“本地基础设施服务”提供的API，向基础设施推送其硬件条件允许的“服务”，这些服务在推送时，首先需要基于基础设施提供的API，核对该基础设施上是否具备运行该服务的条件：检查基础设施上的计算资源、存储资源、网络资源是否能够承载该服务。

(4.5)北向控制器只能通过基础设施给出的API部署“新的服务”，且新的服务仅能基于“本地服务模板”或“第三方服务模板”部署。故上述服务能获得的资源只能是对应模板提供的资源，而无法获得更多的其他资源。

以下结合具体实施例进一步详细说明本发明方法：

步骤一，基于网络设备的资源逻辑抽象：

首先定义几个级别：

{

level:[

infrastructure,//基础设施模板

mng_admin,//管理模板

dev_mng,//业务管理模板

application//应用模板

]

}

用下面JSON文件格式，给出抽象设备资源：

{

resources:[

{

"name":"mng_net",

"type":"virt_net",

"parameters":{

"unit":"M",

"range":"10"

},

{

"name":"svc_net","type":"phy_net","parameters":{

"unit":"M",

"range":"1000000"}

},

{

"name":"cpu"

"type":"caculate","parameters":{

"name":"dmips","range":"100000"}

},

{

"name":"ram"

"type":"ram","parameters":{

"name":"M","range":"1000"

}

},

{

"name":"hdisk"

"type":"hdisk",

"parameters":{

"name":"M",

"range":"100"

}

}

]

}；

管理资源以API形式对外提供，下面基于JSON给出一个“简化”例子，实际业务创建较为复杂，本专利中不过多展示。

{

"name":"create_svc_net",

"parameters":{

"unit":"M",

"range":"10"

}

}

若api执行成功，则返回：

{

"name":"create_svc_net",

"result":"succuess",

"data":[

{

"name":"dev10m0"

}

]

}

若api执行失败，则返回：

{

"name":"create_mng_net",

"result":"unsupported",

"data":[]

}

本地基础设施模板，摘取JSON片段：{

resources：[

{

"name":"mng_net",

"type":"virt_net",

"parameters":{

"unit":"M",

"range":"10"

},

{

"name":"device_x",

"type":"dev",

"parameters":{

...//一些具体的与器件相关的参数

}

},

{

"name":"cpu"

"type":"caculate",

"parameters":{

"name":"dmips",

"range":"100000"

}

},

...//其他提供给基础设施使用的资源

]

}

不同的服务模板中给出的资源不尽相同，其中“本地基础设施服务”获得的是物理资源，故其模板中能够见到具体的硬件器件资源“dev”，而其他的模板获得的皆为基础设施对外提供的API给出的逻辑资源，经过基础设施的抽象后，上层“服务”与“物理资源”形成了隔离，并且它们也不能直接接触、控制到物理资源，保证了资源的安全使用，下面给出一个本地资源管理模板JSON描述片段：

{

resources：[

{

"name":"mng_net",

"type":"virt_net",

"parameters":{

"unit":"M",

"range":"10"

},

{

"name":"cpu"

"type":"caculate",

"parameters":{

"name":"dmips",

"range":"100000"

}

},

...//其他提供给基础设施使用的资源],

api:[

"name":"create_mng_net",

"name":"some_api_name",

"applicant":"application",

"provider":"mng_net",

"parameters":{

"unit":"M",

"range":"10"

...//其他参数

},

"name":"inject_api",

"parameters":{

"name":"some_api_name",

"applicant":"application",

"provider":"this",

"parameter":[...]

...//一些其他必要的参数

}

...//其他允许使用的api

]

}

步骤二，基于上述模板构建诉求，构造对应的开放API

从上面本地资源管理模板片段可知，它获得了创建业务通道的api，这个api是本地基础设施提供的，通过模板中给出的管理通道mng0执行。本地资源管理根据根据业务需要执行这个api时，对应的参数会经由mng0发送到“本地基础设施服务”中，本地基础设施根据前文模板，具有硬件基础设施(device_x)的控制权，相关的具体配置将设置到对应的器件上。具体的执行过程与器件的设计有关，不属于本专利讨论范畴，这里不过多讨论。

同时，可以看到本地资源管理模板中还有inject_api这个api，它允许使用该模板的环境向基础设施注册新的API，便于更下游的环境调用。模板中给出一个必要参数"level"指的是这个api将允许哪一种模板可以选择这个api。如level是application，说明这个api是普适性的，任何模板均能够调用，如果applicant是mng_admin，表明这个api只能由管理模板中的应用调用。

当前给出JSON模板的例子表示，inject_api这个接口的applicant是application，表示这个接口允许任何模板调用，也就是说后续启动的任何服务均有能力向基础设施注册其可提供的API。

步骤三，网络设备本地服务部署

设备实际部署时，“本地基础设施服务”、“本地资源管理服务”、“本地服务”中均有一些默认就存在的服务，组成设备原生形态就应该具备的基础功能。

如图一所示，基础设施、管理网络、业务网络三部分，分别基于前面所说的三个模板直接部署，并且在设备上电后就默认启动基础设施，由基础设施基于本地确定的配置自动拉起当前激活的管理网络、业务网络服务。

在管理网络、业务网络服务启动时，根据前文步骤二中提供的api注册方法，他们向注册对应的api。较为特殊的地方在于，管理网络与业务网络启动过程可能存在先后顺序，api的注册是动态的。

步骤四，网络设备的其他服务部署

如图4所示，为本发明实施例中“其他服务”的部署的原理示意图，这里根据端到端业务管控的场景，给出一个例子。

有两个端到端业务(业务服务A和业务服务B)，分别需要提供给两个不同客户使用，基于这两个业务，都需要给出自己的对应服务，假设我们要分别部署两个bgpd(BorderGateway Protocol Daemon)，提供邻居发现功能。

初始环境中并未正式部署bgpd，根据客户实际需求拉出端口1、2中的对应业务后，由北向控制器正式基于应用容器环境部署包含端口1、2业务的bgpd服务。

同样的，如果有另外的客户需求，同时还希望端口3、4与1、2之间是隔离的，可以单独再拉起bgpd服务，基于api注入端口3、4。

未来有更多业务时，可基于前文提到的api将对应的业务端口注入到bgpd服务所处的容器环境中，例如图例环境中业务服务A增加了需求，将业务端口5也纳入，无需重新配置一个新的容器，然后切换到新的容器中，而是只需要调用前文提到的API，将服务注入到业务服务A中即可。

进一步地，如图5所示，本发明提供了一种容器资源分配系统，包括资源逻辑抽象模块、API构造模块、本地服务部署模块和其他服务部署模块，其中：

所述资源逻辑抽象模块，用于基于网络设备的资源逻辑抽象：对网络接口资源、网络带宽资源、运算能力资源、内存资源、存储能力资源及管理能力资源，构建设备环境部署模板；

所述API构造模块，用于基于上述模板构建诉求，构造对应的开放API：API本身也当作一种资源配置到模板中，允许基于不同模板执行的服务能够获得对应的API；

所述本地服务部署模块，用于网络设备本地服务部署：本地基于“本地基础设施模板”、“本地资源管理模板”、“本地服务模板”部署以下形态服务：本地基础设施、本地资源管理和本地服务；

所述其他服务部署模块，用于网络设备的其他服务部署：“其他服务”包含除去本地网络管理服务的其他形态服务，以及“第三方的其他服务”。

进一步地，所述设备环境部署模板包括本地基础设施模板、本地资源管理模板、本地服务模板、第三方服务模板，其中：

本地基础设施模板为设备最强权限模板，拥有整个设备所有的资源的管理权，在该模板内运行的管理程序能够获得分配运算能力资源、内存资源、存储资源、管理网络资源；

本地资源管理模板为设备第二强权限模板，较基础设施模板弱，但它依然具备分配运算能力资源、内存资源、存储资源、管理网络资源的能力，在该模板内不会运行对整机的监控与管理，它包含的是对自身运行的“资源管理服务”分配到其他容器内的资源管理；

本地服务模板是设备第三强权限模板，它不再获得本地运算、内存、存储资源管控能力，但它具备管理“由本地资源管理”分配给它的网络管控能力，能够与底层驱动交互，它只承担业务管控职责；

第三方服务模板是最弱的权限模板，它仅能够获得前述资源管理模块提供的运算能力资源、内存资源、存储资源、网络资源，基于上述资源运行自己的服务。

进一步地，在所述API构造模块中，最底层API的提供者是基于本地基础设施模板中执行的服务，本地基础设施模板在设备上只能有一个“本地基础设施服务”实例；每种本地基础设施模板中执行的服务，能够对基础设施注入自己提供服务的API，并且声明对应的API能够向什么级别的本地基础设施模板提供；API的使用者是“被声明有对应API权限的模板”，本地基础设施模板本身在被引用时，允许根据需要选择可以“额外”补充的API能力。

进一步地，在所述本地服务部署模块中，“本地基础设施服务”实例提供基础设施API；“本地资源管理服务”实例使用本地基础设施提供的API，获得本地资源管理能力，基于本地资源管理部署“本地服务”，所述“本地服务”包括：

第一个本地服务，是本地的网络管理服务，此网络管理服务允许“本地基础设施服务”与北向管理端建立被管理连接，同时它还向“本地基础设施服务”注册“管理网络”管理API，提供管理“管理网络”的能力的API；

第二个本地服务，是“业务网络管理服务”实例，向“本地基础设施服务”注册“业务网络”管理API。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。