CN116980346A - 基于云平台的容器管理方法及装置 - Google Patents

Abstract

本申请实施例提供基于云平台的容器管理方法及装置。本实施例通过云平台集群的Leader实现对容器集群中各容器的实时监控，实现了利用堆叠系统中的云平台集群管理容器集群来进行基于云平台的容器管理。进一步地，本实施例在容器集群中的Master异常时，本实施例在任一容器监测到担任Leader的云平台异常或者本容器与Leader之间的链路异常时，由本容器和该容器集群中其它容器自行协同选举Master，而当监测到Leader正常且本容器与Leader之间的链路正常时，由Leader集中控制选举容器集群中容器选举Master，实现了选举Master的双层策略，极大提高了堆叠系统的可靠性。

Description

基于云平台的容器管理方法及装置

技术领域

本申请涉及网络通信领域，尤其涉及基于云平台的容器管理方法及装置。

背景技术

虚拟化技术，其核心思想是将多台物理设备连接在一起进行必要的配置后，多台物理设备自动收敛并虚拟化成一台虚拟设备（也称堆叠系统）。图1以堆叠系统为智能弹性架构（IRF：Intelligent Resilient Framework）为例进行了示意。为便于理解，堆叠系统中的各物理设备可称为堆叠系统的成员设备。使用这种虚拟化技术可以集合多台物理设备的硬件资源和软件处理能力，实现多台物理设备的协同工作、统一管理和不间断维护。

随着容器技术的迅速普及，各种容器应用越来越广泛和深入，如何将堆叠系统和容器相结合，是当前亟待解决的技术问题。

发明内容

有鉴于此，本申请实施例提供基于云平台的容器管理方法及装置，以利用堆叠系统中的云平台集群管理容器集群实现基于云平台的容器管理方法。

根据本申请实施例的第一方面，提供一种基于云平台的容器管理方法，方法应用于堆叠系统中任一成员设备，所述堆叠系统是由N个成员设备堆叠得到，任一成员设备除了部署云平台之外还部署了容器，所述堆叠系统中不同成员设备上的云平台组成云平台集群，所述堆叠系统中不同成员设备上的容器组成容器集群；该方法包括：

在本地云平台作为所述云平台集群中的拥护者Follower时，从所述云平台集群中被选举为领导者Leader的云平台中获得容器集群拓扑信息；在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息；

在本地云平台作为Leader时，基于本成员设备中本地容器的健康状态的健康指标确定本地容器的容器健康度，以及接收所述堆叠系统中其它成员设备上报的容器的健康指标，基于接收到的健康指标确定该其它成员设备上容器的容器健康度，并将该容器健康度下发至该其它成员设备；

在本地云平台作为Follower时，若本地容器为所述容器集群中的备容器Slave，若通过本地容器检测到所述容器集群中主容器Master选举事件，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。

根据本申请实施例的第二方面，提供一种基于云平台的容器管理装置，所述装置应用于堆叠系统中任一成员设备，所述堆叠系统是由N个成员设备堆叠得到，任一成员设备除了部署云平台之外还部署了容器，所述堆叠系统中不同成员设备上的云平台组成云平台集群，所述堆叠系统中不同成员设备上的容器组成容器集群；该装置包括：

拓扑单元，用于在本地云平台作为所述云平台集群中的拥护者Follower时，从所述云平台集群中被选举为领导者Leader的云平台中获得容器集群拓扑信息；在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息；

健康指标单元，用于在本地云平台作为Leader时，基于本成员设备中本地容器的健康状态的健康指标确定本地容器的容器健康度，以及接收所述堆叠系统中其它成员设备上报的容器的健康指标，基于接收到的健康指标确定该其它成员设备上容器的容器健康度，并将该容器健康度下发至该其它成员设备；

管理单元，用于在本地云平台作为Follower时，若本地容器为所述容器集群中的备容器Slave，若通过本地容器检测到所述容器集群中主容器Master选举事件，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。

根据本申请实施例的第三方面，提供一种电子设备，电子设备包括：

