一种资源配置方法及装置的制造方法
【技术领域】
[0001] 本申请设及云计算技术领域，尤其设及一种资源配置方法及装置。
【背景技术】
[0002] Docker是一个开源的应用容器引擎，允许开发者打包应用到容器中，适合大规模 分布式应用和大数据处理应用场景。
[0003] 图1示出了现有技术中Docker管理环境的架构示意图，如图所示，包括：控制节 点、容器库、配置/服务发现存储系统W及多台容器节点。其中，
[0004] (1)控制节点实现了对外的调用接口和集群内资源调度功能； 阳0化](2)容器库实现了容器的注册和发布功能，在部署容器时可直接从容器库中将相 关的容器移动待部署的机器上；
[0006] (3)配置/服务发现存储系统用于共享配置并实现服务发现功能；
[0007] (4)容器节点用于实际运行Docker容器。
[0008] 具体的，在每台容器节点上运行了本地容器管理模块、代理模块，其中，
[0009] (1)本地容器管理模块用于与控制节点通信，并根据控制节点的指令在本地创建 容器组，容器组可W包含一个或多个容器；
[0010] (2)代理模块用于解决同一宿主机相同服务端口冲突的问题，还具备service转 发服务端口来对外提供服务的能力。
[0011] 目前，Docker管理环境中的运些组件通常部署在一个数据中屯、内部的多台物理网 络互通的物理服务器或多台虚拟机上。由于管理环境部署于同一个局域网内，各物理服务 器或虚拟机之间没有安全隔离机制，不同用户的应用通过容器进行隔离。当系统进行组件、 资源等的配置管理时，控制节点可W通过交换机或虚拟交换机可W向某个物理机或虚拟机 发送增加、删除组件消息，其他用户也可W向该物理机或虚拟机发送攻击性的消息，例如修 改、删除应用等。
[0012] 现有技术不足在于：
[0013] Docker管理环境中系统的配置管理过程中，用户的应用存在一定的安全风险。
【发明内容】
[0014] 本申请实施例提出了一种资源配置方法及装置，W解决现有技术中系统的配置管 理过程中，用户的应用存在一定安全风险的技术问题。
[0015] 本申请实施例提供了一种资源配置方法，包括如下步骤：
[0016] 管理虚拟私有云VPC上的控制节点获取用户VPC中所部署的应用的副本数；所述 用户VPC用于存放所述用户的应用；
[0017] 所述控制节点判断所述用户VPC中所部署的应用的副本数是否与配置要求的数 量相同；
[0018] 所述控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安全隧道配 置所述用户VPC上的容器。
[0019] 本申请实施例提供了一种资源配置装置，包括：
[0020] 第一获取模块，用于管理虚拟私有云VPC上的控制节点获取用户VPC中所部署的 应用的副本数；所述用户VPC用于存放所述用户的应用；
[0021] 第一判断模块，用于所述控制节点判断所述用户VPC中所部署的应用的副本数是 否与配置要求的数量相同；
[0022] 第一配置模块，用于所述控制节点根据判断结果通过所述管理VPC与所述用户 VPC之间的安全隧道配置所述用户VPC上的容器。
[0023] 有益效果如下：
[0024] 本申请实施例所提供的资源配置方法及装置，在进行资源配置时，由管理VPC上 的控制节点获取用户VPC中所部署的应用的副本数，并判断所述用户VPC中所部署的应用 的副本数是否低于预先配置数量，所述管理VPC上的控制节点根据判断结果通过所述管理 VPC与所述用户VPC之间的安全隧道配置所述用户VPC上的容器，W满足配置要求。本申请 实施例中，由于用户的应用部署于用户VPC中，由管理VPC分别通过与各个用户VPC之间的 安全隧道来管理、配置相应的用户VPC，用户之间通过VPC隔离，从而确保在资源配置时只 有管理VPC可W与所述用户VPC通信，其他用户无法访问或攻击所述用户VPC，提高了用户 应用的安全性。
【附图说明】
[0025] 下面将参照附图描述本申请的具体实施例，其中： 阳0%] 图1示出了现有技术中Docker管理环境部署的架构示意图；
[0027] 图2示出了现有技术中WKubernetes为例的Docker管理环境示意图；
[002引图3示出了本申请实施例中资源配置方法实施的流程示意图； 阳029] 图4示出了本申请实施例中Docker实现系统的结构示意图一；
[0030] 图5示出了本申请实施例中Docker实现系统的结构示意图二；
[0031] 图6示出了本申请实施例中系统的故障处理过程示意图；
[0032] 图7示出了本申请实施例中用户发起应用扩容的过程示意图；
[0033] 图8示出了本申请实施例中系统自动扩容的过程示意图；
[0034] 图9示出了本申请实施例中资源配置装置的结构示意图。
【具体实施方式】
[0035] 为了使本申请的技术方案及优点更加清楚明白，W下结合附图对本申请的示例性 实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是 所有实施例的穷举。并且在不冲突的情况下，本说明中的实施例及实施例中的特征可W互 相结合。
[0036] 发明人在发明过程中注意到：
[0037] 目前kubernetes为常用的Docker容器集群管理系统，它为容器化的应用提供了 资源调度、部署运行、服务发现、扩容缩容等功能。
[0038] 图2示出了现有技术中Wkubernetes为例的Docker管理环境示意图，如图所 不，Docker管理环境可W包括控制节点kubernetesmaster、容器库Dockerregistry、 高可用的键值存储系统ETCD(-个分布式强一致性的key/value存储）和多台容器节点 kubernetesnode。
[0039] 在kubernetes中，kubernetesmaster实现了API(应用编程接口，Application ProgrammingInte;rface)服务器server、副本控制器replicationcontrollers、调度器 sche化Ier等功能模块，其中：
[0040] APIserver作为kubernetes系统的入口，封装了核屯、对象的增加、删除、修改、查 询操作，WRESTF^iI(表述性状态转移，RepresentationalStateTransfer)接口方式提供 给外部客户和内部组件调用。它维护的REST对象将持久化到ETCD。
[0041 ]ReplicationController实现复制多个化d副本，往往一个应用需要多个化d来支撑，并且可W保证其复制的副本数，即使副本所调度分配的主宿机出现异常，通过 ReplicationController可W保证在其它主宿机启用同等数量的化d。
[0042] SChe化Ier负责集群的资源调度，为新建的pod分配机器。
[0043] 在容器节点上运行了本地容器管理模块kubelet、代理模块proxy,其中：
[0044] 本地容器管理模块用于与控制节点（Master)通信，并根据控制节点的指令在 本地创建容器组可W包含一个容器或多个相关的容器；在kubernetes中，通常W容器组 (POD)为单位来进行调度；
[0045] 代理模块（Proxy)用于解决同一主宿机的相同服务端口冲突的问题，还提供了 Service转发服务端口对外提供服务的能力。
[0046] 运些组件可W部署在一个数据中屯、内部的多台物理网络互通的物理服务区或虚 拟机上。具体的，可W将其中某些组件部署在相同的物理机或虚拟机上，例如，将控制节点 和容器库放在相同的物理机或虚拟机上，配置/服务发现存储系统在3个或3个W上的物 理机或虚拟机上独立集群部署。
[0047] 综上可W看出，现有Docker运行环境大多是部署在同一局域网内的物理机或虚 拟机上，彼此之间可W直接通信，不同的用户的应用可W通过容器container隔离。
[0048] 但运种方式，当系统进行资源配置管理时，控制节点可W通过交换机或虚拟交换 机可W向某个物理机或虚拟机发送增加、删除资源的消息，其他用户也可W向该物理机或 虚拟机发送攻击性的消息，例如修改、删除应用等。
[0049] 因此，现有技术可能存在用户的应用被其他用户攻击的风险，不能防止来自容器 的入侵，安全性较低，对于资源隔离要求高、安全性要求高的多租户场景并不适用。
[0050] 为了解决上述问题，本申请实施例提出将容器container与虚拟私有云（VPC， VirtualPrivateCloud)结合起来，通过VPC的机制弥补容器所固有的安全缺陷，也即，将 不同用户的应用放在不同VPC的虚拟机上，同一用户的不同应用使用container隔离，W提 高安全性。
[0051] 基于此，本申请实施例提出了一种资源配置方法及装置，下面进行说明。
[0052] 图3示出了本申请实施例中资源配置方法实施的流程示意图，如图所示，所述资 源配置方法可W包括如下步骤：
[0053] 步骤301、管理VPC上的控制节点获取用户VPC中所部署的应用的副本数；所述用 户VPC用于存放所述用户的应用；
[0054] 步骤302、所述控制节点判断所述用户VPC中所部署的应用的副本数是否与配置 要求的数量相同；
[0055] 步骤303、所述控制节点根据判断结果通过所述管理VPC与所述用户VPC之间的安 全隧道配置所述用户VPC上的容器。
[0056] 具体实施中，管理VPC上