CN111176783A

CN111176783A - 容器治理平台的高可用方法、装置及电子设备

Info

Publication number: CN111176783A
Application number: CN201911142606.8A
Authority: CN
Inventors: 赖新明; 林文辉; 舒南飞; 王志刚; 孙科武
Original assignee: Aisino Corp
Current assignee: Aisino Corp
Priority date: 2019-11-20
Filing date: 2019-11-20
Publication date: 2020-05-19

Abstract

本公开实施例公开了一种容器治理平台的高可用方法、装置及电子设备。其中，容器治理平台的高可用方法，包括：采集节点运行信息，得到监控数据；基于所述监控数据分析当前节点的运行状态得到状态信息，将所述状态信息内嵌到心跳信息中；基于所述心跳信息和配置信息，生成解决异常状态的命令；响应所述命令，执行相应的动作对节点的异常状态进行处理。通过采集节点运行信息，并对节点运行信息进行分析，从而得到节点的状态信息，判断节点是否异常，并根据节点的异常信息和配置好的信息，生成解决异常状态的命令，基于该命令运行相应的程序对异常节点进行修复，从而达到对容器治理平台自身服务故障自动化解决的目的。

Description

容器治理平台的高可用方法、装置及电子设备

技术领域

本公开属于容器技术领域，更具体地，涉及容器治理平台的高可用方法、装置及电子设备。

背景技术

随着容器技术的不断发展，应用容器化带来了越来越多实际好处。相较于传统应用，容器化的应用容易自动化部署、可以在同一环境同时运行多个实例而互不影响、新版本自动化升级发布、更少的外部环境依赖以及易于横向延展以应对流量高峰情况，因此越来越多的企业开始发展容器技术，将更多的IT服务进行容器化改造。

与此同时，针对急剧增长的容器运行需求，容器治理技术应用而生，容器治理技术通过容器运行状态探针来保证容器的平稳运行，同时通过调度算法来保证集群的负载均衡。

然而容器治理平台属于平台层服务，仅能保证运行在其上的应用层服务的稳定性，当平台层自身服务出现故障时，容器治理平台将失去服务能力不能保证上层应用服务的稳定性，上层应用服务中断将会给企业造成经济和声誉上的巨大损失。因此保证容器治理平台的高可用性是亟需解决的问题，对目前工业界的解决方案调研发现，大多数解决方案是基于报警后人工运维的解决方式，这种方式依赖于报警服务的可用性、实时性以及运维人员的专业性，依然不能做到全自动化的解决方案。

发明内容

有鉴于此，本公开实施例提供了一种容器治理平台的高可用方法、装置及电子设备，至少解决现有技术中不能做到全自动化的解决容器治理平台自身服务故障问题。

第一方面，本公开实施例提供了一种容器治理平台的高可用方法，包括：

采集节点运行信息，得到监控数据；

基于所述监控数据分析当前节点的运行状态得到状态信息，将所述状态信息内嵌到心跳信息中；

基于所述心跳信息和配置信息，生成解决异常状态的命令；

响应所述命令，执行相应的动作对节点的异常状态进行处理。

作为本公开实施例的一种具体实现方式，所述基于所述心跳信息和配置信息，生成解决异常状态的命令的步骤之前，还包括：

判决是否能接收心跳信息；

若能正常接收心跳信息，则基于所述心跳信息和配置信息，生成解决异常状态的命令；

若在设定的时间内没有接收到心跳信息，则判断当前节点是否失联。

作为本公开实施例的一种具体实现方式，所述判断当前节点是否失联为：

通过向其他节点下达请求当前节点的任务。

作为本公开实施例的一种具体实现方式，若当前节点失联，则判断当前节点是否为主节点；

若是主节点，则将一个从节点调整为主节点；

当超过设置时间失联的主节点仍然失联，则向其他主节点发送删除失联主节点的命令。

作为本公开实施例的一种具体实现方式，所述采集节点运行信息，得到监控数据的步骤之后，包括：

将监控数据存入内嵌式数据库；

以配置的时间间隔读取所述监控数据。

第二方面，本公开实施例还提供了一种容器治理平台的高可用系统，包括：

监控模块：用于采集节点的物理信息和容器治理平台各个组件的运行状态；