处理器和机器可读存储介质，机器可读存储介质存储有能够被所述处理器执行的机器可执行指令；

所述处理器用于执行机器可执行指令，以实现如上所述的方法。

根据本申请实施例的第四方面，提供一种机器可读存储介质，该机器可读存储介质存储有能够被所述处理器执行的机器可执行指令；

所述机器可执行指令被执行时以实现如上所述的方法。

本申请实施例提供的技术方案可以包括以下有益效果：

在本实施例中，通过云平台集群的Leader实现对容器集群中各容器的实时监控，实现了利用堆叠系统中的云平台集群管理容器集群来进行基于云平台的容器管理。

进一步地，本实施例在容器集群中的Master异常时，基于容器健康度来选举出健康程度最高的容器作为容器集群中的主容器，有效避免了网络出现双主、故障主、或者故障备的运行场景，从而增加了整个堆叠系统的稳定性；

再进一步地，本实施例在任一容器监测到担任Leader的云平台异常或者本容器与Leader之间的链路异常时，由本容器和该容器集群中其它容器自行协同选举Master，而当监测到Leader正常且本容器与Leader之间的链路正常时，由Leader集中控制选举容器集群中容器选举Master，实现了选举Master的双层策略，极大提高了堆叠系统的可靠性。

再进一步地，本实施例在任一容器监测到担任Leader的云平台异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，而非广播选举报文，避免网络震荡。

附图说明

图1是本申请实施例示出的堆叠系统组网示意图；

图2是本申请实施例示出的堆叠系统中各集群示意图；

图3是本申请实施例示出的方法流程图；

图4是本申请实施例示出的容器拓扑构建示意图；

图5是本申请实施例示出的容器上报示意图；

图6是本申请实施例示出的双层选Master示意图；

图7是本申请实施例示出的选举Master的流程图；

图8是本申请实施例提供的选举Master组网示意图；

图9是本申请实施例提供的状态切换示意图；

图10是本申请实施例提供的步骤303另一流程图；

图11是本申请实施例示出的装置结构图；

图12是本申请实施例示出的装置的硬件结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

下面先对本申请实施例提供的应用场景进行描述：

在本实施例中，堆叠系统的各成员设备运行了云平台和容器。比如，如图2所示，三台物理设备组成了堆叠系统比如智能弹性架构（IRF：Intelligent Resilient Framework）堆叠系统。其中P1、P2、P3分别表示三台物理设备中运行的云平台，C1、C2、C3分别表示三台物理设备中运行的Comware V9容器。

在本实施例，堆叠系统中各物理设备上运行的云平台组成云平台集群。这里，云平台集群中的其中一个云平台担任领导者角色（Leader），剩余的云平台担任拥护者角色（Follower）。云平台集群中各云平台的角色可通过设定算法比如Raft算法选举，下文会举例描述，这里暂不赘述。图2举例示出了云平台集群以及其中各云平台的角色。

在本实施例，堆叠系统中各物理设备上运行的容器组成容器集群。这里，容器集群中的其中一个容器担任主容器（Master），剩余的容器担任备容器（Slave）。容器集群中各容器的角色选举，下文会举例描述，这里暂不赘述。图2举例示出了容器集群以及其中各容器的角色。

基于如上描述，下面对本申请实施例提供的方法进行描述：

参见图3，图3为本申请实施例提供的方法流程图。该方法应用于堆叠系统中任一成员设备。

如图3所示，该流程可包括以下步骤：

步骤301，在本地云平台作为Follower时，从Leader中获得容器集群拓扑信息；在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息。

作为一个实施例，云平台集群中的云平台可包括工作组件（Worker）。其中，还有至少一个云平台包括管理组件（Manager）。在本实施例中，被部署了Manager的云平台可作为Leader的候选者，而未被部署了Manager的云平台不作为Leader的候选者。基于此，当云平台集群中的Leader离开时，作为候选者的其它云平台立即发起投票请求，任一云平台接收到投票请求后投出选票（从候选者中选择）。当有一作为候选者的云平台接收到半数以上的投票，则确定本云平台为Leader，代替原来的Leader工作。

