CN107688322A - 一种容器化管理系统 - Google Patents

Abstract

本发明涉及一种容器化管理系统，包括用于控制现场设备工作状态的PLC工业控制器、容器化管理器、客户终端和服务器终端；客户终端用于对现场设备发送控制指令或者用于现场的监控操作；客户终端将用户对生产线设备的操作，通过调用基于容器化的服务终端所提供的基于tcp协议的rpc远程服务调用框架服务终端接口和tcp socket接口完成服务的调用；客户终端访问容器化管理器中的网关时，通过管理器本身的负载均衡策略，决定访问相应的服节点的后端服务；服务器终端接收到客户终端的调用的指令，通过基于opcua和modbus tcp协议的通信接口，直接对PLC工业控制器进行数据的读写操作，从而实现对工业设备的控制。

Description

一种容器化管理系统

技术领域

本发明属于工业自动化控制技术领域，特别是涉及一种容器化管理系统。

背景技术

目前，随着社会的快速发展，PLC工业控制器已经广泛应用于制造业，但是随着现场设备的不断增多，现场设备的管理问题日益突出，因此为了合理有效的控制现场设备，设计开发一种高效、安全的容器化管理系统显得是尤为重要。

发明内容

本发明为解决公知技术中存在的技术问题而提供一种容器化管理系统，该容器化管理系统以容器化管理器技术为基础，针对服务器容器化部署，减少部署的时间，减少硬件的数量。

本发明为解决公知技术中存在的技术问题所采取的技术方案是：

一种容器化管理系统，包括用于控制现场设备工作状态的PLC工业控制器、容器化管理器、客户终端和服务器终端；其中：

所述客户终端用于对现场设备发送控制指令或者用于现场的监控操作；

所述客户终端将用户的操作通过基于容器化的服务终端，提供基于tcp协议的rpc远程服务调用框架服务终端接口和tcp socket接口来完成调用；

所述客户终端访问容器化管理器的网关，通过管理器本身的负载均衡策略，决定访问相应的服节点的后端服务，保证整体服务端的稳定，并通过监控整体访问流量，动态增加或者扩展服务节点；

所述服务器终端接收到客户终端的调用的指令，通过基于opcua和modbus tcp协议的通信接口，直接对PLC工业控制器进行数据的读写操作，从而实现对工业设备的控制。

本发明还可以采用如下技术方案：

进一步：所述容器化管理器包括分布式存储模块、多个服务节点模块和控制节点模块；所述分布式存储模块用于保存集群状态，所述控制节点模块用于运行集群的管理控制，每个服务节点模块用于运行容器的主机节点。

更进一步：每个Minion节点上运行一个Zgbelet代理，用于控制节点上的容器、镜像和存储卷。

更进一步：所述负载均衡策略包括轮循均衡、权重轮循均衡、随机均衡、权重随机均衡、响应速度均衡、最少连接数均衡和处理能力均衡。

更进一步：所述控制节点模块包括：

ZGAPI Server，所述ZGAPI Server提供了资源对象的唯一操作入口，其他所有的组件都必须通过ZGAPI Server提供的API来操作资源对象；ZGAPI Server以RESTful风格的API对外提供接口；所有服务节点的资源对象的生命周期维护都是通过调用API Server的接口来完成；

Controller Manager，Controller Manager用于集群内部的管理控制中心，用于实现容器化管理器的故障检测和自动恢复等工作；Controller Manager包含NodeController和Replication Controller两个核心组件；其中Node Controller负责计算节点的加入和退出，通过Node Controller实现计算节点的扩容和缩容；ReplicationController用于资源对象RC的管理、应用的扩容、缩容以及滚动升级；

Scheduler，Scheduler用于集群中的调度器，负责容器化应用在集群的中的调度和分配；

Zgbelet，Zgbelet用于负责本Node节点上的Pod的创建、修改、监控、删除Pod的全生命周期管理，Zgbelet实时向ZGAPI Server发送所在计算节点Node的信息；

Zgbelet-Proxy，Zgbelet-Proxy用于实现Service的抽象，为一组Pod抽象的服务Service提供统一接口并提供负载均衡功能。

本发明具有的优点和积极效果是：

1.服务终端应用的容器化的部署和复制

本专利的服务终端部署在自主研发的容器化管理器中，基于此容器化管理器，可以针对服务终端容器化部署，减少部署成本和部署时间，较少硬件的开销。

