一种资源配置方法及装置
技术领域
本申请涉及云计算技术领域,尤其涉及一种资源配置方法及装置。
背景技术
Docker是一个开源的应用容器引擎,允许开发者打包应用到容器中,适合大规模分布式应用和大数据处理应用场景。
图1示出了现有技术中Docker管理环境的架构示意图,如图所示,包括:控制节点、容器库、配置/服务发现存储系统以及多台容器节点。其中,
(1)控制节点实现了对外的调用接口和集群内资源调度功能;
(2)容器库实现了容器的注册和发布功能,在部署容器时可直接从容器库中将相关的容器移动待部署的机器上;
(3)配置/服务发现存储系统用于共享配置并实现服务发现功能;
(4)容器节点用于实际运行Docker容器。
具体的,在每台容器节点上运行了本地容器管理模块、代理模块,其中,
(1)本地容器管理模块用于与控制节点通信,并根据控制节点的指令在本地创建容器组,容器组可以包含一个或多个容器;
(2)代理模块用于解决同一宿主机相同服务端口冲突的问题,还具备service转发服务端口来对外提供服务的能力。
目前,Docker管理环境中的这些组件通常部署在一个数据中心内部的多台物理网络互通的物理服务器或多台虚拟机上。由于管理环境部署于同一个局域网内,各物理服务器或虚拟机之间没有安全隔离机制,不同用户的应用通过容器进行隔离。当系统进行组件、资源等的配置管理时,控制节点可以通过交换机或虚拟交换机可以向某个物理机或虚拟机发送增加、删除组件消息,其他用户也可以向该物理机或虚拟机发送攻击性的消息,例如修改、删除应用等。
现有技术不足在于:
Docker管理环境中系统的配置管理过程中,用户的应用存在一定的安全风险。
发明内容
本申请实施例提出了一种资源配置方法及装置,以解决现有技术中系统的配置管理过程中,用户的应用存在一定安全风险的技术问题。
本申请实施例提供了一种资源配置方法,包括如下步骤:
管理虚拟私有云VPC上的控制节点获取用户VPC中所部署的应用的副本数;所述用户VPC用于存放所述用户的应用;
所述控制节点判断所述用户VPC中所部署的应用的副本数是否与配置要求的数量相同;
所述控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安全隧道配置所述用户VPC上的容器。
本申请实施例提供了一种资源配置装置,包括:
第一获取模块,用于管理虚拟私有云VPC上的控制节点获取用户VPC中所部署的应用的副本数;所述用户VPC用于存放所述用户的应用;
第一判断模块,用于所述控制节点判断所述用户VPC中所部署的应用的副本数是否与配置要求的数量相同;
第一配置模块,用于所述控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安全隧道配置所述用户VPC上的容器。
有益效果如下:
本申请实施例所提供的资源配置方法及装置,在进行资源配置时,由管理VPC上的控制节点获取用户VPC中所部署的应用的副本数,并判断所述用户VPC中所部署的应用的副本数是否低于预先配置数量,所述管理VPC上的控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安全隧道配置所述用户VPC上的容器,以满足配置要求。本申请实施例中,由于用户的应用部署于用户VPC中,由管理VPC分别通过与各个用户VPC之间的安全隧道来管理、配置相应的用户VPC,用户之间通过VPC隔离,从而确保在资源配置时只有管理VPC可以与所述用户VPC通信,其他用户无法访问或攻击所述用户VPC,提高了用户应用的安全性。
附图说明
下面将参照附图描述本申请的具体实施例,其中:
图1示出了现有技术中Docker管理环境部署的架构示意图;
图2示出了现有技术中以Kubernetes为例的Docker管理环境示意图;
图3示出了本申请实施例中资源配置方法实施的流程示意图;
图4示出了本申请实施例中Docker实现系统的结构示意图一;
图5示出了本申请实施例中Docker实现系统的结构示意图二;
图6示出了本申请实施例中系统的故障处理过程示意图;
图7示出了本申请实施例中用户发起应用扩容的过程示意图;
图8示出了本申请实施例中系统自动扩容的过程示意图;
图9示出了本申请实施例中资源配置装置的结构示意图。
具体实施方式
为了使本申请的技术方案及优点更加清楚明白,以下结合附图对本申请的示例性实施例进行进一步详细的说明,显然,所描述的实施例仅是本申请的一部分实施例,而不是所有实施例的穷举。并且在不冲突的情况下,本说明中的实施例及实施例中的特征可以互相结合。
发明人在发明过程中注意到:
目前kubernetes为常用的Docker容器集群管理系统,它为容器化的应用提供了资源调度、部署运行、服务发现、扩容缩容等功能。
图2示出了现有技术中以kubernetes为例的Docker管理环境示意图,如图所示,Docker管理环境可以包括控制节点kubernetesmaster、容器库Dockerregistry、高可用的键值存储系统ETCD(一个分布式强一致性的key/value存储)和多台容器节点kubernetesnode。
在kubernetes中,kubernetesmaster实现了API(应用编程接口,ApplicationProgrammingInterface)服务器server、副本控制器replicationcontrollers、调度器scheduler等功能模块,其中:
APIserver作为kubernetes系统的入口,封装了核心对象的增加、删除、修改、查询操作,以RESTFul(表述性状态转移,RepresentationalStateTransfer)接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到ETCD。
ReplicationController实现复制多个Pod副本,往往一个应用需要多个Pod来支撑,并且可以保证其复制的副本数,即使副本所调度分配的主宿机出现异常,通过ReplicationController可以保证在其它主宿机启用同等数量的Pod。
scheduler负责集群的资源调度,为新建的pod分配机器。
在容器节点上运行了本地容器管理模块kubelet、代理模块proxy,其中:
本地容器管理模块用于与控制节点(Master)通信,并根据控制节点的指令在本地创建容器组可以包含一个容器或多个相关的容器;在kubernetes中,通常以容器组(POD)为单位来进行调度;
代理模块(Proxy)用于解决同一主宿机的相同服务端口冲突的问题,还提供了Service转发服务端口对外提供服务的能力。
这些组件可以部署在一个数据中心内部的多台物理网络互通的物理服务区或虚拟机上。具体的,可以将其中某些组件部署在相同的物理机或虚拟机上,例如,将控制节点和容器库放在相同的物理机或虚拟机上,配置/服务发现存储系统在3个或3个以上的物理机或虚拟机上独立集群部署。
综上可以看出,现有Docker运行环境大多是部署在同一局域网内的物理机或虚拟机上,彼此之间可以直接通信,不同的用户的应用可以通过容器container隔离。
但这种方式,当系统进行资源配置管理时,控制节点可以通过交换机或虚拟交换机可以向某个物理机或虚拟机发送增加、删除资源的消息,其他用户也可以向该物理机或虚拟机发送攻击性的消息,例如修改、删除应用等。
因此,现有技术可能存在用户的应用被其他用户攻击的风险,不能防止来自容器的入侵,安全性较低,对于资源隔离要求高、安全性要求高的多租户场景并不适用。
为了解决上述问题,本申请实施例提出将容器container与虚拟私有云(VPC,VirtualPrivateCloud)结合起来,通过VPC的机制弥补容器所固有的安全缺陷,也即,将不同用户的应用放在不同VPC的虚拟机上,同一用户的不同应用使用container隔离,以提高安全性。
基于此,本申请实施例提出了一种资源配置方法及装置,下面进行说明。
图3示出了本申请实施例中资源配置方法实施的流程示意图,如图所示,所述资源配置方法可以包括如下步骤:
步骤301、管理VPC上的控制节点获取用户VPC中所部署的应用的副本数;所述用户VPC用于存放所述用户的应用;
步骤302、所述控制节点判断所述用户VPC中所部署的应用的副本数是否与配置要求的数量相同;
步骤303、所述控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安全隧道配置所述用户VPC上的容器。
具体实施中,管理VPC上的控制节点获取用户VPC中所部署的应用的副本数,可以为管理VPC上实时或定期收集用户VPC中所部署的应用的副本数,并存储于管理VPC上的应用信息表中,控制节点根据所述应用信息表即可获取到用户VPC中所部署的应用的副本数;也可以由控制节点在需要获取用户VPC中所部署的应用的副本数时,通过管理VPC与用户VPC之间的安全隧道发起获取请求来获取。
本申请实施例中配置要求的数量可以为管理VPC中预先配置的每个应用的副本数量要求,所述控制节点将获取到的所述用户VPC中所部署的应用的副本数与预先配置的副本要求进行比对;配置要求的数量还可以为用户发送的应用副本数配置要求,例如,用户更新某个应用的副本数配置信息,该配置信息中可以包括该应用副本的配置要求的数量。
所述控制节点可以根据判断结果,通过所述管理VPC与所述用户VPC之间的安全隧道,来配置所述用户VPC上的容器,以满足应用副本的配置要求。
其中,所述管理VPC与所述用户VPC均可以包括一个虚拟路由装置,如虚拟路由器vRouter或虚拟路由网关vGateway,通过设置所述虚拟路由装置上的路由和安全策略来实现二者之间的安全隧道。
具体实施时,所述安全隧道可以为通用路由封装(GRE,GenericRoutingEncapsulation)隧道或因特网协议安全性(IPSEC,InternetProtocolSecurity)隧道。
其中,GRE隧道是用一种网络协议PDU封装另一种网络协议PDU的技术,可以像真实的网络接口那样传递多播数据包;而IPSEC隧道则是将原始数据包封装在新的数据包内部,隧道两端并不关心起点与终点之间的任何路由器、交换机等安全网关。
本申请实施例所提供的方法,在系统进行资源配置时,管理VPC上的控制节点获取当前用户VPC中部署的应用副本数,并判断所述用户VPC中部署的应用副本数是否与配置要求的数量相同,根据判断结果通过管理VPC与用户VPC之间的安全隧道配置所述用户VPC上的容器,以满足配置要求。由于不同用户的应用分别部署于各自的用户VPC上,用户之间通过VPC实现隔离,用户VPC之间不可互相访问,由管理VPC统一进行资源配置,从而提高了用户应用的安全性。
实施中,如果所述用户VPC中所部署的应用的副本数低于配置要求的数量,所述控制节点通过所述管理VPC与所述用户VPC之间的安全隧道,为所述用户VPC创建容器;所述容器用于部署所述应用的副本。
本申请实施例可以通过判断用户VPC中所部署的应用副本数与配置要求的数量之间的关系,确定所述系统是否需要发起扩容操作,即,如果所述用户VPC中所部署的应用的副本数高于配置要求的数量则需要进行扩容。
具体实施中,可以由控制节点通过所述管理VPC与所述用户VPC之间的安全隧道为用户VPC创建容器,来部署该应用的副本,以达到应用副本的配置要求。
实施中,如果所述用户VPC中所部署的应用的副本数高于配置要求的数量,所述控制节点向所述应用副本所在的虚拟机上的本地容器管理模块发送容器释放消息,所述本地容器管理模块根据所述容器释放消息释放部署所述应用副本的容器。
本申请实施例在确定所述用户VPC中所部署的应用的副本数高于配置要求的数量时,说明此时用户VPC中存在多余的应用副本,可以发起缩容操作,以避免资源的浪费。
具体实施中,可以由控制节点向其中一个或几个应用副本所在的虚拟机上的本地容器管理模块发送容器释放消息,所述本地容器管理模块接收到所述容器释放消息后释放所述部署所述应用副本的容器,释放资源实现缩容目的。
图4示出了本申请实施例中Docker实现系统的结构示意图一,如图所示,所述Docker实现系统可以包括一个管理VPC和多个用户VPC,每个VPC中可以包括虚拟路由装置,具体实施时,虚拟路由装置可以为虚拟路由器vRouter或虚拟机路由网关vGateway等。
图5示出了本申请实施例中Docker实现系统的结构示意图二,为图4的详细说明,如图所示,具体可以为:
管理VPC可以包括:控制节点、容器库、用户VPC管理模块和配置服务发现存储系统;所述用户VPC的虚拟机上部署有本地容器管理模块、代理模块和一个或多个容器container(或者包括一个或多个容器组POD,每个POD可以包括一个或多个容器),所述虚拟机与所述用户VPC的虚拟路由装置连接,所述容器用于存放所述用户的应用。
具体实施中,控制节点、容器库、用户VPC管理模块和配置服务发现存储系统可以分别部署于不同的虚拟机上,也可以将控制节点、容器库、用户VPC管理模块部署于同一虚拟机上、将配置服务发现存储系统单独部署于其他虚拟机上,或者将所述配置服务发现存储系统集群部署于3个或3个以上的虚拟机上。
所述用户VPC管理模块可以通过调用IaaS(基础设施即服务,InfrastructureasaService)云平台的API实现,用来管理所述用户VPC。
其中,所述管理所述用户VPC可以包括:动态创建/删除用户VPC及其虚拟路由装置、建立所述用户VPC与管理VPC之间的安全隧道、设置管理VPC中虚拟路由装置的安全策略、在用户VPC中动态增加或删除虚拟机等。
本申请实施例可以通过在用户VPC的虚拟机中配置控制节点的地址等,来实现所述用户VPC的虚拟机中的本地容器管理模块与所述管理VPC中的控制节点建立通信。
实施中,在确定所述用户VPC中所部署的应用的副本数低于配置要求的数量之后,为所述用户VPC创建容器之前,所述方法可以进一步包括:
所述控制节点获取所述用户VPC的虚拟机信息;
所述控制节点判断所述用户VPC中的虚拟机资源是否足够部署所述应用的副本;
如果所述用户VPC中的虚拟机资源不足以部署所述应用的副本,所述管理VPC上的用户VPC管理模块为所述用户VPC创建虚拟机。
具体实施中,如果控制节点确定所述用户VPC中所部署的应用的副本数低于配置要求的数量,可以获取所述用户VPC的虚拟机信息,判断所述用户VPC中的虚拟机资源是否足够部署所述应用的副本:
如果所述用户VPC中的虚拟机资源足够部署所述应用的副本,则可以在所述用户VPC中的虚拟机上创建容器,部署所述应用的副本;
如果所述用户VPC中的虚拟机资源不足以部署所述应用的副本,那么,则可以由所述管理VPC上的用户VPC管理模块为所述用户VPC创建虚拟机。
本申请实施例在确定所述用户VPC中所部署的应用的副本数低于配置要求的数量之后,首先判断该用户VPC上的虚拟机是否足以部署所述应用的副本,再进行应用副本的部署,以避免用户VPC的虚拟机资源不足导致运行效率低下或虚拟机故障等情况。
实施中,所述控制节点通过所述管理VPC与用户VPC之间的安全隧道,为所述用户VPC创建容器,具体可以为:
所述控制节点确定所述用户VPC中的虚拟机,通过所述管理VPC与用户VPC之间的安全隧道,向所述目标虚拟机上的本地容器管理模块发送容器创建消息;
所述虚拟机上的本地容器管理模块通过所述安全隧道从所述管理VPC上的容器库下载容器模板,根据所述容器模板创建容器。
具体实施中,所述控制节点可以首先确定所述用户VPC中的目标虚拟机;如果所述用户VPC上包括多个足以部署所述应用副本的虚拟机,所述控制节点可以根据负载均衡等策略选择其中一个虚拟机作为目标虚拟机;如果所述用户VPC中没有足以部署所述应用副本的虚拟机,为所述用户VPC创建了新的虚拟机时,所述控制节点可以确定该新创建的虚拟机为目标虚拟机。
所述控制节点通过所述管理VPC与用户VPC之间的安全隧道向所述确定的虚拟机上的本地容器管理模块发送容器创建消息,所述本地容器管理模块从所述管理VPC上的容器库下载容器模板,根据所述容器模板创建容器。所述容器库中可以预先存储有若干容器模板。
具体实施时,所述控制节点向所述虚拟机上的本地容器管理模块发送的容器创建消息中可以包括所述应用的参数,所述本地容器管理模块可以根据所述应用的参数从容器库中选择相应的容器模板来创建容器。
实施中,所述管理VPC上的控制节点获取用户VPC中所部署的应用的副本数,具体可以为:
管理VPC上的控制节点监控用户VPC的虚拟机状态;
当所述控制节点发现所述用户VPC的虚拟机出现故障时,获取所述用户VPC中所部署的应用的副本数。
具体实施时,管理VPC上的控制节点可以实时监控用户VPC的虚拟机状态,一旦发现所述用户VPC上的虚拟机出现故障时,即可获取该用户VPC中所部署的应用的副本数。本申请实施例可以通过监控用户VPC虚拟机状态的方式,及时进行故障处理,以免由于虚拟机故障导致用户的应用无法正常使用。
实施中,所述管理VPC上的控制节点获取用户VPC中所部署的应用的副本数,具体可以为:
所述管理VPC上的控制节点接收到用户的应用副本数更新请求时,获取用户VPC中所部署的应用的副本数。
具体实施中,如果用户发起应用副本数的更新请求,控制节点接收到该更新请求后,可以获取用户VPC中当前的应用副本数,从而将用户VPC中当前的应用副本数与用户更新后的应用副本数进行比对。
本申请实施例可以允许用户主动进行扩容/缩容,并在及时响应用户的需求的同时确保了用户应用的安全性。
实施中,所述管理VPC上的控制节点获取用户VPC中所部署的应用的副本数,具体可以为:
管理VPC上的控制节点监控用户VPC中所部署的应用的资源使用情况;
当所述应用的资源使用情况满足触发条件时,获取用户VPC中所部署的应用的副本数。
本申请实施例中系统可以自动实行扩容、缩容,只需要用户预先设定好扩容/缩容的触发条件即可。
为了便于本申请的实施,下面以实例进行说明。
实施例一:
当用户VPC中某个虚拟机出现故障时,所述管理VPC上的控制节点即可启动资源配置过程。
现有技术中,以kubernetes为例,可以通过副本控制器来控制相应应用的容器满足副本数要求,当副本不足时,副本控制器通知调度器创建新的容器,从而使副本数达到应用要求。
而本申请实施例中,用户的应用是部署于各自的用户VPC中的,在进行故障处理时需要考虑用户的VPC信息,确保新创建的容器/容器组在相应用户VPC内的虚拟机上;当相应用户VPC内的虚拟机数量不够时,还可以动态创建新的虚拟机。
图6示出了本申请实施例中系统的故障处理过程示意图,如图所示,本申请实施例的故障处理过程具体可以包括如下步骤:
步骤601、控制节点监控虚拟机状态;
步骤602、当所述控制节点发现某个虚拟机发生故障时,查询相应故障虚拟机的容器组和应用信息;
步骤603、控制节点查询应用信息表,获得各应用的副本数,并与预先设定的应用的副本数要求进行比对;
具体实施中,应用信息表可以如下表1.1所示:
应用信息表用来记录各个应用所部署到的容器节点信息、容器组信息。
步骤604、当发现某个应用的容器组副本数低于配置要求时,查找该应用所属用户的VPC信息;
步骤605、查询容器节点VPC映射表和容器节点资源监控信息表,确定相应VPC下各虚拟机资源是否足够;
如果资源足够,则执行步骤606;
如果资源不够,则执行步骤607。
具体实施中,容器节点VPC映射表可以如下表1.2所示:
容器节点VPC映射表用来记录每个VPC所包含的容器节点等信息。
容器节点资源监控信息表可以如下表1.3所示:
容器节点资源监控信息表用来记录各个容器节点的资源使用情况,例如,可以包括CPU、内存、硬盘、网络等相关信息。
控制节点可以定期更新上表中的相关信息。
步骤606、根据一定的策略在相应用户VPC的虚拟机中找到目标虚拟机;
步骤607、用户VPC管理模块通过调用IaaS云平台API创建虚拟机;
步骤608、控制节点与目标虚拟机的本地容器管理模块通信,创建相应应用的容器组/容器,控制节点更新应用信息表。
实施例二:
用户在管理自己部署的应用时,可以修改、删除应用副本的数量,主动发起应用扩容、缩容等操作。
当用户更新了应用副本数的配置信息时,系统启动相应的流程以完成用户的扩容、缩容操作。
图7示出了本申请实施例中用户发起应用扩容/缩容的过程示意图,如图所示,可以包括如下步骤:
步骤701、接收用户发送的更新应用副本数配置信息的请求;
步骤702、控制节点查询应用信息表,获得当前各应用的副本数,并与用户更新后的应用的副本数要求进行比对;
步骤703、当发现某个应用的容器组副本数低于配置要求时,查找该应用所属用户的VPC信息;
步骤704、查询容器节点VPC映射表和容器节点资源监控信息表,确定相应VPC下各虚拟机资源是否足够;
如果资源足够,则执行步骤705;
如果资源不够,则执行步骤706。
步骤705、根据一定的策略在相应用户VPC的虚拟机中找到目标虚拟机;
步骤706、用户VPC管理模块通过调用IaaS云平台API创建虚拟机;
步骤707、控制节点与目标虚拟机的本地容器管理模块通信,创建相应应用的容器组/容器,控制节点更新应用信息表。
实施例三:
用户还可以开启应用自动扩容/缩容功能,并设置自动扩容/缩容的触发条件,这样,当满足触发条件时,系统则自动发起扩容/缩容操作。
其中,触发条件可以根据应用的网络连接数、容器/容器组的资源使用率等参数进行设置。
图8示出了本申请实施例中系统自动扩容的过程示意图,如图所示,所述自动扩容过程可以包括如下步骤:
步骤801、控制节点可以通过查询应用资源使用情况信息表,监控每个应用的资源使用情况;
具体实施中,应用资源使用情况信息表可以如下表1.4所示:
应用资源使用情况信息表用于记录每个应用的负载情况,进而可以支持应用的自动扩容/缩容功能。
步骤802、当发现资源使用情况达到自动扩容的触发条件时,更新应用副本数配置信息;
步骤803、控制节点查询应用信息表,获得当前各应用的副本数,并与用户更新后的应用的副本数要求进行比对;
步骤804、当发现某个应用的容器组副本数低于配置要求时,查找该应用所属用户的VPC信息;
步骤805、查询虚拟机VPC映射表和虚拟机资源监控信息表,确定相应VPC下各虚拟机资源是否足够;
如果资源足够,则执行步骤806;
如果资源不够,则执行步骤807。
步骤806、根据一定的策略在相应用户VPC的虚拟机中找到目标虚拟机;
步骤807、用户VPC管理模块通过调用IaaS云平台API创建虚拟机;
步骤808、控制节点与目标虚拟机的本地容器管理模块通信,创建相应应用的容器组/容器,控制节点更新应用信息表。
其中,本申请实施例中控制节点可以定期采集各应用所在容器组/容器的资源使用情况,记录在应用资源使用情况信息表中。
采集方法可以是:
控制节点向该VPC下各容器节点发送采集命令,主动收集各容器组/容器的资源使用情况信息;
或者,
该VPC下各容器节点本地容器管理模块收集本节点内各容器组/容器的资源使用信息,上报给控制节点。
另外,控制节点还可以定期采集各容器节点的资源使用情况,记录在容器节点资源监控信息表中。
采集方法可以为:
控制节点向该VPC下各容器节点发送采集命令,主动收集资源使用情况信息;
或者,
该VPC下各容器节点本地容器管理模块收集本节点资源使用信息,上报给控制节点。
基于同一发明构思,本申请实施例中还提供了一种资源配置装置,由于这些设备解决问题的原理与一种资源配置方法相似,因此这些设备的实施可以参见方法的实施,重复之处不再赘述。
图9示出了本申请实施例中资源配置装置的结构示意图,如图所示,所述资源配置装置可以包括:
第一获取模块901,用于管理虚拟私有云VPC上的控制节点获取用户VPC中所部署的应用的副本数;
第一判断模块902,用于所述控制节点判断所述用户VPC中所部署的应用的副本数是否与配置要求的数量相同;
第一配置模块903,用于所述控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安全隧道配置所述用户VPC上的容器。
实施中,所述第一配置模块具体可以用于如果所述用户VPC中所部署的应用的副本数低于配置要求的数量,所述控制节点通过所述管理VPC与所述用户VPC之间的安全隧道,为所述用户VPC创建容器;所述容器用于部署所述应用的副本。
实施中,所述第一配置模块具体可以用于如果所述用户VPC中所部署的应用的副本数高于配置要求的数量,所述控制节点向所述应用副本所在的虚拟机上的本地容器管理模块发送容器释放消息,所述本地容器管理模块根据所述容器释放消息释放部署所述应用副本的容器。
实施中,所述装置可以进一步包括:
第二获取模块904,用于在所述控制节点确定所述用户VPC中所部署的应用的副本数低于预先配置数量之后,为所述用户VPC创建容器之前,所述控制节点获取所述用户VPC的虚拟机信息;
第二判断模块905,用于所述控制节点判断所述用户VPC中的虚拟机资源是否足够部署所述应用的副本;
第二配置模块906,用于如果所述用户VPC中的虚拟机资源不足以部署所述应用的副本,所述管理VPC上的用户VPC管理模块为所述用户VPC创建虚拟机。
实施中,所述第一配置模块具体可以包括:
确定单元,用于所述控制节点确定所述用户VPC中的目标虚拟机;
发送单元,用于所述控制节点通过所述管理VPC与用户VPC之间的安全隧道,向所述目标虚拟机上的本地容器管理模块发送容器创建消息;
创建单元,用于所述虚拟机上的本地容器管理模块通过所述安全隧道从所述管理VPC上的容器库下载容器模板,根据所述容器模板创建容器。
实施中,所述第一获取模块具体可以包括:
第一监控单元,用于所述管理VPC上的控制节点监控用户VPC的虚拟机状态;
第一获取单元,用于当所述控制节点发现所述用户VPC的虚拟机出现故障时,获取所述用户VPC中所部署的应用的副本数。
实施中,所述第一获取模块具体可以用于所述管理VPC上的控制节点接收到用户的应用副本数更新请求时,获取用户VPC中所部署的应用的副本数。
实施中,所述第一获取模块具体可以包括:
第二监控单元,用于所述管理VPC上的控制节点监控用户VPC中所部署的应用的资源使用情况;
第二获取单元,用于当所述应用的资源使用情况满足触发条件时,获取用户VPC中所部署的应用的副本数。
为了描述的方便,以上所述装置的各部分以功能分为各种模块或单元分别描述。当然,在实施本申请时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。