在本实施例中，Leader中的Manager负责管理云平台集群、以及统一处理外部的配置（也称API处理）。而Leader中的Worker，负责本地容器的管理比如获得本地容器的运行状态并上报给本地Manager等。而Follower中的Worker负责本地容器的管理比如获得本地容器的运行状态并上报给Leader的Manager，以及接收Leader的Manager下发的容器调度消息比如部署容器、构建容器集群等。可以看出，本实施例是利用云平台实现容器的创建和构建容器集群，无须自行广播实现容器堆叠，有效避免了二层广播风暴，避免网络振荡。

在本实施例中，任一容器包括云平台的代理组件（Agent）。堆叠系统中任一成员设备上云平台的Worker与本地容器中的云平台Agent进行通信获得容器信息。基于此，本步骤301中，在本地云平台作为Follower时，从Leader中获得容器集群拓扑信息可包括：通过本地Worker与Leader进行通信，以将本地容器信息比如容器ID、成员编号、容器MAC等发送给Leader使得Leader获取到整个堆叠系统中所有成员设备上容器的容器信息（相当于Leader获得容器集群拓扑信息）；通过本地Worker接收Leader下发的容器集群拓扑信息。最终实现了从Leader中获得容器集群拓扑信息。图4举例示出了容器集群拓扑信息下发示意图。

当然，本步骤301中，在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息可包括：通过本地Manager向各Follower中的Worker发送容器集群拓扑信息。当然，假若堆叠系统中基于容器增加或删除产生容器拓扑变化事件，当上述Leader监测到容器拓扑变化事件，其也会通过本地Manager向各Follower中的Worker发送变化后的容器集群拓扑信息。

步骤302，在本地云平台作为Leader时，基于本成员设备中本地容器的健康状态的健康指标确定本地容器的容器健康度，以及接收其它成员设备上报的容器的健康指标，基于接收到的健康指标确定该其它成员设备上容器的容器健康度，并将该容器健康度下发至该其它成员设备。

在本实施例中，Leader通过本地Manager监控容器集群中各容器的健康指标，以便对容器进行智能管理。图5举例示出了容器健康指标上报示意图。比如，如图5所示，各成员设备中云平台（包括Leader、Follower）内的Worker监控到健康指标时，向Leader内的Manager上报该健康指标。最终实现了Leader通过本地Manager监控容器集群中各容器的健康指标。

可选地，在本实施例中，容器的健康指标用于反映容器的业务运行情况。在具体实现时，健康指标可包括：容器环境下的健康指标、容器容量下的健康指标。任一健康指标可通过健康指标类型和健康指标值表示。表1从容器环境、容器容量两个维度举例示出了容器的健康指标：

表1

在本实施例中，可基于容器环境下各个维度的健康指标确定容器环境健康度，以及基于容器容量下各个维度的健康指标确定容器容量健康度，之后基于设备环境健康度和容器容量环境健康度，确定最终的容器健康度。在本实施例中，容器健康度反映了容器真实的健康状态，健康度越高的容器，优先级越高，被选举为Master的概率也会越高；当容器健康度相同时，容器容量代表容器的运行状态，容器容量越高的容器，相应的优先级也越高，被选举为Master的概率也会越高。

可选地，在本实施例中，基于容器环境下各个维度的健康指标确定设备环境健康度在具体实现时有很多实现方式，比如选择容器环境下取值最小的健康指标作为设备环境健康度，等，本实施例并不具体限定。

可选地，在本实施例中，基于容器容量下各个维度的健康指标确定容器容量健康度在具体实现时有很多实现方式，比如选择容器容量下取值最小的健康指标作为容器容量健康度，等，本实施例并不具体限定。

可选地，在本实施例中，可按照下式计算容器健康度 = (设备环境健康度 +容量健康度)/2。需要说明的是，这里只是举例描述如何计算容器健康度，并非用于限定。

步骤303，在本地容器为容器集群中的Slave时，若通过本地容器检测到Master选举事件，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。

