CN108039975A - 容器集群管理系统及其应用方法 - Google Patents

Abstract

本申请提供一种容器集群管理系统及其应用方法，通过将Nginx的转发规则和配置项存储于预先建立的ConfigMap资源对象中，并由ConfigMap Controller对该ConfigMap进行监控，在ConfigMap资源对象发生变化时，Controller根据ConfigMap中存储的信息生成Nginx的配置文件，之后验证并加载Nginx配置文件，确保配置生效，进而对外暴露服务。结合Nginx所提供的功能在实现对外暴露服务时，兼顾七层和四层的负载均衡目的，且不需要额外引入资源对象和复杂的数据结构，降低容器集群管理系统在实现对外暴露服务时的复杂度。

Description

容器集群管理系统及其应用方法

技术领域

本发明涉及云计算技术领域，具体涉及一种容器集群管理系统及其应用方法。

背景技术

继虚拟化技术出现后，容器技术逐渐成为对云计算技术领域具有深远影响的变革技术。而将应用程序容器化也成为大势所趋。Kubernetes是一种容器集群管理系统，提供应用部署、维护、扩展机制等功能。目前，利用Kubernetes系统管理跨集群运行的容器化应用。同时，Kubernetes系统还提供了形式多样的对象资源，并赋予各个资源对象不同的用途。例如，Secret类型的资源用于保存密码等敏感信息；ConfigMap类型的资源用于保存应用程序的配置信息；Ingress类型的资源用于保存一系列的路由规则信息等。

其中，Ingress是一个规则的集合，它允许集群外的流量通过一定的规则到达集群内的Service，是Kubernetes系统中一种对外暴露服务的方式。目前，在Kubernetes系统中对外暴露服务的方法是使用Ingress的结构来存储转发规则。同时，使用IngressController从该Ingress上读取转发规则信息，生成有关Nginx或者Haproxy的配置文件，从而实现整体的服务发现和负载均衡。

但是，采用上述方式实现对外暴露服务受限于Ingress的结构，仅仅能设置七层的负载均衡的转发规则，针对四层的负载均衡时，需要引入额外的资源对象和复杂的数据结构。

发明内容

有鉴于此，本发明实施例提供一种容器集群管理系统及其应用方法，以解决如何在不引入额外的资源对象和复杂的数据结构的情况下，Kubernetes系统实现对外暴露服务时，兼顾七层和四层的负载均衡的目的。

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

一种容器集群管理系统的应用方法，该方法包括：

通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化，所述ConfigMap资源对象用于存储信息，所述信息包括反向代理负载均衡器Nginx的转发规则和配置项；

当ConfigMap资源对象发生变化时，所述ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件；

验证所述Nginx配置文件，并在验证通过后加载所述Nginx配置文件进行对外暴露服务。

可选的，所述预先建立ConfigMap资源对象的过程，包括：

创建ConfigMap资源对象，所述ConfigMap资源对象用于存储Nginx的转发规则和配置项；

基于确定的待对外暴露服务的部署实例，确定Nginx的转发规则对应的后端部署实例及其对应的配置项；

将所述Nginx的转发规则和配置项按照预设的数据结构分别存储于所述ConfigMap资源对象的不同Key中。

可选的，在通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化之前，还包括：

基于Nginx镜像作为基础镜像，将ConfigMap Controller的二进制程序作为dockerfile文件中entrypoint属性的值，构建ConfigMap Controller镜像；

在Host的网络模式下，利用DaemonSet模式启动ConfigMap Controller容器实例。

可选的，所述ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件，包括：

所述ConfigMap Controller读取所述Nginx的转发规则和配置项，以及所述Nginx的转发规则对应的后端部署实例信息，所述后端部署实例信息包括后端部署实例的IP和端口信息；

将读取的所述Nginx的转发规则、所述配置项和所述后端部署实例信息与内存中存储的配置信息进行对比；

若不存在相同的信息，则利用述Nginx的转发规则、所述配置项和所述后端部署实例信息生成所述Nginx配置文件。

可选的，还包括：

