CN106445637B - 容器管理调度*** - Google Patents

Abstract

本发明涉及一种容器管理调度***，用于对应用程序进行封装，包括：至少一个计算节点，各计算节点分别包括至少一个容器封装单元，容器封装单元包括多个容器；资源管理模块，用于分配管理用于每个计算节点的***资源；容器调度模块，用于对各容器进行调度；其中，同一个容器封装单元中的各容器共享第一、第二及第三信息字段，第一、第二及第三信息字段分别使得同一个容器封装单元中的各容器：具有相同或相应的标识号；实现进程间通信；以及实现网络一致服务。其能够克服现有技术中VM技术的缺陷，提高复杂应用程序的开发效率、节省了开发及部署成本，并具备良好的***稳定性及可靠性。

Description

容器管理调度***

技术领域

本发明涉及对应用程序进行封装/打包，更具体地说，涉及一种容器管理调度***。

背景技术

现有技术主要以VM（虚拟机）来实现传统IaaS（Infrastructure as a Service）平台。然而，IaaS平台往往存在如下问题：

1. VM是有状态的。应用设计得不够完善时，有可能在VM上留下状态信息，导致横向扩展或者故障恢复时失败。

2. VM恢复速度较慢。如果使用本地盘，需要通过网络进行拷贝；即使应用统一存储，操作***本身的启动时间也在分钟级。

针对上述各种问题，“容器”方案逐渐开始受到业内的重视。“容器”是微服务化的一种具体技术，可以彻底解决应用状态不一致、迁移难度大等问题。但是容器是严格的单进程模式。

而在金融行业，涉及的金融应用程序往往都属于复杂应用，在单个VM上部署了多个进程，进程之间依赖性较强。这些复杂应用在迁移至标准容器的过程中，改造程度极大。如果将多个进程部署在一个容器中，则会出现资源冲突和互相影响，违背了使用容器的初衷；如果拆分多个进程至不同容器中，原先使用本地localhost访问以及ipc交互等方式都需要重新设计，改造成本也很大。

此外，复杂应用在使用容器并实现负载均衡时，也存在由于多进程导致的不匹配问题。目前针对容器的负载均衡还普遍存在单点问题，不满足金融行业复杂应用的高可用性要求。

发明内容

本发明的目的在于提供一种利用容器来封装复杂应用程序的容器管理调度***。

为实现上述目的，本发明提供一种技术方案如下：

一种容器管理调度***，用于对应用程序进行封装，该***包括：至少一个计算节点，各计算节点分别包括至少一个容器封装单元，容器封装单元包括多个容器；资源管理模块，与至少一个计算节点中的每个分别耦合，用于分配管理用于每个计算节点的***资源；容器调度模块，与资源管理模块相耦合，用于对各容器进行调度；其中，同一个容器封装单元中的各容器共享第一、第二及第三信息字段，第一、第二及第三信息字段分别使得同一个容器封装单元中的各容器：具有相同或相应的标识号；实现进程间通信；以及实现网络一致服务。

优选地，该***还包括分布式协调管理模块，用于为资源管理模块提供分布式协调管理服务以保证资源管理模块的高可用性。

优选地，容器封装单元还包括容器管理子模块，容器管理子模块用于根据对应的计算节点的命令对多个容器进行配置和/或管理。

优选地，容器封装单元还包括服务发现子模块，服务发现子模块用于为对应的多个容器设置共有的唯一访问入口。

优选地，容器封装单元利用Linux***下的Cgroup机制实现对该容器封装单元下的各容器所占用的***资源进行管理和/或隔离。

本发明提供的容器管理调度***，能够克服现有技术中VM（虚拟机）技术的缺陷，为开发人员带来了便利，提高了复杂应用程序的开发效率、节省了开发及部署成本。此外，上述容器管理调度***具备良好的***稳定性及可靠性，适于在业内推广应用。

附图说明

图1示出本发明第一实施例提供的容器管理调度***的模块结构示意图。

图2示出本发明第二实施例提供的容器管理调度***的模块结构示意图。

图3示出本发明第三实施例提供的容器管理调度***中一容器封装单元的模块结构示意图。

具体实施方式

如图1所示，本发明第一实施例提供一种容器管理调度***，其用于将一复杂应用程序打包封装于多个容器内，具体地，其包括容器调度模块101、资源管理模块102以及多个节点103。

其中，容器调度模块101与资源管理模块102相耦合，通过其可对各容器进行调度，以协调该多个容器共同起作用、从而实现该复杂应用程序的完整功能。

资源管理模块102与多个计算节点103相耦合，其为每个计算节点分配管理所占用的***资源。