在本实施例中，Master选举事件可由容器集群中Master被指定的关键组件故障、容器集群中Slave心跳检测超时等引起。可选地，容器集群中Slave和Master之间进行心跳检测，比如Slave定时向Master发送心跳报文，一旦在发送心跳报文的设定时间段内接收不到Master的响应，则认为心跳检测超时。作为一个实施例，一旦Slave发现心跳检测超时，则该Slave中的云平台Agent通知驱动，由驱动通知设备管理插入/拔出事件，实现及时刷新容器集群拓扑中成员在位信息。

可选地，在本实施例中，关键组件可为运行实时性高的功能组件，一旦关键组件故障，会影响整个容器的运行。可选地，这里的关键组件比如为CPU、插板等，本实施例并不具体限定。表2举例示出了关键组件故障的情况：

表2

可选地，在本实施例中，容器相当于一个操作系统，当容器中的上述关键组件比如CPU出现故障，在Leader正常时，容器所处成员设备上的云平台通过该本地Worker上报该关键组件故障至Leader的Manager。图5也举例示意了容器上报关键组件故障（也称关键指标异常）。比如，C2中的CPU故障，则作为Follower的P2中的Worker会上报该CPU故障至Leader中的Manager。一旦Leader中的Manager收到上述关键指标故障，则会触发Master选举。

作为一个实施例，假若容器集群按照星堆方式堆叠，则当容器集群中的Slave检测到Master选举事件，其会根据容器集群拓扑信息获得其它各容器的容器健康度，以根据本地容器的容器健康度、以及其它容器的容器健康度自行选举Master。

作为一个实施例，假若容器集群被拟定由云平台统一处理，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master（也称容器自行选举Master，简称容器内层选Master）；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master（也称云平台集中控制选举Master，简称云平台外层选Master）；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。举例描述：如图6所示，假若本Follower与Leader的连接正常，则基于所述Leader的控制选举Master，否则，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master。也即实现了双层选举Master的策略，提高堆叠系统的稳定性。

可选地，容器集群中Slave和Slave之间也会进行心跳检测，上述参与本次选举的其它容器可为与本Slave连通的容器。

至此，完成图3所示流程。

通过图3所示流程可以看出，本实施例通过云平台集群的Leader实现对容器集群中各容器的实时监控，实现了利用堆叠系统中的云平台集群管理容器集群来进行基于云平台的容器管理。

进一步地，本实施例在容器集群中的Master异常时，基于容器健康度来选举出健康程度最高的容器作为容器集群中的主容器，有效避免了网络出现双主、故障主、或者故障备的运行场景，从而增加了整个堆叠系统的稳定性；

再进一步地，本实施例在任一容器监测到担任Leader的云平台异常或者本容器与Leader之间的链路异常时，由本容器和该容器集群中其它容器自行协同选举Master，而当监测到Leader正常且本容器与Leader之间的链路正常时，由Leader集中控制选举容器集群中容器选举Master，实现了选举Master的双层策略，极大提高了堆叠系统的可靠性。

再进一步地，本实施例在任一容器监测到担任Leader的云平台异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，而非广播选举报文，避免网络震荡。

下面对本实施例中步骤303依据本地容器的容器健康度、以及其它容器的容器健康度选举Master进行描述：

可选地，在本实施例中，任一容器在确定需要重新选举Master时，进一步会将本地容器的状态切换为选举状态，并启动选举定时器。

基于此，步骤303依据本地容器的容器健康度、以及其它容器的容器健康度选举Master可包括如图7所示的流程：

步骤701，在选举定时器超时之前若获取到参与选举的其它所有容器的容器健康度，则关闭所述选举定时器，执行步骤702，否则，当选举定时器超时时，执行步骤702。

在本实施例中，相对本地容器而言，这里参与选举的其它所有容器是指与本地容器的心跳检测未超时（或者连通的容器）。在本实施例中，所有Slave之间也会进行心跳检测。

步骤702，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master。

可选地，本实施例可按照以下选举决策准则选择Master：