若所述转发规则对应的后端部署实例信息为多个后端部署实例的信息，则确定所述多个后端部署实例的权重百分比；

根据所述多个后端部署实例的权重百分比构造split_clients结构体；

基于所述split_clients结构体在所述Nginx配置文件中生成split_clients的相关配置项。

可选的，还包括：

基于软连接的方式，将Nginx的访问日志定向至Nginx容器的标准输出端，将Nginx的错误日志定向至所述Nginx容器的标准错误输出端；

利用Docker的日志收集器对所述Nginx的访问日志和所述Nginx的错误日志进行收集处理；

或者，在Nginx的日志目录被挂载的情况下，在所述Nginx容器中启动一定时任务，利用logrotate执行所述Nginx的访问日志和所述Nginx的错误日志的滚动，以及对过期的所述Nginx的访问日志和所述Nginx的错误日志进行删除。

一种容器集群管理系统，包括：

监控单元，用于通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化，所述ConfigMap资源对象用于存储信息，所述信息包括反向代理负载均衡器Nginx的转发规则和配置项；

执行单元，用于当所述ConfigMap资源对象发生变化时，所述ConfigMapController根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件，并在验证所述Nginx配置文件通过后加载所述Nginx配置文件，进行对外暴露服务。

可选的，还包括预建单元；

所述预建单元，用于创建ConfigMap资源对象，所述ConfigMap资源对象用于存储Nginx的转发规则和配置项；基于确定的待执行对外暴露服务的部署实例，确定Nginx的转发规则对应的后端部署实例及其对应的配置项；将所述Nginx的转发规则和配置项按照预设的数据结构分别存储于所述ConfigMap资源对象的不同Key中。

可选的，还包括：

测试单元，用于若所述转发规则对应的后端部署实例信息为多个后端部署实例的信息，则确定所述多个后端部署实例的权重百分比；根据所述多个后端部署实例的权重百分比构造split_clients结构体；基于所述split_clients结构体在所述Nginx配置文件中生成split_clients的相关配置项。

可选的，还包括：

日志处理单元，用于基于软连接的方式，将Nginx的访问日志定向至Nginx容器的标准输出端，将Nginx的错误日志定向至所述Nginx容器的标准错误输出端；利用Docker的日志收集器对所述Nginx的访问日志和所述Nginx的错误日志进行收集处理；或者，在Nginx的日志目录被挂载的情况下，在所述Nginx容器中启动一定时任务，利用logrotate执行所述Nginx的访问日志和所述Nginx的错误日志的滚动，以及对过期的所述Nginx的访问日志和所述Nginx的错误日志进行删除。

基于上述技术方案，本申请实施例提供的容器集群管理系统及其应用方法，通过将Nginx的转发规则和配置项存储于预先建立的ConfigMap资源对象中，并由ConfigMapController对该ConfigMap进行监控，在ConfigMap资源对象发生变化时，Controller根据ConfigMap中存储的信息生成Nginx的配置文件，之后验证并加载Nginx配置文件，确保配置生效，进而对外暴露服务。结合Nginx所提供的功能在实现对外暴露服务时，兼顾七层和四层的负载均衡目的，且不需要额外引入资源对象和复杂的数据结构，降低容器集群管理系统在实现对外暴露服务时的复杂度。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的一种容器集群管理系统的应用方法流程示意图；

图2为本申请实施例公开的另一种容器集群管理系统的应用方法流程示意图；

图3为本申请实施例公开的一种容器集群管理系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本申请中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

由背景技术可知，Kubernetes是一种容器集群管理系统，提供应用部署、维护、扩展机制等功能。目前，利用Kubernetes系统管理跨集群运行的容器化应用。但是在应用Kubernetes系统实现对外暴露服务时受限于Ingress的结构，仅仅能设置七层的负载均衡的转发规则，针对四层的负载均衡时，需要引入额外的资源对象和复杂的数据结构。

因此，本申请实施例公开了一种容器集群管理系统及其应用方法，利用ConfigMap资源对象存储相关内容，并结合Nginx所提供的功能，在实现对外暴露服务时，不仅可以实现A/B测试功能，兼顾七层和四层的负载均衡，而且不需要额外引入资源对象和复杂的数据结构，降低容器集群管理系统在实现对外暴露服务时的复杂度。