2.随时扩展或收缩容器规模

容器化管理器，可根据所部署的在其上的应用服务所被访问的流量，动态扩展和减少应用服务的副本的节点，并适时监控每个健康程度，以及所在虚拟机的硬件的参数指标，实现整个产品的分布式和集群化的快速部署，底层采用自主研发的分布式文件系统，保证了产品的底层的数据安全性，通过虚拟挂载卷的形式，动态对分布式文件系统进行动态的扩容。

3.管理器实现负载均衡，多节点服务支撑，保证高可用性。

管理器通过对检测整个对访问应用的服务流量的检测，支持了了基于多种策略的负载均衡算法，实现对集群化应用服务的负载均衡。以下为所支持的负载策略。

轮循均衡(Round Robin)：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

权重轮循均衡(Weighted Round Robin)：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

随机均衡(Random)：把来自网络的请求随机分配给管理器中的多个服务节点。

权重随机均衡(Weighted Random)：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

响应速度均衡(Response Time)：负载均衡设备对内部各服务器发出一个探测请求(例如Ping)，然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户终端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户终端与服务器间的最快响应时间。

最少连接数均衡(Least Connection)：客户终端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。

处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成)最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层(应用层)负载均衡的情况下。

通过访问流量和对节点的健康监测，可对针对高访问量的应用服务进行动态的服务节点的扩展，增强服务的可用性。

4.很容易地升级应用程序容器的新版本

管理器通过初始化部署项目的配置信息，实时的检测本公司所自己搭建版本镜像库中指定产品的镜像，当私有镜像库中发布了最新版本产品，管理平台会自动拉去私有库中的镜像文件，将系统中的服务终端以及副本逐一地热更新，不影响整体产品的服务。

5.自主研发的针对opcua协议的opc-service服务

Opc-service是使用Opc Ua协议传输设备的接入服务。opc-service服务作为整个产品的数据采集以及推送服务，对PLC进行订阅，若寄存器中的数据发生变化，Opc-service可发布订阅信息至后台服务终端。

附图说明

图1是本发明优选实施例的结构框图；

具体实施方式

为能进一步了解本发明的发明内容、特点及功效，兹例举以下实施例，并配合附图详细说明如下：

请参阅图1，包括用于控制现场设备工作状态的PLC工业控制器、容器化管理器、客户终端和服务器终端；其中：

所述客户终端用于对现场设备发送控制指令或者用于现场的监控操作；

所述客户终端将用户的操作通过基于容器化的服务终端，提供基于tcp协议的rpc远程服务调用框架服务终端接口和tcp socket接口来完成调用；

所述客户终端访问容器化管理器的网关，通过管理器本身的负载均衡策略，决定访问相应的服节点的后端服务，保证整体服务端的稳定，并通过监控整体访问流量，动态增加或者扩展服务节点；

所述服务器终端接收到客户终端的调用的指令，通过基于opcua和modbus tcp协议的通信接口，直接对PLC工业控制器进行数据的读写操作，从而实现对工业设备的控制。

在上述优选实施例的基础上：

进一步：所述容器化管理器包括分布式存储模块、多个服务节点模块和控制节点模块；所述分布式存储模块用于保存集群状态，所述控制节点模块用于运行集群的管理控制，每个服务节点模块用于运行容器的主机节点。

更进一步：每个Minion节点上运行一个Zgbelet代理，用于控制节点上的容器、镜像和存储卷。

更进一步：所述负载均衡策略包括轮循均衡、权重轮循均衡、随机均衡、权重随机均衡、响应速度均衡、最少连接数均衡和处理能力均衡。

更进一步：所述控制节点模块包括：

ZGAPI Server，所述ZGAPI Server提供了资源对象的唯一操作入口，其他所有的组件都必须通过ZGAPI Server提供的API来操作资源对象；ZGAPI Server以RESTful风格的API对外提供接口；所有服务节点的资源对象的生命周期维护都是通过调用API Server的接口来完成；

Controller Manager，Controller Manager用于集群内部的管理控制中心，用于实现容器化管理器的故障检测和自动恢复等工作；Controller Manager包含NodeController和Replication Controller两个核心组件；其中Node Controller负责计算节点的加入和退出，通过Node Controller实现计算节点的扩容和缩容；ReplicationController用于资源对象RC的管理、应用的扩容、缩容以及滚动升级；