容器健康度最优（也即最大）的作为Master。

容器健康度相同时，运行时间长的容器作为Master。

运行时间相同时，使用桥MAC地址满足设定要求（比如最小）的作为Master。

基于上述选举决策准则，则本步骤702具体可包括：从本地容器的容器健康度、以及其它容器的容器健康度中选举容器健康度最大的容器；若至少两个容器的容器健康度取值相同且最大，则从该至少两个容器中选举运行时间最长的容器；若选举出的运行时间最长的容器的数量大于1，则从该选举出的运行时间最长的容器种选择桥MAC地址满足设定要求的容器作为Master。

至此，完成图7所示流程。

通过图7所示流程，实现了如何依据本地容器的容器健康度、以及其它容器的容器健康度选举Master。图8通过组网进行了示意。如图8所示，假若初始，容器集群是由C1至C6组成，该容器集群记为容器集群1，此时C1作为Master。假若因为C4至C1之间的链路异常而导致容器集群被分裂出容器集群2和容器集群3，容器集群2由C1至C3组成，容器集群3由C4至C6组成，对于容器集群2，其可仍采用C1作为Master即可，而对于容器集群3，则当Leader故障时，此时容器集群3中的C4至C6可按照图7所示流程执行，以C4为例，C4先进入选举状态，并启动选举定时器，在选举定时器超时之前若获取到参与选举的其它所有容器即C5、C6的容器健康度，则关闭选举定时器，依据本地容器的容器健康度、以及其它容器即C5、C6的容器健康度选举Master。否则，当选举定时器超时时，依据本地容器的容器健康度、以及其它容器即C5、C6的容器健康度选举Master。假若C4至C6的容器健康度中，C4的容器健康度最大，则可选举C4作为容器集群3的Master。

在本实施例中，基于上面描述，可以看出容器会在Master/Slave、选举状态、Master/Slave之间进行切换。以图8所示的容器C4为例，图9举例示出了C4的状态切换示意图。如图9所示，初始，C1为Master，C4为Slave，C4会向C1发送单播心跳报文以进行心跳检测，当通过心跳检测到C1故障或者与C1之间的链路故障，则会触发重新选举Master。C4在重新选举Master时进入选举态（Election）并启动选举定时器。之后，C4依据本C4的容器健康度、以及其它容器即C5、C6的容器健康度选举Master，假若C4被选举为Master，则C4从Election切换为Master，并广播心跳报文。当然，假若C4被选举为Slave，C5被选举为Master，则C4从Election切换为Slave，并向新选举的Master单播发送心跳报文。

下面描述步骤303中如何基于Leader的控制选举Master：

参见图10，图10为本申请实施例提供的步骤303另一流程图。如图10所示，该流程可包括以下步骤：

步骤1001，在本地云平台作为Leader时，检测所述容器集群是否被分成至少两个子群；如果否，执行步骤1002，如果是，执行步骤1003。

步骤1002，在所述容器集群不存在Master时，依据所述容器集群中各容器的容器健康度以及容器容量，指定所述容器集群中其中一个容器为Master。

这里，可按照以下指定原则指定容器集群中其中一个容器为Master：容器健康度最优（也即最大）的作为Master，若容器健康度相同时，容器容量最大的容器作为Master。

步骤1003，从所述至少两个子群中选择满足设定容器要求的最优子群，在所述最优子群不存在Master时，依据所述最优子群中各容器的容器健康度以及容器容量，指定所述最优子群中其中一个容器为Master；并针对除最优子群之外的其它每一非最优子群，隔离该非最优子群中每一容器中的业务口，所述业务口是指容器中除集群堆叠口之外的端口，并在非最优子群中不存在Master时，依据该非最优子群中各容器的容器健康度以及容器容量，指定该非最优子群中其中一个容器为Master。

在本实施例中，最优子群可为容器数量最小的子群。

在本实施例中，指定所述最优子群中其中一个容器为Master，或者指定该非最优子群中其中一个容器为Master，可按照上述指定原则执行，这里不再赘述。

至此，完成图10所示的流程。