这里的七层和四层指的是通过七个/四个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯，用于使不同类型的主机实现数据传输。

七层包括：应用层，表示层，会话层，传输层，网络层，数据链路层和物理层。

四层包括：应用层，传输层，网络层和网络接口层。

Ingress是一个规则的集合，它允许集群外的流量通过一定的规则到达集群内的Service。

Service是对一组提供相同功能的Pod的抽象，并为它们提供一个统一的入口。利用Service可以方便的实现服务发现与负载均衡。Service通过标签来选取服务后端，即后端部署实例。并通过配合Replication Controller或者Deployment确保后端容器的正常运行。

Pod是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。例如，一个web站点应用由前端、后端及数据库构建而成。可以创建包含三个container的pod，使这三个组件运行在各自的容器中。

Replication Controller是pod的复制抽象。

Nginx是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。也可以称为反向代理负载均衡器。其可以作为一个Service部署在Kubernetes集群中。

如图1所示，为本申请实施例公开的一种容器集群管理系统的应用方法的流程示意图。以Kubernetes为例，该应用方法包括：

S101：通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化，若该ConfigMap资源对象未发生变化则执行S102，若该ConfigMap资源对象发生变化则执行S103。

在具体实现中，Kubernetes在通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化之前，需要先启动ConfigMap Controller。

具体启动ConfigMap Controller的过程为：

首先，基于Nginx镜像作为基础镜像，将ConfigMap Controller的二进制程序作为dockerfile文件中entrypoint属性的值，构建ConfigMap Controller镜像。其中，dockerfile文件是构建制作镜像的配置文件。entrypoint属性的值一般是一个二进制程序或者脚本命令。

可选的，Nginx镜像为官方镜像。

然后，在Host的网络模式下，利用DaemonSet启动ConfigMap Controller容器实例。

可选的，将上述创建ConfigMap资源对象的命名空间和名称以参数形式传递给ConfigMap Controller程序，使ConfigMap Controller程序使用默认或初始的配置参数启动Nginx。并通过线程在后台启动定时任务，实现调用logrotate处理Nginx的日志。

在具体实现中，Kubernetes利用Kubernetes中的ConfigMap资源对象存储Nginx的转发规则和配置项。

将上述信息存储于ConfigMap资源对象中的过程为：

首先，Kubernetes在任一命名空间下创建ConfigMap资源对象，使其用来存储Nginx的转发规则、配置项以及该转发规则对应的后端部署实例信息。

然后，基于确定的待执行对外暴露服务的部署实例，确定Nginx的转发规则对应的后端部署实例及其对应的配置项。该后端部署实例包括后端部署实例的IP和端口信息等。具体的，确定待执行对外暴露服务的部署实例之后，为该部署实例创建对内服务的Service。

最后，将Nginx的转发规则和配置项按照预设的数据结构分别存储于ConfigMap资源对象的不同Key中。

可选的，将Nginx的转发规则和配置项按照预设的数据结构以json格式分别存储于ConfigMap资源对象的不同Key中。

可选的，Nginx的转发规则包括：http转发规则和tcp转发规则。

S102：若该ConfigMap资源对象未发生变化，则加载已有的Nginx配置文件执行对外暴露服务。

在具体实现中，若ConfigMap资源对象未发生变化则加载已有的Nginx配置文件执行对外暴露服务。

S103：若ConfigMap资源对象发生变化，则ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件。

在具体实现中，ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件的过程为：

首先，ConfigMap Controller读取所述Nginx的转发规则和配置项，以及所述Nginx的转发规则对应的后端部署实例信息，所述后端部署实例信息包括后端部署实例的IP和端口信息。

然后，将读取的Nginx的转发规则、配置项和后端部署实例信息与内存中存储的配置信息进行对比。

在具体实现中，内存中可能存储有之前保留的配置信息，也可能未保留过配置信息，若存在则进行比对，若不存在相同的信息，则利用Nginx的转发规则、配置项和后端部署实例信息生成Nginx配置文件。