节点服务模块：用于分析监控模块的监控数据，并在每次心跳中将分析结果发送给主服务模块，并用于执行主服务模块下发的命令；

主服务模块：用于接收节点服务模块的心跳信息，并根据配置信息向节点服务模块下发命令；配置信息中包括针对各种异常信息的处理命令或脚本。

作为本公开实施例的一种具体实现方式，所述节点服务模块部署于受控节点，所述主服务模块部署于控制节点；

和/或

所述主服务模块和监控模块以二进制或容器化方式部署，所述节点服务模块以二进制文件方式部署并随容器治理平台启动。

作为本公开实施例的一种具体实现方式，所述主服务模块根据接收的来自所述节点服务模块的心跳信息判断节点连通状态；

若所述主服务模块能正常接收到心跳信息时，根据心跳信息和配置信息，下发解决异常状态的命令给相应的所述节点服务模块；

若所述主服务模块超过可配置的时间没有收到某个所述节点服务模块的心跳信息会判断相应节点是否失联；

若不是节点失联则认为是相应的所述节点服务模块故障，则向其他节点下达指令尝试恢复故障的节点服务模块；

若是节点失联，则根据该节点性质以及配置信息做出相应处理；

所述主服务模块在自身与所述节点服务模块失去联系时，会根据配置等待一段时间，如果在等待时间后依然未收到任何指令，则会根据配置来对自身网络进行恢复。

作为本公开实施例的一种具体实现方式，当需要监控多个业务集群时，根据对高可用的需求和受控集群规模进行嵌套，包括：

所述主服务模块以容器方式多实例运行在容器治理平台集群上，由容器治理平台保证多个所述主服务模块实例的高可用性和负载均衡；

同时运行所述主服务模块的容器治理平台集群节点部署节点服务模块，再以一个独立的单点主服务模块来监控容器治理平台。

第三方面，本公开实施例还提供了一种电子设备，该电子设备包括：

存储器，存储有可执行指令；

处理器，所述处理器运行所述存储器中的所述可执行指令，以实现第一方面的容器治理平台的高可用方法；

或

运行第二方面的容器治理平台的高可用系统。

本公开通过采集节点运行信息，并对节点运行信息进行分析，从而得到节点的状态信息，判断节点是否异常，并根据节点的异常信息和配置好的信息，生成解决异常状态的命令，基于该命令运行相应的程序对异常节点进行修复，从而达到对容器治理平台自身服务故障自动化解决的目的。

本公开的其它特征和优点将在随后具体实施方式部分予以详细说明。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了根据本公开的一个实施例的容器治理平台的高可用方法的流程图；

图2示出了根据本公开的一个实施例的容器治理平台的高可用系统的结构示意图；

图3示出了根据本公开的一个实施例的harchet逻辑架构的结构示意图；

图4示出了根据本公开的一个实施例的harchet心跳的流程图；

图5示出了根据本公开的一个实施例的harchet的三层高可用架构结构示意图。

具体实施方式

下面将更详细地描述本公开的优选实施方式。虽然以下描述了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。

prometheus：普罗米修；

harchet：“海赤”；

harchet-server：海赤服务端；

harchet-client：海赤客户端。

经过多年的发展与竞争，kubernetes成为容器治理平台的业界事实标准。Kubernetes通过容器运行状态探针来保证容器的平稳运行，同时通过调度算法来保证集群的负载均衡。Kubernetes不仅可以使容器应用根据实时负载情况进行动态延展保证服务稳定，也提供了容器应用的灰度发布能力，大大提高了集群的使用效率同时降低了企业的运维成本。

当平台层自身服务出现故障时—以Kubernetes为例，当docker服务故障、dns服务故障、kubelet故障等发生时，Kubernetes将失去服务能力不能保证上层应用服务的稳定性，上层应用服务中断将会给企业造成经济和声誉上的巨大损失。

基于Kubernetes的容器治理平台在保证上层应用服务的高可用性方面已经相对成熟了，但是Kubernetes无法保证自身的高可用性，而目前工业界还没有提出很好的解决方案。

本公开提出一种容器治理平台的高可用系统，主要是解决Kubernets集群自身的高可用问题，提出一种主从控制结构，控制端节点用于保证受控端节点Kubernetes服务的高可用行，Kubernetes集群可能出现的故障主要有以下三种：

1、docker服务故障：