通过图10所示流程，实现了如何基于所述Leader的控制选举Master。

需要说明的是，在本实施例中，假若原来发生异常的Master恢复正常，则可控制除最优子群中的其它各非最优子群重启加入最优子群，最终又恢复出原Master异常前的状态。

以上对本申请实施例提供的方法进行了描述，下面对本申请实施例提供的装置进行描述：

参见图11，图11为本申请实施例提供的装置结构图。所述装置应用于堆叠系统中任一成员设备，所述堆叠系统是由N个成员设备堆叠得到，任一成员设备除了部署云平台之外还部署了容器，所述堆叠系统中不同成员设备上的云平台组成云平台集群，所述堆叠系统中不同成员设备上的容器组成容器集群；该装置包括：

拓扑单元，用于在本地云平台作为所述云平台集群中的拥护者Follower时，从所述云平台集群中被选举为领导者Leader的云平台中获得容器集群拓扑信息；在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息；

健康指标单元，用于在本地云平台作为Leader时，基于本成员设备中本地容器的健康状态的健康指标确定本地容器的容器健康度，以及接收所述堆叠系统中其它成员设备上报的容器的健康指标，基于接收到的健康指标确定该其它成员设备上容器的容器健康度，并将该容器健康度下发至该其它成员设备；

管理单元，用于在本地云平台作为Follower时，若本地容器为所述容器集群中的备容器Slave，若通过本地容器检测到所述容器集群中主容器Master选举事件，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。

可选地，所所述健康指标包括：容器环境下多个不同维度的健康指标、以及容器容量下多个不同维度的健康指标；

所述容器健康度与容器环境健康度和容器容量健康度正相关，其中，所述容器环境健康度是基于容器环境下各个维度的健康指标确定，所述容器容量健康度是基于容器容量下各个维度的健康指标确定。

可选地，所述Master选举事件包括以下至少一个事件：容器集群中Master被指定的关键组件发生故障、心跳检测超时；其中，所述容器集群中Slave和Master之间进行心跳检测，Slave在设定时间段内接收不到Master的响应，则确定心跳检测超时。

可选地，当发现所述Leader异常或者本容器与所述Leader之间的链路异常时，管理单元进一步将本地容器的状态切换为选举状态，并启动选举定时器；

可选地，所述依据本地容器的容器健康度、以及其它容器的容器健康度选举Master包括：

在所述选举定时器超时之前若获取到参与选举的其它所有容器的容器健康度，则关闭所述选举定时器，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master，若在所述选举定时器超时之前未获取到参与选举的其它所有容器的容器健康度，则在所述选举定时器超时时，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master。

可选地，所述依据本地容器的容器健康度、以及其它容器的容器健康度选举Master包括：从本地容器的容器健康度、以及其它容器的容器健康度中选举容器健康度最大的容器；若至少两个容器的容器健康度取值相同且最大，则从该至少两个容器中选举运行时间最长的容器；若选举出的运行时间最长的容器的数量大于1，则从该选举出的运行时间最长的容器种选择桥MAC地址满足设定要求的容器作为Master。

可选地，所述基于所述Leader的控制选举Master包括：在本地云平台作为Leader时，检测所述容器集群是否被分成至少两个子群；如果否，在所述容器集群不存在Master时，依据所述容器集群中各容器的容器健康度以及容器容量，指定所述容器集群中其中一个容器为Master；如果是，从所述至少两个子群中选择满足设定容器要求的最优子群，在所述最优子群不存在Master时，依据所述最优子群中各容器的容器健康度以及容器容量，指定所述最优子群中其中一个容器为Master；并针对除最优子群之外的其它每一非最优子群，隔离该非最优子群中每一容器中的业务口，所述业务口是指容器中除集群堆叠口之外的端口，并在非最优子群中不存在Master时，依据该非最优子群中各容器的容器健康度以及容器容量，指定该非最优子群中其中一个容器为Master。

至此，完成图11所示装置的描述。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