在本申请实施例中，基于Nginx的转发规则对应的后端部署实例，以及存储于ConfigMap资源对象的不同Key中的Nginx的转发规则和配置项生成待执行对外暴露服务的部署实例的Nginx配置文件。

由于Nginx的配置项多为key-value的形式。因此，为了方便后续的扩展且不修改现有的数据结构和代码逻辑，本申请实施例在配置项、域名路径等数据结构中分别引入一个key-valve的map结构。并利用一个ConfigMapController程序来读取ConfigMap中存储的Nginx的转发规则和配置项等信息，并根据这些信息生成Nginx的配置文件。

S104：验证所述Nginx配置文件，并在验证通过后加载所述Nginx配置文件进行对外暴露服务。

在具体实现中，加载Nginx配置文件具体为：ConfigMap Controller程序通过调用Nginx的内置命令测试校验生成的Nginx配置文件是否符合Nginx的规范，如果符合规范，则加载当前生成的配置文件，否则，继续使用前一次执行对外暴露服务所使用的配置文件。

本申请上述实施例所公开的容器集群管理系统的应用方法，通过将Nginx的转发规则和配置项存储于预先建立的ConfigMap资源对象中，在ConfigMap资源对象未发生变化，则加载Nginx配置文件执行对外暴露服务。结合Nginx所提供的功能在实现对外暴露服务时，可以兼顾七层和四层的负载均衡目的。且不需要额外引入资源对象和复杂的数据结构，降低容器集群管理系统在实现对外暴露服务时的复杂度。

进一步的，在执行上述容器集群管理系统的应用方法的过程中，若转发规则对应的后端部署实例信息为多个后端部署实例的信息。具体情况为：对于http的转发规则，如果其转发路径对应多个后端部署实例，则路径规则要进行A/B测试功能；对于tcp转发规则，如果其监听端口对应多个后端部署实例，也需要进行A/B测试功能。

在具体实现中，进行A/B测试功能的过程如图2所示，包括：

S201：确定多个后端部署实例的权重百分比。

S202：根据多个后端部署实例的权重百分比构造split_clients结构体，该split_clients是Nginx中ngx-http-split-clients模块引入的结构体。。

S203：基于split_clients结构体在Nginx配置文件中生成split_clients的相关配置项。

本申请实施例通过执行上述图2示出的方法，利用生成split_clients的相关配置项可以实现A/B测试功能。

进一步的，在执行上述容器集群管理系统的应用方法的过程中，可以改善对Nginx的日志处理。所进行Nginx的日志处理的过程包括以下情况：

本申请实施例，在通常情况下，基于软连接的方式，将Nginx的访问日志定向至Nginx容器的标准输出端，将Nginx的错误日志定向至Nginx容器的标准错误输出端。然后，利用Docker的日志收集器对Nginx的访问日志和Nginx的错误日志进行收集处理。

本申请实施例，在配置项中定义了Syslog Server的地址的情况下，同样利用Docker的日志收集器对Nginx的访问日志和Nginx的错误日志进行收集处理。

本申请实施例，在Nginx的日志目录被挂载的情况下，在Nginx容器中启动一定时任务，利用logrotate执行Nginx的访问日志和Nginx的错误日志的滚动，以及对过期的Nginx的访问日志和Nginx的错误日志进行删除。

在本申请实施例中基于上述容器集群管理系统中对Nginx的日志进行处理。能够避免当Nginx访问量过大时，Nginx容器的磁盘空间被快速填满，进而影响到Nginx容器的正常运行的情况。另外，通过采用上述方式对Nginx的日志进行分析，能够获取有利于用户定位的统计信息，提高用户感受。

基于上述本申请实施例公开的容器集群管理系统的应用方法，本申请实施例还对应公开了一种容器集群管理系统。如图3所示，该容器集群管理系统300包括：监控单元301和执行单元302。

监控单元301，用于通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化，该ConfigMap资源对象用于存储信息，所述信息Nginx的转发规则和配置项。