Kubernetes集群上运行的应用服务和自身的一些组建服务均是以容器形式来调度的，且Kubernetes的多个api都是对docker api的封装，因此docker服务正常运行时Kubernetes提供服务的前提，当docker服务故障时Kubernetes也就不能再继续提供服务。

2、kubernetes组件故障：

Kubernetes包含了kube-apiserver、etcd、kube-scheduler和dns等多个组件，其中apiserver是所有api的入口，etcd存储了所有容器应用服务的状态数据，kube-scheduler负责容器的调度，dns负责服务域名到ip的转换，这些组件相互协调配合完全了整个Kubernetes服务体系，任何一个组件故障时Kubernetes就会出现故障。

3、多个物理节点网络或断电故障：

当组成Kubernetes集群的物理节点出现网络或断电故障时，表现为节点与集群失联，Kubernetes的调度算法具备一定程度的应对节点丢失的能力，会将丢失节点上的容器重新调度到正常节点。但是如果没有及时恢复，剩余可用节点的负载将会加重使宕机可能性加大形成连锁反应。尤其是当有一半以上的Kubernetes主节点丢失时，Kubernetes将停止继续服务。

针对以上三种可能出现的故障问题，本公开提出的高可用方案能够很大程度上解决。

如图1所示，一种容器治理平台的高可用方法，包括如下步骤：

S101：采集节点运行信息，得到监控数据；

有部署在容器治理平台的监控程序对节点运行信息进行采集，并将采集的数据保存到数据库内。

S102：基于所述监控数据分析当前节点的运行状态得到状态信息，将所述状态信息内嵌到心跳信息中；

安装的节点服务程序，会对监控程序采集的监控数据进行分析，从而得知该节点是否故障，如存在故障，则判断具体为什么故障，然后将分析额结果内嵌到心跳信息中发送给主服务程序。

S103：基于所述心跳信息和配置信息，生成解决异常状态的命令；

主服务程序基于心跳信息包含的故障节点和故障原因，查找相应的配置信息，从而得到针对该故障修复命令，并将该修复命令发送给节点服务程序。

S104：响应所述命令，执行相应的动作对节点的异常状态进行处理。

节点服务程序根据接收的命令，执行相应的程序代码，对故障进行修复。

可选的，S102：所述基于所述心跳信息和配置信息，生成解决异常状态的命令的步骤之前，还包括：

判决是否能接收心跳信息；

可选的，所述判断当前节点是否失联的方式为：通过向其他节点下达请求当前节点的任务。即可以通过其他的节点下达指令，其他节点根据指令会向当前节点发出请求，根据当前节点对请求的反应，判断当前节点是否失联。例如ping一下ip地址。

可选的，若当前节点失联，则判断当前节点是否为主节点；

若是主节点，则将一个从节点调整为主节点；

可选的，所述采集节点运行信息，得到监控数据的步骤之后，包括：

将监控数据存入内嵌式数据库；

以配置的时间间隔读取所述监控数据。节点服务程序对其监控数据可以不实时读取，可以根据设置的时间，间隔读取。如3秒钟读取一次。本实施例并不限制实时读取，节点服务程序也可以实时读取监控数据。

相应的如图2所示，本公开还提出一种容器治理平台的高可用系统，包括：

监控模块201：用于采集节点的物理信息和容器治理平台各个组件的运行状态；

节点服务模块202：用于分析监控模块201的监控数据，并在每次心跳中将分析结果发送给主服务模块，并用于执行主服务模块下发的命令；

主服务模块203：用于接收节点服务模块202的心跳信息，并根据配置信息向节点服务模块202下发命令；配置信息中包括针对各种异常信息的处理命令或脚本。

可选的，所述节点服务模块202部署于受控节点，所述主服务模块203部署于控制节点；

和/或

所述主服务模块203和监控模块201以二进制或容器化方式部署，所述节点服务模块202以二进制文件方式部署并随容器治理平台启动。

可选的，所述主服务模块203根据接收的来自所述节点服务模块202的心跳信息判断节点连通状态；

若所述主服务模块203能正常接收到心跳信息时，根据心跳信息和配置信息，下发解决异常状态的命令给相应的所述节点服务模块202；

若所述主服务模块203超过可配置的时间没有收到某个所述节点服务模块202的心跳信息会判断相应节点是否失联；