Scheduler，Scheduler用于集群中的调度器，负责容器化应用在集群的中的调度和分配；

Zgbelet，Zgbelet用于负责本Node节点上的Pod的创建、修改、监控、删除Pod的全生命周期管理，Zgbelet实时向ZGAPI Server发送所在计算节点Node的信息；

Zgbelet-Proxy，Zgbelet-Proxy用于实现Service的抽象，为一组Pod抽象的服务Service提供统一接口并提供负载均衡功能。

1、上述优选实施例的主要构成：

1.1设备控制的客户终端；

1.2设备控制的服务器终端；

1.3PLC工业控制器；

1.4基于虚拟容器化的服务端容器化管理器。

2.上述优选实施例的控制流程：

2.1客户通过客户终端的工业控制的定制界面，对实际的设备发送控制或者监控操作。

2.2客户终端将用户的操作调用用基于容器化的服务端的基于tcp协议的rpc远程服务调用框架服务端接口和tcp socket接口。

2.3客户终端访问容器化管理器的网关，通过管理器本身的负载均衡策略，决定访问相应的服节点的后端服务

2.4服务端接收到客户终端的调用的指令，通过基于opcua和modbus tcp协议的通信接口，直接对工业PLC工业控制器进行数据的读写操作，从而实现对工业设备的控制。

3.原理：

本产品使用了自主开发的容器化的管理平台，此平台为生产环境而设计的容器调度管理系统，对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。随着对容器化和微服务系统架构与设计理念的了解深入，容器化管理系统正是处处为运行云原生应用而设计考虑；提供了多层次的安全防护和隔离机制，多租户应用的支撑能力，应用的全生命周期管理，可扩展的自动资源调度机制，多粒度的资源配额管理能力，多租户支持的统一配置管理组件，多可用区域支撑，实现对集群内部所有部署的应用容器的生命周期进行管理，结合自身的健康检查及错误恢复机制，实现了集群内部应用层的高可用性。

容器化管理平台架构：

由分布式存储、服务节点和控制节点(Master)三大模块构成的。所有的集群状态都保存在分布式存储中，Master节点上则运行集群的管理控制模块。每个服务节点是真正运行应用容器的主机节点，在每个Minion节点上都会运行一个Zgbelet代理，控制该节点上的容器、镜像和存储卷等。

核心组件：

ZGAPI Server:提供了资源对象的唯一操作入口，其他所有的组件都必须通过它提供的API来操作资源对象。它以RESTful风格的API对外提供接口。所有服务节点的资源对象的生命周期维护都是通过调用API Server的接口来完成，例如，用户通过管理节点服务创建一个最小化服务的容器，即是通过调用API Server的接口创建一个Pod对象，并储存在分布式文件系统中集群中。

Controller Manager:集群内部的管理控制中心，主要目的是实现容器化管理平台的故障检测和自动恢复等工作。它包含两个核心组件：Node Controller和ReplicationController。其中Node Controller负责计算节点的加入和退出，可以通过NodeController实现计算节点的扩容和缩容。Replication Controller用于资源对象RC的管理，应用的扩容、缩容以及滚动升级都是有Replication Controller来实现。

Scheduler:集群中的调度器，负责容器化应用在集群的中的调度和分配。

Zgbelet:负责本Node节点上的Pod的创建、修改、监控、删除等Pod的全生命周期管理，Zgbelet实时向ZGAPI Server发送所在计算节点(Node)的信息。

Zgbelet-Proxy:实现Service的抽象，为一组Pod抽象的服务(Service)提供统一接口并提供负载均衡功能。

核心原理:

ZGAPI Server是整个集群的核心，负责集群各个模块之间的通信。集群内部的功能模块通过ZGAPI Server将信息存入分布式文件系统，其他模块通过API Server读取这些信息，从而实现各模块之间的信息交互。比如，Node节点上的Zgbelet每个一个时间周期，通过ZGAPI Server报告自身状态，ZGAPI Server接收这些信息后，将节点状态信息保存到分布式文件系统中。Controller Manager中的Node Controller通过ZGAPI Server定期读取这些节点状态信息，并做相应处理。Scheduler监听到某个Pod创建的信息后，检索所有符合该Pod要求的节点列表，并将Pod绑定到节点中最符合要求的节点上：如果Scheduler监听到某个Pod被删除，则删除本节点上的相应Pod实例。