执行单元302，用于当ConfigMap资源对象发生变化时，所述ConfigMapController根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件，并在验证所述Nginx配置文件通过后加载所述Nginx配置文件，进行对外暴露服务。

在具体实现中，该执行单元302还用于若ConfigMap资源对象未发生变化，则加载已有的Nginx配置文件执行对外暴露服务。

该执行单元302具体根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件的过程为：读取Nginx的转发规则和配置项，以及Nginx的转发规则对应的后端部署实例信息，该后端部署实例信息包括后端部署实例的IP和端口信息；将读取的Nginx的转发规则、配置项和后端部署实例信息与内存中存储的配置信息进行对比；若不存在相同的信息，则利用Nginx的转发规则、配置项和后端部署实例信息生成Nginx配置文件。

在具体实现中，该执行单元302还用于在监控单元301执行监控之前，启动ConfigMap Controller，具体过程为：基于Nginx镜像作为基础镜像，将ConfigMapController的二进制程序作为dockerfile文件中entrypoint属性的值，构建ConfigMapController镜像；在Host的网络模式下，利用DaemonSet模式启动ConfigMap Controller容器实例。

进一步，该容器集群管理系统300还包括预建单元303。

预建单元303，用于创建ConfigMap资源对象，该ConfigMap资源对象用于存储Nginx的转发规则和配置项，基于确定的待执行对外暴露服务的部署实例，确定Nginx的转发规则对应的后端部署实例及其对应的配置项；将Nginx的转发规则和配置项按照预设的数据结构分别存储于ConfigMap资源对象的不同Key中；基于Nginx的转发规则、配置项和Nginx的转发规则对应的后端部署实例生成待执行对外暴露服务的部署实例的Nginx配置文件。

进一步，该容器集群管理系统300还包括测试单元304。

测试单元304，用于若转发规则对应的后端部署实例信息为多个后端部署实例的信息，则确定多个后端部署实例的权重百分比；根据多个后端部署实例的权重百分比构造split_clients结构体；基于split_clients结构体在Nginx配置文件中生成split_clients的相关配置项。

具体的该测试单元304用于实现A/B测试功能。

进一步，该容器集群管理系统300还包括日志处理单元305。

日志处理单元305，用于基于软连接的方式，将Nginx的访问日志定向至Nginx容器的标准输出端，将Nginx的错误日志定向至Nginx容器的标准错误输出端；利用Docker的日志收集器对Nginx的访问日志和Nginx的错误日志进行收集处理；或者，在Nginx的日志目录被挂载的情况下，在Nginx容器中启动一定时任务，利用logrotate执行Nginx的访问日志和Nginx的错误日志的滚动，以及对过期的Nginx的访问日志和Nginx的错误日志进行删除。

为了描述的方便，描述以上系统时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

上述各个单元的具体实现方式可以参见上述本申请实施例公开的容器集群管理系统的应用方法，这里不再进行赘述。

综上所述，本申请实施例提供的上述容器集群管理系统及其应用方法，通过将Nginx的转发规则和配置项存储于预先建立的ConfigMap资源对象中，在ConfigMap资源对象未发生变化，则加载Nginx配置文件执行对外暴露服务。结合Nginx所提供的功能在实现对外暴露服务时，不仅可以实现A/B测试功能，兼顾七层和四层的负载均衡，而且不需要额外引入资源对象和复杂的数据结构，降低容器集群管理系统在实现对外暴露服务时的复杂度。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种容器集群管理系统的应用方法，其特征在于，所述方法包括：

通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化，所述ConfigMap资源对象用于存储信息，所述信息包括反向代理负载均衡器Nginx的转发规则和配置项；

当ConfigMap资源对象发生变化时，所述ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件；

验证所述Nginx配置文件，并在验证通过后加载所述Nginx配置文件进行对外暴露服务。

2.根据权利要求1所述的方法，其特征在于，所述预先建立ConfigMap资源对象的过程，包括：

创建ConfigMap资源对象，所述ConfigMap资源对象用于存储Nginx的转发规则和配置项；

基于确定的待对外暴露服务的部署实例，确定Nginx的转发规则对应的后端部署实例及其对应的配置项；