若不是节点失联则认为是相应的所述节点服务模块202故障，则向其他节点下达指令尝试恢复故障的节点服务模块202；

所述主服务模块203在自身与所述节点服务模块202失去联系时，会根据配置等待一段时间，如果在等待时间后依然未收到任何指令，则会根据配置来对自身网络进行恢复。

在一个具体的应用场景中，如kubernetes中，引入prometheus作为监控工具，自研harchet高可用系统，提供面向集群的监控、服务恢复与节点恢复机制，

如图3所示为harchet的逻辑架构，harchet为主从结构，harchet-server部署于控制节点，用于接收harchet-client的心跳信息，harchet-client可根据配置信息向harchet-client下发命令；harchet-client部署于受控节点，用于分析prometheus的监控数据，并在每次心跳中将分析结果发送给harchet-server，harchet-client还用于执行harchet-server下发的命令；prometheus是开源组件，主要用于监控采集节点的物理信息和kubernetes各个组件的运行状态。其中harchet-server和prometheus可以二进制方式部署也可以容器化部署，可以纳入容器治理平台管理，harchet-client以二进制文件方式部署并随系统启动。harchet-server即上述节点服务模块202，harchet-client即上述主服务模块203，prometheus即监控模块201。

如图4所示，是单次心跳的运行流程图，在harchet运行中，prometheus采集节点运行信息存入内嵌式postgres数据库，harchet-client端以配置的时间间隔读取监控数据，如3秒或5秒等读取一次，也可以实时读取。通过监控数据分析当前节点的运行状态，并将状态信息内嵌到心跳信息中发送给harchet-server端。Harchet-server端根据心跳信息判断节点连通状态，能正常接收到节点心跳时根据心跳信息和配置信息，下发解决异常状态的命令给相应harchet-client，配置信息中包含了针对各种异常信息的处理命令或脚本。Harchet-client接收到harchet-server下发的命令后，立即执行，例如命令其使用bash执行systemctl restart docker命令。

如果harchet-server超过可配置的时间没有收到某个harchet-client端的心跳信息会判断相应节点是否失联，判断方法是通过向其他节点下达请求目标节点任务，例如ping一下ip地址。如果不是失联则认为是harchet-client自身故障，会向其他节点下达指令尝试恢复，如果判定是节点丢失，则根据该节点性质以及配置信息做出相应处理。如果节点是Kubernetes的master节点，为了保证kubernetes集群的高可用性，harchet-server将向一个slave节点下发加入master集群的相关命令动作。当过一段可配置的时间该master节点依然未恢复，则会向其他master节点下发删除宕机master的指令，以达到kubernetes集群始终保持master数量稳定，达到高可用目的。Harchet-clint在自身与harchet-server失去联系时，会根据配置等待一段时间，如果在等待时间后依然未收到为何指令，则会根据配置来对自身网络进行一个恢复。

可选的，当需要监控多个业务集群时，根据对高可用的需求和受控集群规模进行嵌套，包括：

所述主服务模块203以容器方式多实例运行在容器治理平台集群上，由容器治理平台保证多个所述主服务模块203实例的高可用性和负载均衡；

同时运行所述主服务模块203的容器治理平台集群节点部署节点服务模块202，再以一个独立的单点主服务模块203来监控容器治理平台。

当需要监控多个业务集群，且受控业务集群规模较大时harhcet-server性能将会出现瓶颈，本方案可根据对高可用的需求和受控集群规模进行嵌套，如图5所示，为嵌套式三层架构，harchet-server端以容器方式多实例运行在Kubernetes集群上，由Kubernetes保证多个harchet-server实例的高可用性和负载均衡，多实例以提供更大规模的集群监控。同时运行harchet-server的Kubernetes集群节点也同样安装harchet-client服务，再以一个独立的单点harchet-server来监控该Kubernetes达到三层架构。

本公开的一种容器治理平台的高可用系统，采用当下流行的主从控制结构，引入prometheus作为监控工具，自研harchet高可用系统，提供面向集群的监控、服务恢复与节点恢复机制，有效的保证集群高可用、易扩展等特点。

用于容器治理平台的高可用系统，保证集群高可用的途径有以下几个策略：

针对服务故障，监控目标集群所有节点的容器治理平台相关服务数据，提供故障服务的重启机制；