Controller Manager作为集群的内部管理控制中心，负责集群内的Node，Pod，RC，服务端点(Endpoint)，命名空间(Namespace)，服务账号(ServiceAccount)、资源配额(ResourceQuota)等的管理并执行自动化修复流程，确保集群出处于预期的工作状态，比如，RC实现自动控制Pod活跃副本数，如果Pod出错退出，RC自动创建一个新的Pod，来保持活跃的Pod的个数。

Controller Manager包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、TokenController、Server Controller以及Endpoint Controller等多个控制器，ControllerManager是这些Controller的管理者。我们会在以后的文章中深入介绍这些Controller。

Scheduler负责Pod的调度管理，它负责将要创建的Pod按照一定的规则分配在某个适合的Node上。

Scheduler的默认调度流程分为以下两步：

预选调度过程，即遍历所有目标Node，筛选出符合要求的候选节点。为此，管理器内置了多种预选策略供用户选择。

确定最优节点，在第一步的基础上，采用优选策略为每个候选节点打分，分值最高的胜出。

Scheduler的调度流程是通过插件方式加载“调度算法提供者”具体实现的，一个调度算法提供者其实就是包括了一组预选策略与一组有限选择策略的结构体，

在管理器中，每个计算节点(Node)上会运行一个守护进程：Zgbelet。它用于处理Master节点下发到本节点的任务，管理Pod以及Pod中的容器。每个Zgbelet进程会在APIServer上注册自身节点的信息，定期向API Server汇报节点资源的使用情况，并通过cAdvise监控容器和节点资源。

Zgbelet主要功能：

节点管理：Zgbelet可以自动向API Server注册自己，它可以采集所在计算节点的资源信息和使用情况并提交给API Server，通过启动/停止Zgbelet进程来实现计算节点的扩容、缩容。

Pod管理：Zgbelet通过API Server监听ETCD目录，同步Pod清单，当发现有新的Pod绑定到所在的节点，则按照Pod清单的要求创建改清单。如果发现本地的Pod被删除，则Zgbelet通过docker client删除该容器。

健康检查：Pod通过两类探针来检查容器的健康状态。一个是LivenessProbe探针，用于判断容器是否健康，如果LivenessProbe探针探测到容器不健康，则Zgbelet将删除该容器，并根据容器的重启策略做相应的处理。另一类是ReadnessProbe探针，用于判断容器是否启动完成，且准备接受请求，如果ReadnessProbe探针检测到失败，则Pod的状态被修改。Enpoint Controller将从Service的Endpoint中删除包含该容器的IP地址的Endpoint条目。Zgbelet定期调用LivenessProbe探针来诊断容器的健康状况，它目前支持三种探测：HTTP的方式发送GET请求；TCP方式执行Connect目的端口；Exec的方式，执行一个脚本。

cAdvisor资源监控:在管理器中，应用程序的执行情况可以在不同的级别上检测到，这些级别包含Container，Pod，Service和整个集群。作为管理器的一部分，管理器提供给用户各个级别的资源使用信息，这将使用户能够更加深入地了解应用的执行情况，并找到可能的瓶颈。

4.本专利的创新点为：

1.服务端应用的容器化的部署和复制

本产品的服务端部署在自主研发的容器化管理器中，基于此管理器，可以针对服务端容器化部署，减少部署成本和部署时间，较少硬件的开销。

2.随时扩展或收缩容器规模

容器化管理器，可根据所部署的在其上的应用服务所被访问的流量，动态扩展和减少应用服务的副本的节点，并适时监控每个健康程度，以及所在虚拟机的硬件的参数指标，实现整个产品的分布式和集群化的快速部署，底层采用自主研发的分布式文件系统，保证了产品的底层的数据安全性，通过虚拟挂载卷的形式，动态对分布式文件系统进行动态的扩容。

3.管理器实现负载均衡，多节点服务支撑，保证高可用性。

管理器通过对检测整个对访问应用的服务流量的检测，支持了了基于多种策略的负载均衡算法，实现对集群化应用服务的负载均衡。以下为所支持的负载策略。

轮循均衡(Round Robin)：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

权重轮循均衡(Weighted Round Robin)：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