将所述Nginx的转发规则和配置项按照预设的数据结构分别存储于所述ConfigMap资源对象的不同Key中。

3.根据权利要求2所述的方法，其特征在于，在通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化之前，还包括：

基于Nginx镜像作为基础镜像，将ConfigMap Controller的二进制程序作为dockerfile文件中entrypoint属性的值，构建ConfigMap Controller镜像；

在Host的网络模式下，利用DaemonSet模式启动ConfigMap Controller容器实例。

4.根据权利要求1所述的方法，其特征在于，所述ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件，包括：

所述ConfigMap Controller读取所述Nginx的转发规则和配置项，以及所述Nginx的转发规则对应的后端部署实例信息，所述后端部署实例信息包括后端部署实例的IP和端口信息；

将读取的所述Nginx的转发规则、所述配置项和所述后端部署实例信息与内存中存储的配置信息进行对比；

若不存在相同的信息，则利用述Nginx的转发规则、所述配置项和所述后端部署实例信息生成所述Nginx配置文件。

5.根据权利要求1-4中任一项所述的方法，其特征在于，还包括：

若所述转发规则对应的后端部署实例信息为多个后端部署实例的信息，则确定所述多个后端部署实例的权重百分比；

根据所述多个后端部署实例的权重百分比构造split_clients结构体；

基于所述split_clients结构体在所述Nginx配置文件中生成split_clients的相关配置项。

6.根据权利要求1-4中任一项所述的方法，其特征在于，还包括：

基于软连接的方式，将Nginx的访问日志定向至Nginx容器的标准输出端，将Nginx的错误日志定向至所述Nginx容器的标准错误输出端；

利用Docker的日志收集器对所述Nginx的访问日志和所述Nginx的错误日志进行收集处理；

或者，在Nginx的日志目录被挂载的情况下，在所述Nginx容器中启动一定时任务，利用logrotate执行所述Nginx的访问日志和所述Nginx的错误日志的滚动，以及对过期的所述Nginx的访问日志和所述Nginx的错误日志进行删除。

7.一种容器集群管理系统，其特征在于，包括：

监控单元，用于通过ConfigMap Controller监控预先建立的ConfigMap资源对象是否发生变化，所述ConfigMap资源对象用于存储信息，所述信息包括反向代理负载均衡器Nginx的转发规则和配置项；

执行单元，用于当所述ConfigMap资源对象发生变化时，所述ConfigMap Controller根据所述ConfigMap资源对象中存储的信息生成Nginx配置文件，并在验证所述Nginx配置文件通过后加载所述Nginx配置文件，进行对外暴露服务。

8.根据权利要求7所述的系统，其特征在于，还包括预建单元；

所述预建单元，用于创建ConfigMap资源对象，所述ConfigMap资源对象用于存储Nginx的转发规则和配置项；基于确定的待执行对外暴露服务的部署实例，确定Nginx的转发规则对应的后端部署实例及其对应的配置项；将所述Nginx的转发规则和配置项按照预设的数据结构分别存储于所述ConfigMap资源对象的不同Key中。

9.根据权利要求7或8所述的系统，其特征在于，还包括：

测试单元，用于若所述转发规则对应的后端部署实例信息为多个后端部署实例的信息，则确定所述多个后端部署实例的权重百分比；根据所述多个后端部署实例的权重百分比构造split_clients结构体；基于所述split_clients结构体在所述Nginx配置文件中生成split_clients的相关配置项。

10.根据权利要求7或8所述的系统，其特征在于，还包括：

日志处理单元，用于基于软连接的方式，将Nginx的访问日志定向至Nginx容器的标准输出端，将Nginx的错误日志定向至所述Nginx容器的标准错误输出端；利用Docker的日志收集器对所述Nginx的访问日志和所述Nginx的错误日志进行收集处理；或者，在Nginx的日志目录被挂载的情况下，在所述Nginx容器中启动一定时任务，利用logrotate执行所述Nginx的访问日志和所述Nginx的错误日志的滚动，以及对过期的所述Nginx的访问日志和所述Nginx的错误日志进行删除。