针对节点状态故障，监控Kubernetes集群各个master节点状态，提供slave节点替换机制；

针对节点物理状态，根据Kubernetes集群所有slave的心跳情况，提供slave节点的重启机制；

本实施例应用于Kubernetes集群，可有效保证Kubernetes集群上各节点的平稳运行和及时恢复，大大降低了Kubernetes节点的故障时间从而保证集群上业务系统的平稳运行。且基于配置的集群故障恢复机制，可以根据用户需求和平台差异进行简单的适配，有效的降低了企业运维投入。

本实施例提出的容器治理平台的高可用系统，可应用与包括Kubernetes在内的所有容器治理平台，提高Kubernetes集群的可用性。同时实施例的系统具备高性能和高可用性的特点，且易于拓展到大规模集群方案。

根据本公开实施例的电子设备包括存储器和处理器,

存储器，存储有可执行指令；

处理器，处理器运行存储器中的可执行指令，以实现容器治理平台的高可用方法，

或用来运行容器治理平台的高可用系统。

该存储器用于存储非暂时性计算机可读指令。具体地，存储器可以包括一个或多个计算机程序产品，该计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。该易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。该非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。

该处理器可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元，并且可以控制电子设备中的其它组件以执行期望的功能。在本公开的一个实施例中，该处理器用于运行该存储器中存储的该计算机可读指令。

本领域技术人员应能理解，为了解决如何获得良好用户体验效果的技术问题，本实施例中也可以包括诸如通信总线、接口等公知的结构，这些公知的结构也应包含在本公开的保护范围之内。

有关本实施例的详细说明可以参考前述各实施例中的相应说明，在此不再赘述。

本公开实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现所述的容器治理平台的高可用方法；

或该计算机程序被处理器执行时运行所述的容器治理平台的高可用系统。

根据本公开实施例的计算机可读存储介质，其上存储有非暂时性计算机可读指令。当该非暂时性计算机可读指令由处理器运行时，执行前述的本公开各实施例方法的全部或部分步骤。

上述计算机可读存储介质包括但不限于：光存储介质(例如：CD－ROM和DVD)、磁光存储介质(例如：MO)、磁存储介质(例如：磁带或移动硬盘)、具有内置的可重写非易失性存储器的媒体(例如：存储卡)和具有内置ROM的媒体(例如：ROM盒)。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。

Claims

1.一种容器治理平台的高可用方法，其特征在于，包括：

采集节点运行信息，得到监控数据；

基于所述心跳信息和配置信息，生成解决异常状态的命令；

2.根据权利要求1所述的容器治理平台的高可用方法，其特征在于，所述基于所述心跳信息和配置信息，生成解决异常状态的命令的步骤之前，还包括：

判决是否能接收心跳信息；

3.根据权利要求2所述的容器治理平台的高可用方法，其特征在于，所述判断当前节点是否失联为：

通过向其他节点下达请求当前节点的任务。

4.根据权利要求2所述的容器治理平台的高可用方法，其特征在于，

若当前节点失联，则判断当前节点是否为主节点；

若是主节点，则将一个从节点调整为主节点；

5.根据权利要求1所述的容器治理平台的高可用方法，其特征在于，所述采集节点运行信息，得到监控数据的步骤之后，包括：

将监控数据存入内嵌式数据库；

以配置的时间间隔读取所述监控数据。

6.一种容器治理平台的高可用系统，其特征在于，包括：

7.根据权利要求6所述的容器治理平台的高可用系统，其特征在于，

所述节点服务模块部署于受控节点，所述主服务模块部署于控制节点；

和/或

8.根据权利要求6所述的容器治理平台的高可用系统，其特征在于，

所述主服务模块根据接收的来自所述节点服务模块的心跳信息判断节点连通状态；

9.根据权利要求6所述的容器治理平台的高可用系统，其特征在于，

当需要监控多个业务集群时，根据对高可用的需求和受控集群规模进行嵌套，包括：

10.一种电子设备，其特征在于，所述电子设备包括：

存储器，存储有可执行指令；

处理器，所述处理器运行所述存储器中的所述可执行指令，以实现权利要求1-5中任一项所述的容器治理平台的高可用方法；

或

运行权利要求6-9中任一项所述的容器治理平台的高可用系统。