随机均衡(Random)：把来自网络的请求随机分配给管理器中的多个服务节点。

权重随机均衡(Weighted Random)：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

响应速度均衡(Response Time)：负载均衡设备对内部各服务器发出一个探测请求(例如Ping)，然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户终端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户终端与服务器间的最快响应时间。

最少连接数均衡(Least Connection)：客户终端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。

处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成)最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层(应用层)负载均衡的情况下。

通过访问流量和对节点的健康监测，可对针对高访问量的应用服务进行动态的服务节点的扩展，增强服务的可用性。

4.很容易地升级应用程序容器的新版本

管理器通过初始化部署项目的配置信息，实时的检测本公司所自己搭建版本镜像库中指定产品的镜像，当私有镜像库中发布了最新版本产品，管理平台会自动拉去私有库中的镜像文件，将系统中的服务端以及副本逐一地热更新，不影响整体产品的服务。

5.自主研发的针对opcua协议的opc-service服务

Opc-service是使用Opc Ua协议传输设备的接入服务。opc-service服务作为整个产品的数据采集以及推送服务，对PLC进行订阅，若寄存器中的数据发生变化，Opc-service可发布订阅信息至后台服务端。

以上对本发明的实施例进行了详细说明，但所述内容仅为本发明的较佳实施例，不能被认为用于限定本发明的实施范围。凡依本发明申请范围所作的均等变化与改进等，均应仍归属于本发明的专利涵盖范围之内。

Claims (5)

1.一种容器化管理系统，包括用于控制现场设备工作状态的PLC工业控制器；其特征在于：至少还包括：容器化管理器、客户终端和服务器终端；其中：

所述客户终端用于对现场设备发送控制指令或者用于现场的监控操作；

所述客户终端将用户的操作通过基于容器化的服务终端，提供基于tcp协议的rpc远程服务调用框架服务终端接口和tcp socket接口来完成调用；

所述客户终端访问容器化管理器的网关，通过管理器本身的负载均衡策略，决定访问相应的服节点的后端服务，保证整体服务端的稳定，并通过监控整体访问流量，动态增加或者扩展服务节点；

所述服务器终端接收到客户终端的调用的指令，通过基于opcua和modbus tcp协议的通信接口，直接对PLC工业控制器进行数据的读写操作，从而实现对工业设备的控制。

2.根据权利要求1所述的容器化管理系统，其特征在于：所述容器化管理器包括分布式存储模块、多个服务节点模块和控制节点模块；所述分布式存储模块用于保存集群状态，所述控制节点模块用于运行集群的管理控制，每个服务节点模块用于运行容器的主机节点。

3.根据权利要求2所述的容器化管理系统，其特征在于：每个Minion节点上运行一个Zgbelet代理，用于控制节点上的容器、镜像和存储卷。

4.根据权利要求2所述的容器化管理系统，其特征在于：所述负载均衡策略包括轮循均衡、权重轮循均衡、随机均衡、权重随机均衡、响应速度均衡、最少连接数均衡和处理能力均衡。

5.根据权利要求2所述的容器化管理系统，其特征在于：所述控制节点模块包括：

ZGAPI Server，所述ZGAPI Server提供了资源对象的唯一操作入口，其他所有的组件都必须通过ZGAPI Server提供的API来操作资源对象；ZGAPI Server以RESTful风格的API对外提供接口；所有服务节点的资源对象的生命周期维护都是通过调用API Server的接口来完成；

Controller Manager，Controller Manager用于集群内部的管理控制中心，用于实现容器化管理器的故障检测和自动恢复等工作；Controller Manager包含Node Controller和Replication Controller两个核心组件；其中Node Controller负责计算节点的加入和退出，通过Node Controller实现计算节点的扩容和缩容；Replication Controller用于资源对象RC的管理、应用的扩容、缩容以及滚动升级；

Scheduler，Scheduler用于集群中的调度器，负责容器化应用在集群的中的调度和分配；

Zgbelet，Zgbelet用于负责本Node节点上的Pod的创建、修改、监控、删除Pod的全生命周期管理，Zgbelet实时向ZGAPI Server发送所在计算节点Node的信息；

Zgbelet-Proxy，Zgbelet-Proxy用于实现Service的抽象，为一组Pod抽象的服务Service提供统一接口并提供负载均衡功能。