一种Docker实现系统及其通信方法
技术领域
本申请涉及云计算技术领域,尤其涉及一种Docker实现系统及其通信方法。
背景技术
Docker是一个开源的应用容器引擎,允许开发者打包应用到容器中,适合大规模分布式应用和大数据处理应用场景。
图1示出了现有技术中Docker管理环境的架构示意图,如图所示,包括:控制节点、容器库、配置/服务发现存储系统以及多台容器节点。其中,
(1)控制节点实现了对外的调用接口和集群内资源调度功能;
(2)容器库实现了容器的注册和发布功能,在部署容器时可直接从容器库中将相关的容器移动待部署的机器上;
(3)配置/服务发现存储系统用于共享配置并实现服务发现功能;
(4)容器节点用于实际运行Docker容器。
具体的,在每台容器节点上运行了本地容器管理模块、代理模块,其中,
(1)本地容器管理模块用于与控制节点通信,并根据控制节点的指令在本地创建容器组,容器组可以包含一个或多个容器;
(2)代理模块用于解决同一宿主机相同服务端口冲突的问题,还具备service转发服务端口来对外提供服务的能力。
目前,Docker管理环境中的这些组件通常部署在一个数据中心内部的多台物理网络互通的物理服务器或多台虚拟机上。由于管理环境部署于同一个局域网内,各物理服务器或虚拟机之间没有安全隔离机制,不同用户的应用通过容器进行隔离,因此,用户的应用存在被其他用户攻击的风险。
现有技术不足在于:
Docker管理环境中用户的应用通过容器隔离,存在一定安全风险。
发明内容
本申请实施例提出了一种Docker实现系统及其通信方法,以解决现有技术中用户的应用通过容器隔离,存在一定安全风险的技术问题。
本申请实施例提供了一种Docker实现系统,包括管理虚拟私有云VPC和用户VPC,每个VPC中包含虚拟路由装置和虚拟机,其中,
所述管理VPC包括用户VPC管理模块、控制节点、容器库和配置服务发现存储系统,所述用户VPC管理模块、控制节点、容器库和配置服务发现存储系统与所述管理VPC的虚拟路由装置连接;
所述用户VPC的虚拟机上部署有本地容器管理模块、代理模块和容器container,所述虚拟机与所述用户VPC的虚拟路由装置连接,所述容器用于存放所述用户的应用;
所述管理VPC的虚拟路由装置与所述用户VPC的虚拟路由装置存在安全隧道。
本申请实施例提供了上述系统的通信方法,包括如下步骤:
所述控制节点发送消息至所述管理VPC的虚拟路由装置,所述消息中包括用户VPC信息及其虚拟机信息;
所述管理VPC的虚拟路由装置根据所述用户VPC信息确定消息发送的隧道,将所述消息发送至所述隧道,所述隧道的终点为所述用户VPC的虚拟路由装置;
所述用户VPC的虚拟路由装置根据所述用户VPC的虚拟机信息确定所述消息的目标地址,将所述消息发送至所述用户VPC的虚拟机;
所述用户VPC的虚拟机将所述消息传递至所述虚拟机的本地容器管理模块。
本申请实施例提供了上述系统的另一种通信方法,包括如下步骤:
所述本地容器管理模块发送消息至所述用户VPC的虚拟路由装置,所述消息中包括管理VPC信息及其虚拟机信息;
所述用户VPC的虚拟路由装置根据所述管理VPC信息确定消息发送的隧道,将所述消息发送至所述隧道,所述隧道的终点为所述管理VPC的虚拟路由装置;
所述管理VPC的虚拟路由装置根据所述管理VPC的虚拟机信息确定所述消息的目标地址,将所述消息发送至所述管理VPC的虚拟机;
所述管理VPC的虚拟机将所述消息传递至所述虚拟机的控制节点。
有益效果如下:
本申请实施例所提供的Docker实现系统及其通信方法,包括管理VPC和用户VPC,每个VPC中包含虚拟路由装置和虚拟机,所述管理VPC与用户VPC通过各自的虚拟路由装置之间的安全隧道进行通信,由管理VPC统一管理用户VPC,形成安全的管理网络,由于管理VPC与用户VPC建立安全隧道,所述用户VPC与所述管理VPC通过安全隧道进行通信,用户VPC之间不能互相访问,从而起到了隔离作用,减少了用户的应用被其他用户攻击的风险,提高了系统安全性。
附图说明
下面将参照附图描述本申请的具体实施例,其中:
图1示出了现有技术中Docker管理环境部署的架构示意图;
图2示出了现有技术中以Kubernetes为例的Docker管理环境示意图;
图3示出了本申请实施例中Docker实现系统的结构示意图一;
图4示出了本申请实施例中Docker实现系统的结构示意图二;
图5示出了本申请实施例中Docker实现系统的通信方法实施的流程示意图;
图6示出了本申请实施例中控制节点与本地容器管理模块之间的交互示意图;
图7示出了本申请实施例中Docker实现系统的另一种通信方法实施的流程示意图;
图8示出了本申请实施例中本地容器管理模块与控制节点之间的交互示意图;
图9示出了本申请实施例中Docker实现系统的结构示意图三。
具体实施方式
为了使本申请的技术方案及优点更加清楚明白,以下结合附图对本申请的示例性实施例进行进一步详细的说明,显然,所描述的实施例仅是本申请的一部分实施例,而不是所有实施例的穷举。并且在不冲突的情况下,本说明中的实施例及实施例中的特征可以互相结合。
发明人在发明过程中注意到:
目前Kubernetes为常用的Docker容器集群管理系统,它为容器化的应用提供了资源调度、部署运行、服务发现、扩容缩容等功能。
图2示出了现有技术中以Kubernetes为例的Docker管理环境示意图,如图所示,Docker管理环境可以包括控制节点Kubernetes master、容器库Docker registry、高可用的键值存储系统ETCD(一个分布式强一致性的key/value存储)和多台容器节点Kubernetesnode。
在kubernetes中,kubernetes master实现了API服务器server、副本控制器replication controllers、调度器scheduler等功能模块,其中:
API server作为kubernetes系统的入口,封装了核心对象的增加、删除、修改、查询操作,以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到ETCD。
Replication Controller实现复制多个Pod副本,往往一个应用需要多个Pod来支撑,并且可以保证其复制的副本数,即使副本所调度分配的主宿机出现异常,通过Replication Controller可以保证在其它主宿机启用同等数量的Pod。
scheduler负责集群的资源调度,为新建的pod分配机器。
在容器节点上运行了本地容器管理模块kubelet、代理模块proxy,其中:
本地容器管理模块用于与控制节点(Master)通信,并根据控制节点的指令在本地创建容器组可以包含一个容器或多个相关的容器;在kubernetes中,通常以容器组(POD)为单位来进行调度;
代理模块(Proxy)用于解决同一主宿机的相同服务端口冲突的问题,还提供了Service转发服务端口对外提供服务的能力。
这些组件可以部署在一个数据中心内部的多台物理网络互通的物理服务区或虚拟机上。具体的,可以将其中某些组件部署在相同的物理机或虚拟机上,例如,将控制节点和容器库放在相同的物理机或虚拟机上,配置/服务发现存储系统在3个或3个以上的物理机或虚拟机上独立集群部署。
综上可以看出,现有Docker运行环境大多是部署在同一局域网内的物理机或虚拟机上,彼此之间可以直接通信,不同的用户的应用可以通过容器container隔离。但这种方式可能存在用户的应用被其他用户攻击的风险,不能防止来自容器的入侵,安全性较低,对于资源隔离要求高、安全性要求高的多租户场景并不适用。
为了解决上述问题,本申请实施例提出将容器container与虚拟私有云VPC结合起来,通过VPC的机制弥补容器所固有的安全缺陷,也即,将不同用户的应用放在不同VPC的虚拟机上,同一用户的不同应用使用container隔离,以提高安全性。
本申请实施例提出的container与VPC结合的结构,即基于VPC部署用户的Docker,每个用户的容器部署在单独的VPC中保障不同用户的容器被严格的隔离起来。
要实现这样的目的,最直接的方法可以是在每个VPC中独立部署一套完整的Docker环境,即每个VPC中部署一套控制节点、容器库、配置/服务发现存储系统以及多台容器节点。
但发明人又注意到,由于控制节点、容器库、配置/服务发现存储系统需要占用独立的虚拟机,多套VPC分别部署完整的Docker环境浪费较多的资源;同时,一些企业用户为了实现企业内部不同部门的隔离,可能需要同时配置多个VPC,每个VPC内均部署完整的Docker环境会导致资源浪费、成本较高。
基于此,本申请实施例提出了一种Docker实现系统及其通信方法,下面进行详细说明。
图3示出了本申请实施例中Docker实现系统的结构示意图一,如图所示,所述Docker实现系统可以包括管理VPC和用户VPC,每个VPC中包含虚拟路由装置和虚拟机,其中,
所述管理VPC包括用户VPC管理模块、控制节点、容器库和配置服务发现存储系统,所述用户VPC管理模块、控制节点、容器库和配置服务发现存储系统与所述管理VPC的虚拟路由装置连接;
所述用户VPC的虚拟机上部署有本地容器管理模块、代理模块和容器container,所述虚拟机与所述用户VPC的虚拟路由装置连接,所述容器用于存放所述用户的应用;
所述管理VPC的虚拟路由装置与所述用户VPC的虚拟路由装置存在安全隧道。
发明人注意到,为了在提高安全性的前提下进一步降低资源浪费,本申请实施例可以将现有技术中Docker的管理调度节点单独放在管理VPC中,这种情况下,需要建立管理VPC与用户VPC的网络连接,同时保障不同用户VPC之间的网络隔离。因此,本申请实施例各个VPC中均可以包括虚拟路由装置,然后通过管理VPC的虚拟路由装置与用户VPC的虚拟路由装置建立安全隧道,实现管理VPC与用户VPC的网络连接并确保用户VPC之间的网络隔离。
其中,所述用户VPC管理模块用于管理所述用户VPC。
具体实施中,所述用户VPC管理模块可以通过调用IaaS(基础设施即服务,Infrastructure as a Service)云平台的API(应用程序编程接口,ApplicationProgramming Interface)实现管理所述用户VPC,所述管理所述用户VPC可以包括动态创建/删除用户VPC及其虚拟路由装置、建立所述用户VPC与管理VPC之间的安全隧道、设置管理VPC中虚拟路由装置的安全策略、在用户VPC中动态增加或删除虚拟机等。
本申请实施例可以通过在用户VPC的虚拟机中配置控制节点的地址等,来实现所述用户VPC的虚拟机中的本地容器管理模块与所述管理VPC中的控制节点建立通信。
另外,发明人还注意到,现有技术中是把所有的容器节点看作是对等的,即不同的容器节点是平等关系,在进行资源分配时主要考虑不同容器节点的负载情况和应用之间的关系即可。
在本申请实施例中,由于本申请实施例引入了VPC架构,因此所述控制节点可以保存用户信息、用户VPC信息、用户VPC的虚拟路由装置信息、用户VPC的虚拟机信息之间的对应关系,以及用户VPC信息与所述用户VPC内容器信息之间的对应关系。
具体实施中,上述对应关系可以分别以多个表格的形式体现,下面进行详细说明。
1、用户和用户VPC的映射表,用于保存用户信息、用户VPC信息之间的对应关系,具体可以如下表1.1所示:
用户VPC映射表可以记录有用户标识ID信息以及用户VPC ID信息等,每个用户可以有一个或多个用户VPC,此时该用户VPC映射表中对于每个用户可能会生成一条或多条记录。
2、容器节点和用户VPC的映射表,用于保存用户VPC信息与所述用户VPC内的容器节点信息之间的对应关系,具体可以如下表1.2所示:
容器节点和用户VPC的映射表记录有每个用户VPC中所包含的容器节点等信息。
3、容器资源监控信息表,用于记录各个容器节点的资源使用情况,可以包括CPU、内存、硬盘、网络等信息,具体可以如下表1.3所示:
本申请实施例中控制节点可以定期更新表内的相关信息。
4、应用信息表,用于记录各个应用所部署到的容器信息、容器组信息等,具体可以如下表1.4所示:
5、应用资源使用信息表,用于记录每个应用的负载情况,具体可以如下表1.5所示:
具体实施中,本申请实施例中的本地管理模块和代理模块可以在建立虚拟机后部署,也可以事先在虚拟机镜像模板中进行预部署。
由于本申请实施例中所述管理VPC与所述用户VPC建立安全隧道,不同用户的应用分别部署于不同的用户VPC上,用户之间通过VPC实现隔离,由于不同用户VPC之间无法互相访问,因此,本申请实施例相比现有技术的容器隔离来说安全性更高。
实施中,所述用户VPC管理模块、控制节点、容器库和配置服务发现存储系统可以分别部署于所述管理VPC中不同的虚拟机上,或者所述用户VPC管理模块、控制节点和容器库部署于同一虚拟机、所述配置服务发现存储系统集群部署于所述管理VPC的其他虚拟机上。
具体实施时,所述管理VPC中部署Docker管理环境的用户VPC管理模块、控制节点、容器库和配置服务发现存储系统,可以将这些组件分别部署于不同的虚拟机上,也可以将其中部分组件部署于相同虚拟机上,例如:所述用户VPC管理模块、控制节点和容器库放在相同的虚拟机上、所述配置服务发现存储系统集群在其他虚拟机上单独部署。
通常,为了节省资源可以将所述配置服务发现存储系统部署于单独的虚拟机上,将所述用户VPC管理模块、控制节点和容器库部署于同一虚拟机中。所述配置服务发现存储系统集群部署于所述管理VPC的3个或3个以上的虚拟机上。
实施中,所述用户VPC可以为多个,所述管理VPC的虚拟路由装置与所述用户VPC的虚拟路由装置存在安全隧道,具体可以为,所述管理VPC的虚拟路由装置分别与每个用户VPC的虚拟路由装置存在安全隧道,各用户VPC之间不存在隧道。
具体实施中,本申请实施例中的虚拟路由装置可以为虚拟路由器vRouter、虚拟网关vGateway等。
图4示出了本申请实施例中Docker实现系统的结构示意图二,如图所示,本申请实施例中,当用户VPC为多个时,管理VPC的虚拟路由装置可以分别与每个用户VPC的虚拟路由装置建立安全隧道,各个用户VPC之间不存在用于通信的隧道,确保每个用户VPC只能与管理VPC通信,用户VPC之间不可访问,从而提高用户应用的安全性。
实施中,所述安全隧道可以为通用路由封装(GRE,Generic RoutingEncapsulation)隧道或因特网协议安全性(IPSEC,Internet Protocol Security)隧道。
其中,GRE隧道是用一种网络协议PDU封装另一种网络协议PDU的技术,可以像真实的网络接口那样传递多播数据包;IPSEC隧道将原始数据包封装在新的数据包内部,隧道两端并不关心起点与终点之间的任何路由器、交换机等安全网关。
实施中,所述管理VPC的虚拟路由装置不具备路由转发功能。
本申请实施例中虽然各用户VPC之间可能无法直接通信,在一定程度上提高了安全性,但考虑到所有用户VPC均会与管理VPC建立安全隧道,将所述管理VPC的虚拟路由装置设定为无法进行路由转发,从而可以确保管理VPC在与其中某个用户VPC通信时,其他用户无法通过所述管理VPC进行路由转发来攻击所述用户VPC,进一步提高了安全性。
具体实施中,本申请实施例中管理VPC中的虚拟路由装置与其他用户VPC的虚拟路由装置建立安全隧道,为了进一步提高安全性,还可以在管理VPC的虚拟路由装置上设置安全策略,防止不同用户VPC通过所述管理VPC通信。具体实施时,可以在管理VPC的虚拟路由装置上设置访问控制策略防止不同用户VPC通过管理VPC互相访问,限制用户VPC之间的通信。
实施中,所述用户VPC的虚拟机上部署有容器具体可以为,所述用户VPC的虚拟机上包括一个或多个容器组,所述容器组中包括一个或多个容器。
本申请实施例通过以容器组为单位,将相关的应用放在一个容器组内的不同容器中,同一个容器组内的容器可以在同一台虚拟机上运行,实现彼此之间的数据共享和通信,简化管理。
在现有技术中,由于Docker管理环境部署于同一局域网中,因此组件之间可以直接通信。而本提案中,由于不同模块跨越了不同的VPC,因此,通信方式也与现有技术有所区别。基于此,本申请实施例还提出了一种上述系统的通信方法,下面进行说明。
图5示出了本申请实施例中Docker实现系统的通信方法实施的流程示意图,如图所示,所述Docker实现系统的通信方法可以包括如下步骤:
步骤501、所述控制节点发送消息至所述管理VPC的虚拟路由装置,所述消息中包括用户VPC信息及其虚拟机信息;
步骤502、所述管理VPC的虚拟路由装置根据所述用户VPC信息确定消息发送的隧道,将所述消息发送至所述隧道,所述隧道的终点为所述用户VPC的虚拟路由装置;
步骤503、所述用户VPC的虚拟路由装置根据所述用户VPC的虚拟机信息确定所述消息的目标地址,将所述消息发送至所述用户VPC的虚拟机;
步骤504、所述用户VPC的虚拟机将所述消息传递至所述虚拟机的本地容器管理模块。
实施中,在所述控制节点发送消息至所述管理VPC的虚拟路由装置之前,所述方法可以进一步包括:
控制节点接收用户的应用部署请求,所述请求中包括所述用户的标识ID;
所述控制节点根据所述用户ID确定所述用户的用户VPC信息及其虚拟机信息。
实施中,所述方法可以进一步包括:
所述本地容器管理模块通过所述用户VPC与所述管理VPC之间的安全隧道发送容器模板下载请求;
所述管理VPC通过所述安全隧道接收到所述请求后,将所述容器库中的容器模板发送至所述本地容器管理模块。
具体实施中,所述控制节点可以监控并存储所述用户VPC中容器资源使用信息和所述容器内应用的资源使用信息。
本申请实施例以管理VPC的控制节点与用户VPC的虚拟机的本地容器管理模块之间的通信为例,说明通信过程如下:
假设,管理VPC为VPC0,管理VPC的控制节点所在虚拟机为VM00,管理VPC的虚拟路由器为VR0;第n个用户的用户VPC为VPCn,第n个用户VPC的虚拟路由器为VRn;第n个用户中的第i个虚拟机为VMni。
图6示出了本申请实施例中控制节点与本地容器管理模块之间的交互示意图,如图所示,可以包括如下步骤:
步骤601、控制节点发送消息,所述消息的目标地址为VMni的管理地址,内容可以为与VMni的本地容器管理模块的交互内容;
步骤602、控制节点所在虚拟机VM00将所述消息发送至管理VPC的虚拟路由器VR0;
步骤603、管理VPC的虚拟路由器VR0根据目标地址(即VMni的管理地址),查找相应的隧道;
步骤604、管理VPC的虚拟路由器VR0将所述消息进行隧道封装;
步骤605、管理VPC的虚拟路由器VR0将所述消息发送至相应的隧道;所述隧道的终点为用户VPC的虚拟路由器VRn;
步骤606、用户VPC的虚拟路由器VRn接收到所述消息后进行解封装;
步骤607、用户VPC的虚拟路由器VRn根据所述消息的目标地址将所述消息发送至用户VPC的虚拟机VMni;
步骤608、用户VPC的虚拟机VMni将所述消息发送给本地容器管理模块。
图7示出了本申请实施例中Docker实现系统的另一种通信方法实施的流程示意图,如图所示,所述Docker实现系统的通信方法可以包括如下步骤:
步骤701、所述本地容器管理模块发送消息至所述用户VPC的虚拟路由装置,所述消息中包括管理VPC信息及其虚拟机信息;
步骤702、所述用户VPC的虚拟路由装置根据所述管理VPC信息确定消息发送的隧道,将所述消息发送至所述隧道,所述隧道的终点为所述管理VPC的虚拟路由装置;
步骤703、所述管理VPC的虚拟路由装置根据所述管理VPC的虚拟机信息确定所述消息的目标地址,将所述消息发送至所述管理VPC的虚拟机;
步骤704、所述管理VPC的虚拟机将所述消息传递至所述虚拟机的控制节点。
图8示出了本申请实施例中本地容器管理模块与控制节点之间的交互示意图,如图所示,可以包括如下步骤:
步骤801、用户VPC中虚拟机上的本地容器管理模块可以发送消息,所述消息的目标地址为所述管理VPC控制节点的管理地址,内容可以为与控制节点的交互内容;
步骤802、所述本地容器管理模块所在虚拟机将所述消息发送至所述用户VPC的虚拟路由器;
步骤803、所述用户VPC的虚拟路由器根据目标地址(即控制节点的管理地址),查找相应的隧道;
步骤804、所述用户VPC的虚拟路由器将所述消息进行隧道封装;
步骤805、所述用户VPC的虚拟路由器将所述消息发送至相应的隧道;所述隧道的终点为管理VPC的虚拟路由器;
步骤806、所述管理VPC的虚拟路由器接收到所述消息后进行解封装;
步骤807、所述管理VPC的虚拟路由器根据所述消息的目标地址将所述消息发送至所述管理VPC的虚拟机;
步骤808、所述管理VPC的虚拟机将所述消息发送给所述虚拟机上的控制节点。
为了便于本申请的实施,下面以实例进行说明。
图9示出了本申请实施例中Docker实现系统的结构示意图三,如图所示,本申请实施例对Docker实现系统及其通信方法说明如下:
一、系统原始状态
创建一个管理VPC(即VPC0)及其虚拟路由器VR0,在VPC0中创建两个虚拟机VM1、VM2,在VM1部署用户VPC管理模块、控制节点和容器库,在VM2中部署配置服务发现存储系统。
二、创建新用户
2.1、用户VPC管理模块可以通过调用IaaS(基础设施即服务,Infrastructure asa Service)云平台API(应用程序编程接口,Application Programming Interface)申请并创建一个VPC1和虚拟路由器VR1,并建立与VPC0的安全隧道、设置VPC0中虚拟路由器的安全策略;
2.2、用户VPC管理模块将该用户的ID和VPC1的ID记录到用户VPC映射表中;
2.3、用户VPC管理模块通过调用IaaS云平台API设置VPC0的VR0与VPC1的VR1之间的路由及安全策略,保证VR0与VR1之间互通但VR0不能将VR1的路由转发到其他用户VPC的vRouter上(如VPC2的VR2),从而保证不同用户的VPC之间不可访问,但管理VPC0中的虚拟机可以访问用户VPC1、VPC2...等中的虚拟机。
三、用户首次部署应用
3.1、用户VPC管理模块通过调用IaaS云平台API在VPC1(假设用户对应的VPC为VPC1)中创建虚拟机VM10;
在VM10中预先部署本地容器管理模块和代理模块(或者,事先在虚拟机镜像模板中做好预部署),并做相应配置(如配置控制节点的地址等),使VM10中的本地容器管理模块可以和控制模块通信,并将虚拟机ID、VPC ID信息记录到容器节点VPC映射表中;
3.2、根据应用部署的需要可以重复步骤3.1来创建多个虚拟机,如VM11、VM12...等;
3.3、控制节点根据用户ID,查找用户VPC映射表获得该用户对应VPC(即VPC1)的ID;然后查找容器节点VPC映射表,获得归属于VPC1的容器节点列表,根据一定的策略选择容器节点,向相应容器节点(如VM10)上的本地容器管理模块发送消息。
3.4、本地容器管理模块接收到消息后,根据消息中的用户定义的应用参数,从容器库将相应的容器模板下载到本地,并创建容器组或容器,完成应用的部署;
3.5、控制节点更新应用信息表,记录相关的应用及容器组信息、所在容器节点等信息,具体的,可以根据实际部署的容器节点个数,插入多条记录,以分别对应不同的容器组或容器。
四、用户后续部署应用
4.1、控制节点根据用户ID,查找用户VPC映射表获得该用户对应VPC(即VPC1)的ID,然后查找容器节点VPC映射表,获得归属于VPC1的容器节点列表;
4.2、控制节点获取属于VPC1的容器节点列表的资源使用信息,判断当前VPC1的容器节点是否能够满足新应用的部署需求;
4.3、若当前VPC1的容器节点不能满足新应用的部署需求,则按照步骤2.1由用户VPC管理模块通过调用IaaS云平台API来创建新的虚拟机;
4.4、控制节点可以根据负载均衡策略选择容器节点,向相应容器节点(如VM10)上的本地容器管理模块发送消息;
4.5、本地容器管理模块接收到消息后,根据消息中的用户定义的应用参数,从容器库将相应的容器模板下载到本地,并创建容器组或容器,完成应用的部署;
4.6、控制节点更新应用信息表,记录相关应用及容器组信息、所在容器节点等信息,具体的,可以根据实际部署的容器节点个数,插入多条记录,以分别对应不同的容器组或容器节点。
4.7、进行该VPC下各容器节点的资源使用情况的采集,记录在容器节点资源监控信息表中。
其中,采集方法可以如下:
控制节点向该VPC下各容器节点发送采集命令,主动收集资源使用情况信息;
或者,该VPC下各容器节点的本地容器管理模块收集本节点的资源使用信息,上报给控制节点。
五、用户应用释放方法
5.1、用户提出应用释放请求;
所述应用释放请求中可以包括用户ID和应用ID。
5.2、控制节点接收到所述应用释放请求,根据用户ID和应用ID查询应用信息表,获取相应的容器组、容器节点信息表;
5.3、控制节点向相应的容器节点的本地容器管理模块发送释放容器的消息,相应的容器节点的本地容器管理模块根据接收的消息释放相应的容器组/容器;
5.4、控制节点更新所述应用信息表,记录相关应用及容器组信息、所在容器节点等信息,具体的,可以根据实际部署的容器节点个数,插入多条记录,以分别对应不同的容器组、容器节点;
5.5、统计各容器节点资源使用信息;
5.6、当控制节点发现某个或某些容器节点资源空闲或者无应用部署时,可以通过用户VPC管理模块主动释放相应容器节点的虚拟机,并更新容器节点VPC映射表和容器节点资源监控信息表,删除相应的容器节点的信息;
5.7、当发现该用户所有应用都已释放并且不再使用资源时,可以通过用户VPC管理模块删除该用户对应的VPC,并更新用户VPC映射表信息。
六、故障处理
当某个容器节点出现故障时,控制节点可以启动自愈过程。
例如,在kubernetes中,通过副本控制器将控制相应应用的容器满足副本数要求,当副本不足时,可以通知调度器创建新的容器组/容器,从而使副本数达到应用要求。
本申请实施例与现有方案不同之处在于,故障处理考虑了用户的VPC信息,确保新创建的容器组/容器在相应用户的VPC内的容器节点上。当相应用户VPC内的容器节点数量不够时,动态创建新的虚拟机(容器节点)。
6.1、当控制节点发现某个容器节点故障时,查询相应的故障容器节点的容器组和应用信息;
6.2、根据应用配置要求,启动故障自愈过程如下:
a)控制节点查询应用信息表,获得各应用的副本数,并与应用的副本数要求进行比对;
b)当发现某个应用的容器组副本数低于配置要求时,查找该应用所属用户的VPC信息;
c)查询容器节点VPC映射表和容器节点资源监控信息表,确定相应VPC下各容器节点资源是否足够;
d)如果资源不够,则由用户VPC管理模块通过调用IaaS云平台API创建虚拟机(容器节点);
e)根据一定的策略在相应VPC中的容器节点中找到目标容器节点;
f)控制节点与目标容器节点的本地容器管理模块进行通信;
g)创建相应应用的容器组/容器;
h)更新应用信息表。
七、用户发起的应用扩容/缩容
7.1、用户更新应用副本数配置信息;
7.2、控制节点查询应用信息表,获得各应用的副本数,并与应用的副本数要求进行比对;
7.3、当发现某个应用的容器组副本数低于配置要求时,查找该应用所属用户的VPC信息、容器节点VPC映射表和容器节点资源监控信息表,确定相应VPC下各容器节点资源是否足够;
7.4、如果资源不够,则由用户VPC管理模块通过调用IaaS云平台API创建虚拟机(容器节点);
7.5、根据一定的策略在相应VPC中的容器节点中找到目标容器节点,控制节点与目标容器节点的本地容器管理模块进行通信,创建相应应用的容器组/容器,更新应用信息表。
八、系统自动应用扩容/缩容
本申请实施例可以根据用户预先设置的自动扩容/缩容的触发条件,自行进行扩容/缩容。
其中,触发条件可以为应用的网络连接数、容器/容器组的资源使用率等参数,本领域技术人员也可以根据实际需要设定其他的触发条件,本申请对此不作限制。
8.1、控制节点通过查询应用资源使用情况信息表监控每个应用的资源使用情况;
8.2、当发现资源使用信息达到自动扩容或缩容的触发条件,更新应用副本数配置信息;
8.3、控制节点查询应用信息表,获得各应用的副本数,并与应用的副本数要求进行比对;
8.4、当发现某个应用的容器组副本数低于配置要求时,查找该应用所属用户的VPC信息、容器节点VPC映射表和容器节点资源监控信息表,确定相应VPC下各容器节点资源是否足够;
8.5、如果资源不够,则由用户VPC管理模块通过调用IaaS云平台API创建虚拟机(容器节点);
8.6、根据一定的策略在相应VPC中的容器节点中找到目标容器节点,控制节点与目标容器节点的本地容器管理模块进行通信,创建相应应用的容器组/容器,更新应用信息表。
本申请实施例为了提升用户的安全性,解决Docker的安全问题,同时保留了Docker的自动打包、运维升级等方面的优势,提出了容器与VPC结合的架构,即,基于VPC部署用户的Docker,每个用户的容器部署在单独的VPC中,保障不同用户的容器被严格隔离起来。
本申请实施例提出了一种利用独立的管理VPC与用户VPC组成的统一的安全管理网络,在管理网络中跨不同的VPC,构建了统一的Docker管理环境,实现了不同用户的安全Docker容器管理和分配。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。