对应地，本申请实施例还提供了图11所示装置的硬件结构图，具体如图12所示，该电子设备可以为上述实施方法的设备。如图12所示，该硬件结构包括：

处理器和机器可读存储介质，机器可读存储介质存储有能够被所述处理器执行的机器可执行指令；

所述处理器用于执行机器可执行指令以实现上述示例公开的方法。

示例性的，上述机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM（Radom Access Memory，随机存取存储器）、易失存储器、非易失性存储器、闪存、存储驱动器（如硬盘驱动器）、固态硬盘、任何类型的存储盘（如光盘、DVD等），或者类似的存储介质，或者它们的组合。

至此，完成图12所示电子设备的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (10)

1.一种基于云平台的容器管理方法，其特征在于，所述方法应用于堆叠系统中任一成员设备，所述堆叠系统是由N个成员设备堆叠得到，任一成员设备除了部署云平台之外还部署了容器，所述堆叠系统中不同成员设备上的云平台组成云平台集群，所述堆叠系统中不同成员设备上的容器组成容器集群；该方法包括：

在本地云平台作为所述云平台集群中的拥护者Follower时，从所述云平台集群中被选举为领导者Leader的云平台中获得容器集群拓扑信息；在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息；

在本地云平台作为Leader时，基于本成员设备中本地容器的健康状态的健康指标确定本地容器的容器健康度，以及接收所述堆叠系统中其它成员设备上报的容器的健康指标，基于接收到的健康指标确定该其它成员设备上容器的容器健康度，并将该容器健康度下发至该其它成员设备；

在本地云平台作为Follower时，若本地容器为所述容器集群中的备容器Slave，若通过本地容器检测到所述容器集群中主容器Master选举事件，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。

2.根据权利要求1所述的方法，其特征在于，所述健康指标包括：容器环境下多个不同维度的健康指标、以及容器容量下多个不同维度的健康指标；

所述容器健康度与容器环境健康度和容器容量健康度正相关，其中，所述容器环境健康度是基于容器环境下各个维度的健康指标确定，所述容器容量健康度是基于容器容量下各个维度的健康指标确定。

3.根据权利要求1所述的方法，其特征在于，当发现所述Leader异常或者本容器与所述Leader之间的链路异常时，该方法进一步包括：将本地容器的状态切换为选举状态，并启动选举定时器；

所述依据本地容器的容器健康度、以及其它容器的容器健康度选举Master包括：

在所述选举定时器超时之前，若获取到参与选举的其它所有容器的容器健康度，则关闭所述选举定时器并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master，否则，在所述选举定时器超时时，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master。

4.根据权利要求1或3所述的方法，其特征在于，所述依据本地容器的容器健康度、以及其它容器的容器健康度选举Master包括：

从本地容器的容器健康度、以及其它容器的容器健康度中选举容器健康度最大的容器；

若至少两个容器的容器健康度取值相同且最大，则从该至少两个容器中选举运行时间最长的容器；

若选举出的运行时间最长的容器的数量大于1，则从该选举出的运行时间最长的容器种选择桥MAC地址满足设定要求的容器作为Master。

5.根据权利要求1所述的方法，其特征在于，所述基于所述Leader的控制选举Master包括：

在本地云平台作为Leader时，检测所述容器集群是否被分成至少两个子群；

如果否，在所述容器集群不存在Master时，依据所述容器集群中各容器的容器健康度以及容器容量，指定所述容器集群中其中一个容器为Master；

如果是，从所述至少两个子群中选择满足设定容器要求的最优子群，在所述最优子群不存在Master时，依据所述最优子群中各容器的容器健康度以及容器容量，指定所述最优子群中其中一个容器为Master；并针对除最优子群之外的其它每一非最优子群，隔离该非最优子群中每一容器中的业务口，所述业务口是指容器中除集群堆叠口之外的端口，并在非最优子群中不存在Master时，依据该非最优子群中各容器的容器健康度以及容器容量，指定该非最优子群中其中一个容器为Master。