图1还示出了计算节点103的放大视图，其中计算节点103包括多个容器封装单元1031、1032、1033；而每个容器封装单元又包括一个或多个容器。

根据该第一实施例，同一个容器封装单元中的各容器共享第一、第二及第三信息字段，其中，第一信息字段使得同一个容器封装单元中的各容器具有相同或相应的标识号；第二信息字段使得同一个容器封装单元中的各容器能够实现进程间通信；以及，第三信息字段使得同一个容器封装单元中的各容器能够实现网络一致服务。

作为上述第一实施例的一种优选实施方式，容器封装单元利用Linux***下的Cgroup机制实现对该容器封装单元下的各容器所占用的***资源进行管理和/或隔离。

进一步地，基于Cgroup机制，第一信息字段为Pid namespace，所述第二信息字段为Ipc namespace，所述第三信息字段为Uts namespace。同一个容器封装单元中的各容器还可以通过共享volume信息字段实现相互之间的数据交互。

基于Cgroup机制，具体地，针对同一容器封装单元中的各容器，通过在linux内核文件/proc/[pid]/ns中修改namespace的软连接，能够使得该多个容器指向同一个ID号或能够互相识别的ID号（即，使各容器具有相同或相应的标识号）；每个容器内部仅设置一个进程，它们可以通过ipc实现进程间通讯（即，各容器能够实现进程间通信），而由于容器封装单元包括多个容器，在容器封装单元内部实际上实现了多个进程；通过networknamespace共享能够实现各容器的网络一致服务，例如通过localhost访问本地服务，也对外呈现同一IP地址，使得使用负载均衡措施时，为这些容器配置一个IP即可。

此外，同一容器封装单元中的各容器可以通过共享volume信息字段而实现相互之间的数据交互，通过volume信息字段各容器能够共享，例如，一个文件或一个目录。

虽然各容器之间共享多个信息字段，然而，由于cgroup机制仍然是针对每一个容器，因此各个容器所占用的***资源是相互隔离的，不会出现资源竞争或者相互影响。

可以理解，在同一个容器封装单元中的各容器具有相同或相应的标识号、能够实现进程间通信、以及能够实现网络一致服务的情况下，所有的调度和扩展（例如，由容器调度模块101进行）都基于该容器封装单元来进行，这还便于保证容器封装单元内部的各容器的启停顺序，从而使得在一个容器封装单元内部即可部署相对复杂的应用程序或应用程序片段。进一步地，利用容器调度模块101对多个不同计算节点下的各容器封装单元内的各容器进行调度（计算节点—容器封装单元—容器，共三级调度），则能够进一步地将极为复杂的应用程序打包/封装于上述容器管理调度***内，而仍能实现该应用程序的完整功能。由此，可以将复杂的金融服务应用程序打包封装于上述容器管理调度***内。

图2示出本发明第二实施例提供的容器管理调度***，其包括容器调度模块101、资源管理模块102、多个节点103以及分布式协调管理模块104。其中，容器调度模块101、资源管理模块102、多个节点103之间的逻辑关系与上述第一实施例中相同。

其中，计算节点分别包括至少一个容器封装单元，各容器封装单元分别包括多个容器，同一个容器封装单元中的各容器具有相同或相应的标识号、能够实现进程间通信、以及能够实现网络一致服务。从而能够将较为复杂的应用程序打包封装于容器管理调度***内，并仍能实现其各项功能。

与上述第一实施例不同的是，分布式协调管理模块104为资源管理模块102提供分布式协调管理服务，以保证资源管理模块102的高可用性。

具体地，可以为资源管理模块102设置一个或多个备用服务器（这种方式在图2中示出），或者，将资源管理模块102按分布式***来设置，使其功能分布到多个彼此平等的多台服务器上来实现，这多台服务器可以互为备份（这种方式未在图2中示出）。随之，利用分布式协调管理模块104来协调管理资源管理模块102及其备份服务器（或采用分布式***的彼此平等的多台服务器），使得多个管理节点中任意一个出错或宕机都不影响整个***的运行，并且在选举机制不会出现脑裂的问题。

根据一种优选的实施方式，分布式协调管理模块104可以基于Linux***下的iptables、Haproxy以及keepalived机制来实现。

另外，分布式协调管理模块104还能够负责实现采用分布式***的彼此平等的多台服务器之间的负载平衡。