6.一种基于云平台的容器管理装置，其特征在于，所述装置应用于堆叠系统中任一成员设备，所述堆叠系统是由N个成员设备堆叠得到，任一成员设备除了部署云平台之外还部署了容器，所述堆叠系统中不同成员设备上的云平台组成云平台集群，所述堆叠系统中不同成员设备上的容器组成容器集群；该装置包括：

拓扑单元，用于在本地云平台作为所述云平台集群中的拥护者Follower时，从所述云平台集群中被选举为领导者Leader的云平台中获得容器集群拓扑信息；在本地云平台作为Leader时，向其它成员设备发送容器集群拓扑信息；

健康指标单元，用于在本地云平台作为Leader时，基于本成员设备中本地容器的健康状态的健康指标确定本地容器的容器健康度，以及接收所述堆叠系统中其它成员设备上报的容器的健康指标，基于接收到的健康指标确定该其它成员设备上容器的容器健康度，并将该容器健康度下发至该其它成员设备；

管理单元，用于在本地云平台作为Follower时，若本地容器为所述容器集群中的备容器Slave，若通过本地容器检测到所述容器集群中主容器Master选举事件，则当发现Leader异常或者本容器与Leader之间的链路异常时，基于所述容器集群拓扑信息向所述容器集群中参与本次选举的其它容器发送单播选举报文以得到其它容器的容器健康度，并依据本地容器的容器健康度、以及其它容器的容器健康度选举Master；当发现所述云平台集群中的Leader正常且本容器与所述Leader之间的链路正常时，基于所述Leader的控制选举Master；若本地容器被选举为Master，则通过本地容器接替原Master工作并通知其它Slave停止选举，若本地容器被选举为Slave，则通过本地容器继续以Slave的角色工作。

7.根据权利要求6所述的装置，其特征在于，所述健康指标包括：容器环境下多个不同维度的健康指标、以及容器容量下多个不同维度的健康指标；

所述容器健康度与容器环境健康度和容器容量健康度正相关，其中，所述容器环境健康度是基于容器环境下各个维度的健康指标确定，所述容器容量健康度是基于容器容量下各个维度的健康指标确定。

8.根据权利要求6所述的装置，其特征在于，所述管理单元在发现所述Leader异常或者本容器与所述Leader之间的链路异常时，进一步将本地容器的状态切换为选举状态，并启动选举定时器；

所述依据本地容器的容器健康度、以及其它容器的容器健康度选举Master包括：

在所述选举定时器超时之前若获取到参与选举的其它所有容器的容器健康度，则关闭所述选举定时器，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master，若在所述选举定时器超时之前未获取到参与选举的其它所有容器的容器健康度，则在所述选举定时器超时时，依据本地容器的容器健康度、以及其它容器的容器健康度选举Master。

9.根据权利要求6或8所述的装置，其特征在于，所述依据本地容器的容器健康度、以及其它容器的容器健康度选举Master包括：

从本地容器的容器健康度、以及其它容器的容器健康度中选举容器健康度最大的容器；若至少两个容器的容器健康度取值相同且最大，则从该至少两个容器中选举运行时间最长的容器；若选举出的运行时间最长的容器的数量大于1，则从该选举出的运行时间最长的容器种选择桥MAC地址满足设定要求的容器作为Master。

10.根据权利要求6所述的装置，其特征在于，所述基于所述Leader的控制选举Master包括：

在本地云平台作为Leader时，检测所述容器集群是否被分成至少两个子群；

如果否，在所述容器集群不存在Master时，依据所述容器集群中各容器的容器健康度以及容器容量，指定所述容器集群中其中一个容器为Master；

如果是，从所述至少两个子群中选择满足设定容器要求的最优子群，在所述最优子群不存在Master时，依据所述最优子群中各容器的容器健康度以及容器容量，指定所述最优子群中其中一个容器为Master；并针对除最优子群之外的其它每一非最优子群，隔离该非最优子群中每一容器中的业务口，所述业务口是指容器中除集群堆叠口之外的端口，并在非最优子群中不存在Master时，依据该非最优子群中各容器的容器健康度以及容器容量，指定该非最优子群中其中一个容器为Master。