具体地，分布式协调管理模块104在各计算节点上设有一个进程uprm-proxy，该进程会在宿主机上创建两个Haproxy容器，通过keepalived实现高可用。将它们的cpu、内存、网络IO等***资源均设定在一个阀值内，且这两个容器的虚IP（由keepalived创建）为一个保留IP。容器通过veth设备对和桥接的方式接入宿主机网络。Haproxy会将一个端口与某个服务关联起来，所有发往该端口的流量会被负载均衡到一组upod中去。同时，uprm-proxy通过iptables将多个upod发布的服务IP和端口，重定向到本机haproxy的IP和haproxy设置的随机端口。在这过程中，服务IP和端口是不会改变的，uprm-proxy会根据存储在etcd中的信息，保证通过访问服务IP和端口能最终访问到后端的upod应用。实现负载均衡后，本地Haproxy通过keepalived实现高可用，当宿主机宕机时，也不影响别的宿主机上的应用通过自己的Haproxy来访问后端的相应容器封装单元。

图3示出本发明第三实施例提供的容器管理调度***中的一个容器封装单元，在该容器封装单元1031中，除了多个容器311、312、313之外，还包括容器管理子模块314以及服务发现子模块315。

其中，根据该第三实施例的容器管理调度***可以按照上述第一或第二实施例来配置或实现。不同的是，在容器封装单元1031内，容器管理子模块1034可以根据对应的计算节点的命令对该多个容器311、312、313进行配置和/或管理。例如，对各容器的生命周期进行管理，以及负责网络、各种服务的注册，容器管理子模块1034还可以对容器封装单元1031中的其他附加单元或子模块，例如服务发现子模块315，进行配置。

服务发现子模块315可以使相同的一组容器暴露出唯一的访问入口，并且告知各个容器如何访问某个服务，以便实现复杂应用程序的各项功能。例如，这些服务可以为Linux框架下已有的服务。

本发明各实施例提供的容器管理调度***，可以通过容器封装单元而将复杂的金融服务应用程序打包封装于多个容器中，这不仅克服了现有技术中VM（虚拟机）技术的缺陷，也为开发人员带来了便利，提高了复杂应用程序的开发效率、节省了开发及部署成本。此外，上述容器管理调度***，通过保证资源管理模块的高可用性、实现管理资源管理模块的负载平衡，而具备良好的***稳定性及可靠性。

通过在容器封装单元内设置各种附加单元或子模块，可以实现对容器封装单元内各容器更细致的配置与管理，进一步地将这些容器充分结合在一起、协同工作，来实现应用程序或应用程序片段的功能性。

上述说明仅针对于本发明的优选实施例，并不在于限制本发明的保护范围。本领域技术人员可作出各种变形设计，而不脱离本发明的思想及附随的权利要求。

Claims (9)

1.一种容器管理调度***，用于对应用程序进行封装，所述***包括：

至少一个计算节点，各所述计算节点分别包括至少一个容器封装单元，所述容器封装单元包括多个容器；

资源管理模块，与所述至少一个计算节点中的每个分别耦合，用于分配管理用于每个所述计算节点的***资源；

容器调度模块，与所述资源管理模块相耦合，用于对各所述容器进行调度；

其中，同一个所述容器封装单元中的各所述容器共享第一、第二及第三信息字段，所述第一、第二及第三信息字段分别使得同一个所述容器封装单元中的各所述容器：

具有相同或相应的标识号；

实现进程间通信；以及

实现网络一致服务。

2.根据权利要求1所述的***，其特征在于，所述***还包括分布式协调管理模块，用于为所述资源管理模块提供分布式协调管理服务以保证所述资源管理模块的高可用性。

3.根据权利要求2所述的***，其特征在于，分布式协调管理模块基于Linux***下的iptables、Haproxy以及keepalived机制来实现。

4.根据权利要求1所述的***，其特征在于，所述容器封装单元还包括容器管理子模块，所述容器管理子模块用于根据对应的所述计算节点的命令对所述多个容器进行配置和/或管理。

5.根据权利要求4所述的***，其特征在于，所述容器封装单元还包括服务发现子模块，所述服务发现子模块用于指示对应的所述多个容器如何访问各种服务。

6.根据权利要求1所述的***，其特征在于，所述容器封装单元利用Linux***下的Cgroup机制实现对该容器封装单元下的各所述容器所占用的***资源进行管理和/或隔离。

7.根据权利要求6所述的***，其特征在于，所述第一信息字段为Pid namespace，所述第二信息字段为Ipc namespace，所述第三信息字段为Uts namespace。

8.根据权利要求6所述的***，其特征在于，同一个所述容器封装单元中的各所述容器还通过共享volume信息字段实现数据交互。

9.根据权利要求1至8中任一项所述的***，其特征在于，所述应用程序为金融服务应用程序。